openEmu app.zip

//////////////////////////////////////////////////////////////////////////////// //// crt-royale, by TroggleMonkey <[email protected]> //// //// Last Updated: August 16, 2014 //// //////////////////////////////////////////////////////////////////////////////// REQUIREMENTS: The earliest official Retroarch version fully supporting crt-royale is 1.0.0.3 (currently unreleased). Earlier versions lack shader parameters and proper mipmapping and sRGB support, but the shader may still run at reduced quality. The earliest development version fully supporting this shader is: commit ba40be909913c9ccc34dab5d452fba4fe61af9d0 Author: Themaister <[email protected]> Date: Thu Jun 5 17:41:10 2014 +0200 A few earlier revisions support the required features, but they may be buggier. BASICS: crt-royale is a highly customizable CRT shader for Retroarch and other programs supporting the libretro Cg shader standard. It uses a number of nonstandardized extensions like sRGB FBO's, mipmapping, and runtime shader parameters, but hopefully it will run without much of a fuss on new implementations of the standard as well. There are a huge number of parameters. Among the things you can customize: * Phosphor mask type: An aperture grille, slot mask, and shadow mask are each included, although the latter won't be seeing much usage until 1440p displays and better become more common (4k UHD and 8k UHD are increasingly optimal). * Phosphor mask dot pitch * Phosphor mask resampling method: Choose between Lanczos sinc resizing, mipmapped hardware resizing, and no resizing of the input LUT. * Phosphor bloom softness and type (real or fake ;)) * Gaussian and generalized Gaussian scanline beam properties/distribution, including convergence offsets * Screen geometry, including curvature (spherical, alternative spherical, or cylindrical like Trinitrons), tilt, and borders * Antialiasing level, resampling filter, and sharpness parameters for gracefully combining screen curvature with high-frequency phosphor details, including optionally resampling based on RGB subpixel positions. * Halation (electrons bouncing under the glass and lighting random phosphors) random phosphors) * Refractive diffusion (light spreading from the imperfect CRT glass face) * Interlacing options * etc. There are two major ways to customize the shader: * Runtime shader parameters allow convenient experimentation with real-time feedback, but they are much slower, because they prevent static evaluation of a lot of math. Disabling them drastically speeds up the shader. * If runtime shader parameters are disabled (partially or totally), those same settings can be freely altered in the text of the user-settings.h file. There are also a number of other static-only settings, including the #define macros which indicate where and when to allow runtime shader parameters. To disable them entirely, comment out the "#define RUNTIME_SHADER_PARAMS_ENABLE" line by putting a double-slash ("//") at the beginning...your FPS will skyrocket. You may also note that there are two major versions of the shader preset: * crt-royale.cgh is the "full" version of the shader, which blooms the light from the brighter phosphors to maintain brightness and avoid clipping. * crt-royale-fake-bloom.cgh is the "cheater's" version of the shader, which only fakes the bloom based on carefully blending in a [potentially blurred] version of the original input. This version is MUCH faster, and you have to strain to see the difference, so people with slower GPU's will prefer it. There's a lot to play around with, and I encourage everyone using this shader to read through the user-settings.h file to learn about the parameters. Before loading the shader, be sure to read the next section, entitled... //////////////////////////////////////////////////////////////////////////////// //// FREQUENTLY EXPECTED QUESTIONS: //// //////////////////////////////////////////////////////////////////////////////// 1.) WHY IS THE SHADER CRASHING WHEN I LOAD IT?!? Do you get C6001 or C6002 errors with integrated graphics, like Intel HD 4000? If so, please try one of the following .cgp presets: * crt-royale-intel.cgp * crt-royale-fake-bloom-intel.cgp These load .cg wrappers that #define INTEGRATED_GRAPHICS_COMPATIBILITY_MODE (also available in user-settings.h) before loading the main .cg shader files. Integrated graphics compatibility mode will disable these three features, which currently require more registers or instructions than Intel GPU's allow: * PHOSPHOR_MASK_MANUALLY_RESIZE: The phosphor mask will be softer. (This may be reenabled in a later release.) * RUNTIME_GEOMETRY_MODE: You must change the screen geometry/curvature using the geom_mode_static setting in user-settings.h. * The high-quality 4x4 Gaussian resize for the bloom approximation Using Intel-specific .cgp files is equivalent to #defining INTEGRATED_GRAPHICS_COMPATIBILITY_MODE in your user-settings.h. Out of the box, user-settings.h is configured for maximum configurability and compatibility with dedicated nVidia and AMD/ATI GPU's. Compatibility mode is disabled by default to avoid silently degrading quality for AMD/ATI and nVidia users, so Intel- specific .cgp's are a convenient way for Intel users to play with the shader without editing text files. I've tested this solution on Intel HD 4000 graphics, and it should work for that GPU at least, but please let me know if you're still having problems! -------------------------------------------------------------------------------- 2.) WHY IS EVERYTHING SO SLOW?!?: Out of the box, this will be a problem for all but monster GPU's. The default user-settings.h file disables any features and optimizations which might cause compilation failure on AMD/ATI GPU's. Despite the name of the options, this is not a problem with your card or drivers; it's a shortcoming in the Cg shader compiler's nVidia-centric profile setups. Uncommenting the following #define macros at the top of user-settings.h will help performance a good deal on compatible nVidia cards: #define DRIVERS_ALLOW_DERIVATIVES #define DRIVERS_ALLOW_DYNAMIC_BRANCHES #define ACCOMODATE_POSSIBLE_DYNAMIC_LOOPS #define DRIVERS_ALLOW_TEX2DLOD #define DRIVERS_ALLOW_TEX2DBIAS A few of these warrant some elaboration. First, derivatives: Derivatives allow the shader to cheaply calculate a tangent-space matrix for correct antialiasing when curvature or overscan are used. Without them, there are two options: a.) Cheat, and there will be artifacts with strong cylindrical curvature b.) Compute the correct tangent-space matrix analytically. This is used by default, and it's controlled by this option near the bottom: geom_force_correct_tangent_matrix = true Dynamic branches: Dynamic branches allow the shader to avoid performing computations that it doesn't need (but might have, given different runtime options). Without them, the shader has to either let the GPU evaluate every possible codepath and select a result, or make a "best guess" ahead of time. The full phosphor bloom suffers most from not having dynamic branches, because the shader doesn't know how big of a blur to use until it knows your phosphor mask dot pitch...which you set at runtime if shader parameters are enabled. If RUNTIME_PHOSPHOR_BLOOM_SIGMA is commented out (faster), this won't matter: The shader will just select the blur size and standard deviation suitable for the mask_triad_size_desired_static setting in user-settings.cgp. It will be fast, but larger triads won't blur enough, and smaller triads will blur more than they need to. However, if RUNTIME_PHOSPHOR_BLOOM_SIGMA is enabled, the shader will calculate an optimal standard deviation and *try* to use the right blur size for it...but using an "if standard deviation