mac 小霸王游戏/红白机/街机模拟器 OpenEmu
立即下载
资源介绍:
mac 小霸王游戏/红白机/街机模拟器 OpenEmu
////////////////////////////////////////////////////////////////////////////////
//// crt-royale, by TroggleMonkey ////
//// 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
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
资源文件列表:
OpenEmu_2.4.1.zip 大约有1168个文件