Please show off what crt shaders can do!

I tested on a 1080p screen in 720p I did not see the difference jpeg png and it did not look like my basic preset, then I tested on my screen 4k with a resolution changed to 720p in the parameters, and well even if it’s blurred I see the difference haha ​​so one day you can test it :stuck_out_tongue: then my preset first change levels_autodim_temp = 1.0 ‘user-settings.h’ in crt-royale and uncomment #define RUNTIME_ANTIALIAS_SUBPIXEL_OFFSETS or i will post my user settings and maybe you need to change lcd_gamma on preset to 1.40 ,2.2 on my screen is wrong only in this shader so i’m not sure and change directory too

shaders = "12"
shader0 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-first-pass-linearize-crt-gamma-bob-fields.slang"
filter_linear0 = "false"
wrap_mode0 = "clamp_to_border"
mipmap_input0 = "false"
alias0 = "ORIG_LINEARIZED"
float_framebuffer0 = "false"
srgb_framebuffer0 = "true"
scale_type_x0 = "source"
scale_x0 = "1.000000"
scale_type_y0 = "source"
scale_y0 = "1.000000"
shader1 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-scanlines-vertical-interlacing.slang"
filter_linear1 = "true"
wrap_mode1 = "clamp_to_border"
mipmap_input1 = "false"
alias1 = "VERTICAL_SCANLINES"
float_framebuffer1 = "false"
srgb_framebuffer1 = "true"
scale_type_x1 = "source"
scale_x1 = "1.000000"
scale_type_y1 = "viewport"
scale_y1 = "1.000000"
shader2 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-bloom-approx.slang"
filter_linear2 = "true"
wrap_mode2 = "clamp_to_border"
mipmap_input2 = "false"
alias2 = "BLOOM_APPROX"
float_framebuffer2 = "false"
srgb_framebuffer2 = "true"
scale_type_x2 = "source"
scale_x2 = "1.000000"
scale_type_y2 = "source"
scale_y2 = "1.000000"
shader3 = "D:\RetroArch\shaders\shaders_slang\blurs\blur9fast-vertical.slang"
filter_linear3 = "true"
wrap_mode3 = "clamp_to_border"
mipmap_input3 = "false"
alias3 = ""
float_framebuffer3 = "false"
srgb_framebuffer3 = "true"
scale_type_x3 = "source"
scale_x3 = "1.000000"
scale_type_y3 = "source"
scale_y3 = "1.000000"
shader4 = "D:\RetroArch\shaders\shaders_slang\blurs\blur9fast-horizontal.slang"
filter_linear4 = "true"
wrap_mode4 = "clamp_to_border"
mipmap_input4 = "false"
alias4 = "HALATION_BLUR"
float_framebuffer4 = "false"
srgb_framebuffer4 = "true"
scale_type_x4 = "source"
scale_x4 = "1.000000"
scale_type_y4 = "source"
scale_y4 = "1.000000"
shader5 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-mask-resize-vertical.slang"
filter_linear5 = "true"
wrap_mode5 = "clamp_to_border"
mipmap_input5 = "false"
alias5 = ""
float_framebuffer5 = "false"
srgb_framebuffer5 = "false"
scale_type_x5 = "absolute"
scale_x5 = "64"
scale_type_y5 = "viewport"
scale_y5 = "0.062500"
shader6 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-mask-resize-horizontal.slang"
filter_linear6 = "false"
wrap_mode6 = "clamp_to_border"
mipmap_input6 = "false"
alias6 = "MASK_RESIZE"
float_framebuffer6 = "false"
srgb_framebuffer6 = "false"
scale_type_x6 = "viewport"
scale_x6 = "0.062500"
scale_type_y6 = "source"
scale_y6 = "1.000000"
shader7 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-scanlines-horizontal-apply-mask.slang"
filter_linear7 = "true"
wrap_mode7 = "clamp_to_border"
mipmap_input7 = "false"
alias7 = "MASKED_SCANLINES"
float_framebuffer7 = "false"
srgb_framebuffer7 = "true"
scale_type_x7 = "viewport"
scale_x7 = "1.000000"
scale_type_y7 = "viewport"
scale_y7 = "1.000000"
shader8 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-brightpass.slang"
filter_linear8 = "true"
wrap_mode8 = "clamp_to_border"
mipmap_input8 = "false"
alias8 = "BRIGHTPASS"
float_framebuffer8 = "false"
srgb_framebuffer8 = "true"
scale_type_x8 = "viewport"
scale_x8 = "1.000000"
scale_type_y8 = "viewport"
scale_y8 = "1.000000"
shader9 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-bloom-vertical.slang"
filter_linear9 = "true"
wrap_mode9 = "clamp_to_border"
mipmap_input9 = "false"
alias9 = ""
float_framebuffer9 = "false"
srgb_framebuffer9 = "true"
scale_type_x9 = "source"
scale_x9 = "1.000000"
scale_type_y9 = "source"
scale_y9 = "1.000000"
shader10 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-bloom-horizontal-reconstitute.slang"
filter_linear10 = "true"
wrap_mode10 = "clamp_to_border"
mipmap_input10 = "false"
alias10 = ""
float_framebuffer10 = "false"
srgb_framebuffer10 = "true"
scale_type_x10 = "source"
scale_x10 = "1.000000"
scale_type_y10 = "source"
scale_y10 = "1.000000"
shader11 = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\src\crt-royale-geometry-aa-last-pass.slang"
filter_linear11 = "true"
wrap_mode11 = "clamp_to_border"
mipmap_input11 = "true"
alias11 = ""
float_framebuffer11 = "false"
srgb_framebuffer11 = "false"
scale_type_x11 = "viewport"
scale_x11 = "1.000000"
scale_type_y11 = "viewport"
scale_y11 = "1.000000"
parameters = "crt_gamma;lcd_gamma;levels_contrast;halation_weight;diffusion_weight;bloom_underestimate_levels;bloom_excess;beam_min_sigma;beam_max_sigma;beam_spot_power;beam_min_shape;beam_max_shape;beam_shape_power;beam_horiz_filter;beam_horiz_sigma;beam_horiz_linear_rgb_weight;convergence_offset_x_r;convergence_offset_x_g;convergence_offset_x_b;convergence_offset_y_r;convergence_offset_y_g;convergence_offset_y_b;mask_type;mask_sample_mode_desired;mask_specify_num_triads;mask_triad_size_desired;mask_num_triads_desired;aa_subpixel_r_offset_x_runtime;aa_subpixel_r_offset_y_runtime;aa_cubic_c;aa_gauss_sigma;geom_mode_runtime;geom_radius;geom_view_dist;geom_tilt_angle_x;geom_tilt_angle_y;geom_aspect_ratio_x;geom_aspect_ratio_y;geom_overscan_x;geom_overscan_y;border_size;border_darkness;border_compress;interlace_bff;interlace_1080i"
crt_gamma = "2.600000"
lcd_gamma = "1.800000"
levels_contrast = "1.000000"
halation_weight = "0.000000"
diffusion_weight = "0.000000"
bloom_underestimate_levels = "0.800000"
bloom_excess = "0.000000"
beam_min_sigma = "0.245000"
beam_max_sigma = "0.005000"
beam_spot_power = "0.010000"
beam_min_shape = "2.000000"
beam_max_shape = "2.000000"
beam_shape_power = "0.010000"
beam_horiz_filter = "1.000000"
beam_horiz_sigma = "0.350000"
beam_horiz_linear_rgb_weight = "1.000000"
convergence_offset_x_r = "0.000000"
convergence_offset_x_g = "0.000000"
convergence_offset_x_b = "0.000000"
convergence_offset_y_r = "0.000000"
convergence_offset_y_g = "0.000000"
convergence_offset_y_b = "0.000000"
mask_type = "0.000000"
mask_sample_mode_desired = "0.000000"
mask_specify_num_triads = "0.000000"
mask_triad_size_desired = "3.000000"
mask_num_triads_desired = "480.000000"
aa_subpixel_r_offset_x_runtime = "0.000000"
aa_subpixel_r_offset_y_runtime = "0.000000"
aa_cubic_c = "4.000000"
aa_gauss_sigma = "1.000000"
geom_mode_runtime = "0.000000"
geom_radius = "2.000000"
geom_view_dist = "2.000000"
geom_tilt_angle_x = "0.000000"
geom_tilt_angle_y = "0.000000"
geom_aspect_ratio_x = "432.000000"
geom_aspect_ratio_y = "329.000000"
geom_overscan_x = "1.000000"
geom_overscan_y = "1.000000"
border_size = "0.000000"
border_darkness = "0.000000"
border_compress = "1.000000"
interlace_bff = "0.000000"
interlace_1080i = "0.000000"
textures = "mask_grille_texture_small;mask_grille_texture_large;mask_slot_texture_small;mask_slot_texture_large;mask_shadow_texture_small;mask_shadow_texture_large"
mask_grille_texture_small = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\TileableLinearApertureGrille15Wide8And5d5SpacingResizeTo64.png"
mask_grille_texture_small_linear = "true"
mask_grille_texture_small_wrap_mode = "repeat"
mask_grille_texture_small_mipmap = "false"
mask_grille_texture_large = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\TileableLinearApertureGrille15Wide8And5d5Spacing.png"
mask_grille_texture_large_linear = "true"
mask_grille_texture_large_wrap_mode = "repeat"
mask_grille_texture_large_mipmap = "true"
mask_slot_texture_small = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\TileableLinearSlotMaskTall15Wide9And4d5Horizontal9d14VerticalSpacingResizeTo64.png"
mask_slot_texture_small_linear = "true"
mask_slot_texture_small_wrap_mode = "repeat"
mask_slot_texture_small_mipmap = "false"
mask_slot_texture_large = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\TileableLinearSlotMaskTall15Wide9And4d5Horizontal9d14VerticalSpacing.png"
mask_slot_texture_large_linear = "true"
mask_slot_texture_large_wrap_mode = "repeat"
mask_slot_texture_large_mipmap = "true"
mask_shadow_texture_small = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\TileableLinearShadowMaskEDPResizeTo64.png"
mask_shadow_texture_small_linear = "true"
mask_shadow_texture_small_wrap_mode = "repeat"
mask_shadow_texture_small_mipmap = "false"
mask_shadow_texture_large = "D:\RetroArch\shaders\shaders_slang\crt\shaders\crt-royale\TileableLinearShadowMaskEDP.png"
mask_shadow_texture_large_linear = "true"
mask_shadow_texture_large_wrap_mode = "repeat"
mask_shadow_texture_large_mipmap = "true"

sorry ouble posts characters limits

#ifndef USER_SETTINGS_H #define USER_SETTINGS_H

/////////////////////////////  DRIVER CAPABILITIES  ////////////////////////////

//  The Cg compiler uses different "profiles" with different capabilities.
//  This shader requires a Cg compilation profile >= arbfp1, but a few options
//  require higher profiles like fp30 or fp40.  The shader can't detect profile
//  or driver capabilities, so instead you must comment or uncomment the lines
//  below with "//" before "#define."  Disable an option if you get compilation
//  errors resembling those listed.  Generally speaking, all of these options
//  will run on nVidia cards, but only DRIVERS_ALLOW_TEX2DBIAS (if that) is
//  likely to run on ATI/AMD, due to the Cg compiler's profile limitations.

//  Derivatives: Unsupported on fp20, ps_1_1, ps_1_2, ps_1_3, and arbfp1.
//  Among other things, derivatives help us fix anisotropic filtering artifacts
//  with curved manually tiled phosphor mask coords.  Related errors:
//  error C3004: function "float2 ddx(float2);" not supported in this profile
//  error C3004: function "float2 ddy(float2);" not supported in this profile
    //#define DRIVERS_ALLOW_DERIVATIVES

//  Fine derivatives: Unsupported on older ATI cards.
//  Fine derivatives enable 2x2 fragment block communication, letting us perform
//  fast single-pass blur operations.  If your card uses coarse derivatives and
//  these are enabled, blurs could look broken.  Derivatives are a prerequisite.
    #ifdef DRIVERS_ALLOW_DERIVATIVES
        #define DRIVERS_ALLOW_FINE_DERIVATIVES
    #endif

//  Dynamic looping: Requires an fp30 or newer profile.
//  This makes phosphor mask resampling faster in some cases.  Related errors:
//  error C5013: profile does not support "for" statements and "for" could not
//  be unrolled
    //#define DRIVERS_ALLOW_DYNAMIC_BRANCHES

//  Without DRIVERS_ALLOW_DYNAMIC_BRANCHES, we need to use unrollable loops.
//  Using one static loop avoids overhead if the user is right, but if the user
//  is wrong (loops are allowed), breaking a loop into if-blocked pieces with a
//  binary search can potentially save some iterations.  However, it may fail:
//  error C6001: Temporary register limit of 32 exceeded; 35 registers
//  needed to compile program
    #define ACCOMODATE_POSSIBLE_DYNAMIC_LOOPS

//  tex2Dlod: Requires an fp40 or newer profile.  This can be used to disable
//  anisotropic filtering, thereby fixing related artifacts.  Related errors:
//  error C3004: function "float4 tex2Dlod(sampler2D, float4);" not supported in
//  this profile
    #define DRIVERS_ALLOW_TEX2DLOD

//  tex2Dbias: Requires an fp30 or newer profile.  This can be used to alleviate
//  artifacts from anisotropic filtering and mipmapping.  Related errors:
//  error C3004: function "float4 tex2Dbias(sampler2D, float4);" not supported
//  in this profile
    //#define DRIVERS_ALLOW_TEX2DBIAS

//  Integrated graphics compatibility: Integrated graphics like Intel HD 4000
//  impose stricter limitations on register counts and instructions.  Enable
//  INTEGRATED_GRAPHICS_COMPATIBILITY_MODE if you still see error C6001 or:
//  error C6002: Instruction limit of 1024 exceeded: 1523 instructions needed
//  to compile program.
//  Enabling integrated graphics compatibility mode will automatically disable:
//  1.) PHOSPHOR_MASK_MANUALLY_RESIZE: The phosphor mask will be softer.
//      (This may be reenabled in a later release.)
//  2.) RUNTIME_GEOMETRY_MODE
//  3.) The high-quality 4x4 Gaussian resize for the bloom approximation
    //#define INTEGRATED_GRAPHICS_COMPATIBILITY_MODE


////////////////////////////  USER CODEPATH OPTIONS  ///////////////////////////

//  To disable a #define option, turn its line into a comment with "//."

//  RUNTIME VS. COMPILE-TIME OPTIONS (Major Performance Implications):
//  Enable runtime shader parameters in the Retroarch (etc.) GUI?  They override
//  many of the options in this file and allow real-time tuning, but many of
//  them are slower.  Disabling them and using this text file will boost FPS.
#define RUNTIME_SHADER_PARAMS_ENABLE
//  Specify the phosphor bloom sigma at runtime?  This option is 10% slower, but
//  it's the only way to do a wide-enough full bloom with a runtime dot pitch.
#define RUNTIME_PHOSPHOR_BLOOM_SIGMA
//  Specify antialiasing weight parameters at runtime?  (Costs ~20% with cubics)
#define RUNTIME_ANTIALIAS_WEIGHTS
//  Specify subpixel offsets at runtime? (WARNING: EXTREMELY EXPENSIVE!)
#define RUNTIME_ANTIALIAS_SUBPIXEL_OFFSETS
//  Make beam_horiz_filter and beam_horiz_linear_rgb_weight into runtime shader
//  parameters?  This will require more math or dynamic branching.
#define RUNTIME_SCANLINES_HORIZ_FILTER_COLORSPACE
//  Specify the tilt at runtime?  This makes things about 3% slower.
#define RUNTIME_GEOMETRY_TILT
//  Specify the geometry mode at runtime?
#define RUNTIME_GEOMETRY_MODE
//  Specify the phosphor mask type (aperture grille, slot mask, shadow mask) and
//  mode (Lanczos-resize, hardware resize, or tile 1:1) at runtime, even without
//  dynamic branches?  This is cheap if mask_resize_viewport_scale is small.
#define FORCE_RUNTIME_PHOSPHOR_MASK_MODE_TYPE_SELECT

//  PHOSPHOR MASK:
//  Manually resize the phosphor mask for best results (slower)?  Disabling this
//  removes the option to do so, but it may be faster without dynamic branches.
    #define PHOSPHOR_MASK_MANUALLY_RESIZE
//  If we sinc-resize the mask, should we Lanczos-window it (slower but better)?
    //#define PHOSPHOR_MASK_RESIZE_LANCZOS_WINDOW
//  Larger blurs are expensive, but we need them to blur larger triads.  We can
//  detect the right blur if the triad size is static or our profile allows
//  dynamic branches, but otherwise we use the largest blur the user indicates
//  they might need:
    #define PHOSPHOR_BLOOM_TRIADS_LARGER_THAN_3_PIXELS
    #define PHOSPHOR_BLOOM_TRIADS_LARGER_THAN_6_PIXELS
    //#define PHOSPHOR_BLOOM_TRIADS_LARGER_THAN_9_PIXELS
    //#define PHOSPHOR_BLOOM_TRIADS_LARGER_THAN_12_PIXELS
    //  Here's a helpful chart:
    //  MaxTriadSize    BlurSize    MinTriadCountsByResolution
    //  3.0             9.0         480/640/960/1920 triads at 1080p/1440p/2160p/4320p, 4:3 aspect
    //  6.0             17.0        240/320/480/960 triads at 1080p/1440p/2160p/4320p, 4:3 aspect
    //  9.0             25.0        160/213/320/640 triads at 1080p/1440p/2160p/4320p, 4:3 aspect
    //  12.0            31.0        120/160/240/480 triads at 1080p/1440p/2160p/4320p, 4:3 aspect
    //  18.0            43.0        80/107/160/320 triads at 1080p/1440p/2160p/4320p, 4:3 aspect


///////////////////////////////  USER PARAMETERS  //////////////////////////////

//  Note: Many of these static parameters are overridden by runtime shader
//  parameters when those are enabled.  However, many others are static codepath
//  options that were cleaner or more convert to code as static constants.

//  GAMMA:
    static const float crt_gamma_static = 2.5;                  //  range [1, 5]
    static const float lcd_gamma_static = 2.2;                  //  range [1, 5]

//  LEVELS MANAGEMENT:
    //  Control the final multiplicative image contrast:
    static const float levels_contrast_static = 1.0;            //  range [0, 4)
    //  We auto-dim to avoid clipping between passes and restore brightness
    //  later.  Control the dim factor here: Lower values clip less but crush
    //  blacks more (static only for now).
    static const float levels_autodim_temp = 1.0;               //  range (0, 1]

//  HALATION/DIFFUSION/BLOOM:
    //  Halation weight: How much energy should be lost to electrons bounding
    //  around under the CRT glass and exciting random phosphors?
    static const float halation_weight_static = 0.0;            //  range [0, 1]
    //  Refractive diffusion weight: How much light should spread/diffuse from
    //  refracting through the CRT glass?
    static const float diffusion_weight_static = 0.075;         //  range [0, 1]
    //  Underestimate brightness: Bright areas bloom more, but we can base the
    //  bloom brightpass on a lower brightness to sharpen phosphors, or a higher
    //  brightness to soften them.  Low values clip, but >= 0.8 looks okay.
    static const float bloom_underestimate_levels_static = 0.8; //  range [0, 5]
    //  Blur all colors more than necessary for a softer phosphor bloom?
    static const float bloom_excess_static = 0.0;               //  range [0, 1]
    //  The BLOOM_APPROX pass approximates a phosphor blur early on with a small
    //  blurred resize of the input (convergence offsets are applied as well).
    //  There are three filter options (static option only for now):
    //  0.) Bilinear resize: A fast, close approximation to a 4x4 resize
    //      if min_allowed_viewport_triads and the BLOOM_APPROX resolution are sane
    //      and beam_max_sigma is low.
    //  1.) 3x3 resize blur: Medium speed, soft/smeared from bilinear blurring,
    //      always uses a static sigma regardless of beam_max_sigma or
    //      mask_num_triads_desired.
    //  2.) True 4x4 Gaussian resize: Slowest, technically correct.
    //  These options are more pronounced for the fast, unbloomed shader version.
#ifndef RADEON_FIX
    static const float bloom_approx_filter_static = 2.0;
#else
    static const float bloom_approx_filter_static = 2.0;
#endif

//  ELECTRON BEAM SCANLINE DISTRIBUTION:
    //  How many scanlines should contribute light to each pixel?  Using more
    //  scanlines is slower (especially for a generalized Gaussian) but less
    //  distorted with larger beam sigmas (especially for a pure Gaussian).  The
    //  max_beam_sigma at which the closest unused weight is guaranteed <
    //  1.0/255.0 (for a 3x antialiased pure Gaussian) is:
    //      2 scanlines: max_beam_sigma = 0.2089; distortions begin ~0.34; 141.7 FPS pure, 131.9 FPS generalized
    //      3 scanlines, max_beam_sigma = 0.3879; distortions begin ~0.52; 137.5 FPS pure; 123.8 FPS generalized
    //      4 scanlines, max_beam_sigma = 0.5723; distortions begin ~0.70; 134.7 FPS pure; 117.2 FPS generalized
    //      5 scanlines, max_beam_sigma = 0.7591; distortions begin ~0.89; 131.6 FPS pure; 112.1 FPS generalized
    //      6 scanlines, max_beam_sigma = 0.9483; distortions begin ~1.08; 127.9 FPS pure; 105.6 FPS generalized
    static const float beam_num_scanlines = 3.0;                //  range [2, 6]
    //  A generalized Gaussian beam varies shape with color too, now just width.
    //  It's slower but more flexible (static option only for now).
    static const bool beam_generalized_gaussian = true;
    //  What kind of scanline antialiasing do you want?
    //  0: Sample weights at 1x; 1: Sample weights at 3x; 2: Compute an integral
    //  Integrals are slow (especially for generalized Gaussians) and rarely any
    //  better than 3x antialiasing (static option only for now).
    static const float beam_antialias_level = 2.0;              //  range [0, 2]
    //  Min/max standard deviations for scanline beams: Higher values widen and
    //  soften scanlines.  Depending on other options, low min sigmas can alias.
    static const float beam_min_sigma_static = 0.02;            //  range (0, 1]
    static const float beam_max_sigma_static = 0.3;             //  range (0, 1]
    //  Beam width varies as a function of color: A power function (0) is more
    //  configurable, but a spherical function (1) gives the widest beam
    //  variability without aliasing (static option only for now).
    static const float beam_spot_shape_function = 0.0;
    //  Spot shape power: Powers <= 1 give smoother spot shapes but lower
    //  sharpness.  Powers >= 1.0 are awful unless mix/max sigmas are close.
    static const float beam_spot_power_static = 1.0/3.0;    //  range (0, 16]
    //  Generalized Gaussian max shape parameters: Higher values give flatter
    //  scanline plateaus and steeper dropoffs, simultaneously widening and
    //  sharpening scanlines at the cost of aliasing.  2.0 is pure Gaussian, and
    //  values > ~40.0 cause artifacts with integrals.
    static const float beam_min_shape_static = 2.0;         //  range [2, 32]
    static const float beam_max_shape_static = 4.0;         //  range [2, 32]
    //  Generalized Gaussian shape power: Affects how quickly the distribution
    //  changes shape from Gaussian to steep/plateaued as color increases from 0
    //  to 1.0.  Higher powers appear softer for most colors, and lower powers
    //  appear sharper for most colors.
    static const float beam_shape_power_static = 1.0/4.0;   //  range (0, 16]
    //  What filter should be used to sample scanlines horizontally?
    //  0: Quilez (fast), 1: Gaussian (configurable), 2: Lanczos2 (sharp)
    static const float beam_horiz_filter_static = 0.0;
    //  Standard deviation for horizontal Gaussian resampling:
    static const float beam_horiz_sigma_static = 0.35;      //  range (0, 2/3]
    //  Do horizontal scanline sampling in linear RGB (correct light mixing),
    //  gamma-encoded RGB (darker, hard spot shape, may better match bandwidth-
    //  limiting circuitry in some CRT's), or a weighted avg.?
    static const float beam_horiz_linear_rgb_weight_static = 1.0;   //  range [0, 1]
    //  Simulate scanline misconvergence?  This needs 3x horizontal texture
    //  samples and 3x texture samples of BLOOM_APPROX and HALATION_BLUR in
    //  later passes (static option only for now).
    static const bool beam_misconvergence = true;
    //  Convergence offsets in x/y directions for R/G/B scanline beams in units
    //  of scanlines.  Positive offsets go right/down; ranges [-2, 2]
    static const float2 convergence_offsets_r_static = float2(0.1, 0.2);
    static const float2 convergence_offsets_g_static = float2(0.3, 0.4);
    static const float2 convergence_offsets_b_static = float2(0.5, 0.6);
    //  Detect interlacing (static option only for now)?
    static const bool interlace_detect = false;
    //  Assume 1080-line sources are interlaced?
    static const bool interlace_1080i_static = false;
    //  For interlaced sources, assume TFF (top-field first) or BFF order?
    //  (Whether this matters depends on the nature of the interlaced input.)
    static const bool interlace_bff_static = false;

//  ANTIALIASING:
    //  What AA level do you want for curvature/overscan/subpixels?  Options:
    //  0x (none), 1x (sample subpixels), 4x, 5x, 6x, 7x, 8x, 12x, 16x, 20x, 24x
    //  (Static option only for now)
    static const float aa_level = 24.0;                     //  range [0, 24]
    //  What antialiasing filter do you want (static option only)?  Options:
    //  0: Box (separable), 1: Box (cylindrical),
    //  2: Tent (separable), 3: Tent (cylindrical),
    //  4: Gaussian (separable), 5: Gaussian (cylindrical),
    //  6: Cubic* (separable), 7: Cubic* (cylindrical, poor)
    //  8: Lanczos Sinc (separable), 9: Lanczos Jinc (cylindrical, poor)
    //      * = Especially slow with RUNTIME_ANTIALIAS_WEIGHTS
    static const float aa_filter = 6.0;                     //  range [0, 9]
    //  Flip the sample grid on odd/even frames (static option only for now)?
    static const bool aa_temporal = false;
    //  Use RGB subpixel offsets for antialiasing?  The pixel is at green, and
    //  the blue offset is the negative r offset; range [0, 0.5]
    static const float2 aa_subpixel_r_offset_static = float2(-1.0/3.0, 0.0);//float2(0.0);
    //  Cubics: See http://www.imagemagick.org/Usage/filter/#mitchell
    //  1.) "Keys cubics" with B = 1 - 2C are considered the highest quality.
    //  2.) C = 0.5 (default) is Catmull-Rom; higher C's apply sharpening.
    //  3.) C = 1.0/3.0 is the Mitchell-Netravali filter.
    //  4.) C = 0.0 is a soft spline filter.
    static const float aa_cubic_c_static = 0.5;             //  range [0, 4]
    //  Standard deviation for Gaussian antialiasing: Try 0.5/aa_pixel_diameter.
    static const float aa_gauss_sigma_static = 0.5;     //  range [0.0625, 1.0]

//  PHOSPHOR MASK:
    //  Mask type: 0 = aperture grille, 1 = slot mask, 2 = EDP shadow mask
    static const float mask_type_static = 1.0;                  //  range [0, 2]
    //  We can sample the mask three ways.  Pick 2/3 from: Pretty/Fast/Flexible.
    //  0.) Sinc-resize to the desired dot pitch manually (pretty/slow/flexible).
    //      This requires PHOSPHOR_MASK_MANUALLY_RESIZE to be #defined.
    //  1.) Hardware-resize to the desired dot pitch (ugly/fast/flexible).  This
    //      is halfway decent with LUT mipmapping but atrocious without it.
    //  2.) Tile it without resizing at a 1:1 texel:pixel ratio for flat coords
    //      (pretty/fast/inflexible).  Each input LUT has a fixed dot pitch.
    //      This mode reuses the same masks, so triads will be enormous unless
    //      you change the mask LUT filenames in your .cgp file.
    static const float mask_sample_mode_static = 0.0;           //  range [0, 2]
    //  Prefer setting the triad size (0.0) or number on the screen (1.0)?
    //  If RUNTIME_PHOSPHOR_BLOOM_SIGMA isn't #defined, the specified triad size
    //  will always be used to calculate the full bloom sigma statically.
    static const float mask_specify_num_triads_static = 0.0;    //  range [0, 1]
    //  Specify the phosphor triad size, in pixels.  Each tile (usually with 8
    //  triads) will be rounded to the nearest integer tile size and clamped to
    //  obey minimum size constraints (imposed to reduce downsize taps) and
    //  maximum size constraints (imposed to have a sane MASK_RESIZE FBO size).
    //  To increase the size limit, double the viewport-relative scales for the
    //  two MASK_RESIZE passes in crt-royale.cgp and user-cgp-contants.h.
    //      range [1, mask_texture_small_size/mask_triads_per_tile]
    static const float mask_triad_size_desired_static = 24.0 / 8.0;
    //  If mask_specify_num_triads is 1.0/true, we'll go by this instead (the
    //  final size will be rounded and constrained as above); default 480.0
    static const float mask_num_triads_desired_static = 480.0;
    //  How many lobes should the sinc/Lanczos resizer use?  More lobes require
    //  more samples and avoid moire a bit better, but some is unavoidable
    //  depending on the destination size (static option for now).
    static const float mask_sinc_lobes = 2.0;                   //  range [2, 4]
    //  The mask is resized using a variable number of taps in each dimension,
    //  but some Cg profiles always fetch a constant number of taps no matter
    //  what (no dynamic branching).  We can limit the maximum number of taps if
    //  we statically limit the minimum phosphor triad size.  Larger values are
    //  faster, but the limit IS enforced (static option only, forever);
    //      range [1, mask_texture_small_size/mask_triads_per_tile]
    //  TODO: Make this 1.0 and compensate with smarter sampling!
    static const float mask_min_allowed_triad_size = 1.0;

//  GEOMETRY:
    //  Geometry mode:
    //  0: Off (default), 1: Spherical mapping (like cgwg's),
    //  2: Alt. spherical mapping (more bulbous), 3: Cylindrical/Trinitron
    static const float geom_mode_static = 0.0;      //  range [0, 3]
    //  Radius of curvature: Measured in units of your viewport's diagonal size.
    static const float geom_radius_static = 2.0;    //  range [1/(2*pi), 1024]
    //  View dist is the distance from the player to their physical screen, in
    //  units of the viewport's diagonal size.  It controls the field of view.
    static const float geom_view_dist_static = 2.0; //  range [0.5, 1024]
    //  Tilt angle in radians (clockwise around up and right vectors):
    static const float2 geom_tilt_angle_static = float2(0.0, 0.0);  //  range [-pi, pi]
    //  Aspect ratio: When the true viewport size is unknown, this value is used
    //  to help convert between the phosphor triad size and count, along with
    //  the mask_resize_viewport_scale constant from user-cgp-constants.h.  Set
    //  this equal to Retroarch's display aspect ratio (DAR) for best results;
    //  range [1, geom_max_aspect_ratio from user-cgp-constants.h];
    //  default (256/224)*(54/47) = 1.313069909 (see below)
    static const float geom_aspect_ratio_static = 1.330000000;
    //  Before getting into overscan, here's some general aspect ratio info:
    //  - DAR = display aspect ratio = SAR * PAR; as in your Retroarch setting
    //  - SAR = storage aspect ratio = DAR / PAR; square pixel emulator frame AR
    //  - PAR = pixel aspect ratio   = DAR / SAR; holds regardless of cropping
    //  Geometry processing has to "undo" the screen-space 2D DAR to calculate
    //  3D view vectors, then reapplies the aspect ratio to the simulated CRT in
    //  uv-space.  To ensure the source SAR is intended for a ~4:3 DAR, either:
    //  a.) Enable Retroarch's "Crop Overscan"
    //  b.) Readd horizontal padding: Set overscan to e.g. N*(1.0, 240.0/224.0)
    //  Real consoles use horizontal black padding in the signal, but emulators
    //  often crop this without cropping the vertical padding; a 256x224 [S]NES
    //  frame (8:7 SAR) is intended for a ~4:3 DAR, but a 256x240 frame is not.
    //  The correct [S]NES PAR is 54:47, found by blargg and NewRisingSun:
    //      http://board.zsnes.com/phpBB3/viewtopic.php?f=22&t=11928&start=50
    //      http://forums.nesdev.com/viewtopic.php?p=24815#p24815
    //  For flat output, it's okay to set DAR = [existing] SAR * [correct] PAR
    //  without doing a. or b., but horizontal image borders will be tighter
    //  than vertical ones, messing up curvature and overscan.  Fixing the
    //  padding first corrects this.
    //  Overscan: Amount to "zoom in" before cropping.  You can zoom uniformly
    //  or adjust x/y independently to e.g. readd horizontal padding, as noted
    //  above: Values < 1.0 zoom out; range (0, inf)
    static const float2 geom_overscan_static = float2(1.0, 1.0);// * 1.005 * (1.0, 240/224.0)
    //  Compute a proper pixel-space to texture-space matrix even without ddx()/
    //  ddy()?  This is ~8.5% slower but improves antialiasing/subpixel filtering
    //  with strong curvature (static option only for now).
    static const bool geom_force_correct_tangent_matrix = false;

//  BORDERS:
    //  Rounded border size in texture uv coords:
    static const float border_size_static = 0.015;           //  range [0, 0.5]
    //  Border darkness: Moderate values darken the border smoothly, and high
    //  values make the image very dark just inside the border:
    static const float border_darkness_static = 2.0;        //  range [0, inf)
    //  Border compression: High numbers compress border transitions, narrowing
    //  the dark border area.
    static const float border_compress_static = 2.5;        //  range [1, inf)


#endif  //  USER_SETTINGS_H

@Dogway sure i know that but why you tell me that lol ? it was a discussion between @Nesguy and @Squalo ,i think you missclicked on your reply,it wasn’t me who did color work and i paste a message from another guy,but thanks :yum:

Hi

Thank you for the settings I find them really nice. For me in my eyes they are a bit better than the shader crt-guest-dr-venom for systems 16bits (snes & genesis). I still prefer crt-guest-dr-venom for arcade games (cps-1 - cps-2)

It is true that with your parameters it is necessary to “push” the light to the max. With my 1080p Iiyama computer screen it looks better than my old Samsung LCD TV (10 years old 1080p) but I think the light or the contrast is missing.

On Sonic 1, I find your settings really nice against F-zero or I think the colors are more faded probably because of lack of light or contrast (for me).

Now if it would be possible to add to your chain a kind of “bright boost” and “contrast boost” and of course the screen curvature you get in my opinion one of the best chain that was made

I do not know how far you can go in the emulation of CRT screen with the shaders but I think that your chain and that of crt-guest-dr-venom are for me the new generation and the way to go .

Honestly is it worthwhile today to buy a 4K TV for retrogaming and shaders or is it better to wait again.

Thank you

1 Like

Yeah, a 10+ year old LCD won’t be able to get bright enough with the settings I posted. Pretty much any LED-lit LCD made in the last 5-6 years should be sufficient, though.

If you want a brighter image without increasing the display backlight, the options are:

-increase the contrast of the image (resulting in clipping and color shifts),

-increase the black level (resulting in crushed blacks and reducing the contrast ratio),

-increase the contrast of the mask (washing out the phosphors and the resulting image),

-lower the mask and/or scanlines strength (which makes the image look too blurry/smooth when any blur is applied, or too sharp if no blur is applied).

All of these, while giving you a brighter image, compromise the image quality in other ways. So it’s really a matter of personal preference what things are important to you and what things you’re willing to compromise on. On my gaming LCD (purchased 2015), I’m reaching probably ~95% of the peak brightness of a CRT with my backlight adjusted to 100% with the settings I posted, which I find to be completely acceptable in a dim room. It gets washed out very easily if there’s a lot of ambient light, but the same thing happens with CRTs.

“image-adjustment” can be useful for making changes to contrast, black level and saturation. “Color mangler”, which we’ve been discussing in this thread recently, can also be useful. I’m sure there are others that I’m failing to mention.

The biggest gain you get from going to 4k with shaders is an increase in mask detail/resolution, allowing you to emulate a low-res CRT (360 TVL) or a high-res CRT (720 TVL). You can also get quite a bit more scanline beam width variation at 4k since you have more vertical area to work with per pixel.

I’m honestly more excited about HDR and brighter displays than I am about 4k, but they tend to go together.

I don’t see this as being completely subjective, necessarily. Rather, this is one of those things which is objective, but also difficult (if not impossible) to define/measure. I think the most we can do when it comes to this subject is define an acceptable range, and so personal preference comes into play. I think that finding a single “correct” color balance for all games is either impossible or too difficult to be worth the headache, personally. This is why I’m happy to just slightly boost the blue channel on my display and call it a day.

Looking at post 372, I do think the corrected shot is an improvement over the defaults in some respects, but the greens look somewhat washed out in comparison to the Trinitron (but now we know, thanks to Dr. Venom, that it’s impossible to match those greens on an sRGB display).

Yeah, that looks pretty good. I was referring to an earlier shot where there were clearly some misaligned scanlines, but whether that’s due to your settings or how the image appears on my display, I’m not sure. It may seem that I’m overly picky about scanlines, but if they aren’t perfectly consistent it can result in some moire-like patterns that are almost nausea-inducing for me (I literally start to feel dizzy after a short time).

Hmm actually it’s quite simple. White should look white. That’s the objective, measurable part of it. From there onwards, all else comes down to taste. But if your whites are not white, you are doing something wrong. In that particular case (post 372), matching those greens was (or would be, if you don’t think they look the same) a piece of cake, since everything is being displayed on digital screens. What Dr Venom said doesn’t apply here. In order to perceive his findings you would have to compare a crt and an lcd side by side.

About bad scanlines, idk… maybe the reshade ones.

If the goal is to just get whites to look white, whites look white on my display just using the srgb calibrated profile… :neutral_face:

I thought the point was to match CRT colors? I’m sure it’s possible to match the photo with more fiddling, but it’s not something I’m losing sleep over. Carry on, though.

I agree, @scorpius.milo!

What is missing from the guest’s shader is the 256px and 320px composite video option.

This is a super-busy thread - having trouble tracking down how you got these color changes. The difference is nothing short of stunning. Can you point me in the right direction?

2 Likes

@SkyHighGam3r

target_gamma = "2.200000"
monitor_gamma = "2.200000"
overscan_percent_x = "0.000000"
overscan_percent_y = "0.000000"
saturation = "0.950000"
contrast = "1.050000"
luminance = "0.920000"
black_level = "-0.040000"
bright_boost = "-0.025000"
R = "0.970000"
G = "0.970000"
B = "1.030000"
ZOOM = "1.000000"
XPOS = "0.000000"
YPOS = "0.000000"
V_OSMASK = "0.000000"
H_OSMASK = "0.000000"
gamma_boost_r = "0.400000"
gamma_boost_g = "0.400000"
gamma_boost_b = "0.400000"
sat_r = "1.000000"
sat_g = "1.000000"
sat_b = "1.000000"
lum = "1.000000"
cntrst = "1.000000"
r = "1.000000"
g = "1.000000"
b = "1.000000"
rg = "0.000000"
rb = "0.000000"
gr = "0.000000"
gb = "0.150000"
br = "0.000000"
bg = "0.050000"
blr = "0.000000"
blg = "0.000000"
blb = "0.000000"

These are the settings he posted to me after I :sob: about it, lol.

Which seems to be image-adjustment and a modified version of color-mangler.

2 Likes

Honestly, the second image looks like a simple color profile change on an lcd monitor’s color profile settings from “Warm” to “Cool”.

This is what I did on my arcade cabinet monitor and many of the games now (Especially Super Contra) look more correct. I just leave my monitor on this setting now.

Just a reminder, the thickness of the scanlines can’t be the same when you are on a monitor close to your face compared to a far away TV, I have different shader settings for these 2 situations

@SkyHighGam3r yeah big difference isn’t it! The settings I posted for Syh are good for Cadillacs (in fact they look better than the image I published, slightly brighter and more saturated) and also for many other too bright + yellow arcade games. If things get too dark after applying them (Cadillacs at default is really hot, it clips massively) simply bring gamma_boost (from color mangler) and luminance (from i.a) back to 0-ish.

@trnzaddict actually no, it’s not that simple. I have explained this a few times already but it is indeed a busy thread so here it goes again: when you change the overall white point all colours are shifted, and I don’t want reds pushed towards magenta. To make a long story short, I noticed that emulated games on lcds have an ugly yellow cast to them, something that I don’t see on crts. They produce a cooler image but still output bright, warm reds, which I like.

So basically what you want to do is shift the green channel towards blue, and leave red more or less alone (although I like pushing it a bit towards green sometimes). The color mangler shader in its current form is the best way to do that, since with it you can make adjustments per channel. Per channel is the key here.

More convoluted than simply changing the overall temperature of the image, but much better results imo. Please see post #372. The corrected image has actually white clouds and nice cool greens while keeping reds punchy and warm, just like in the Sony Trinitron capture, which is a great reference. Changing the color profile at monitor level is not a good solution, especially if you have a carefully calibrated screen (my case). For you it makes more sense, since it sounds like you have a separate monitor for playing old games :+1:t3:

3 Likes

That’s what I did, too, and I think it’s definitely an improvement after allowing your eyes to adjust. Can’t argue with the fact that 9300k was the standard for NTSC-J.

I also think you just have to accept that the colors aren’t going to match those on a CRT arcade monitor no matter what you do. Even getting a CRT TV to look like a CRT arcade monitor is a pretty big challenge.

In general, I don’t like things that require a lot of fiddling, so I gave up on color mangler after playing with it for a bit. It just seems like a lot of fiddling for a marginal improvement in quality vs a simple color temp change.

I may at some point actually calibrate this monitor to 9300k since the profiles that come with most monitors can be pretty bad, in my experience.

1 Like

Ah…that’s true but I do not use RA on my cabinet; so it’s not possible to run these color mangler shaders. I use Groovymame with a G-Sync monitor, so simply changing my color profile is the only option for me to get the colors this way across all my games.

I don’t have to. And if you feel like you do, then you will also have to accept that scanlines, shadowmasks, motion resolution and a long etc aren’t going to match those on a crt no matter what you do. But accepting limitations and calling it a day is not what we are trying to do here is it.

gb = “0.150000”. So much fiddling :roll_eyes:

Not saying that you should change your ways of course, but if you want to try, it is most certainly doable outside the realm of retroarch, via reshade’s color matrix. That (combined with the crt-lottes port and a few other shaders) is what I use for standalone emulators.

Yes, really old version of mame, but smooth_mame_plus is wonderful, even more so nowadays thanks to RTSS and its low-lag scanline sync feature (in short, poor man’s GSync) and that’s the last version of it, probably ever… a story for another time and place.

According to Dr. Venom, who appears to be a lot more knowledgeable about this subject than either of us- yes, you do. You’re never going to match the colors on an arcade CRT with an LCD. Even matching an arcade CRT with a CRT TV is a stretch. But by all means, carry on.

I wouldn’t say that scanlines, masks, and motion resolution aren’t going to match those on a CRT no matter what you do. In fact, the aperture grille effect at 1080p does pretty much exactly what a 360 TVL CRT does when you max it out as I’ve been doing, and the scanlines are as good as those on any of the consumer Trinitrons I’ve owned over the years. The only major difference is the RGB values of the individual phosphors, which can’t ever hope to exactly match those on an arcade CRT. Motion resolution on LCDs has largely been solved by black frame insertion. It’s the colors and the emissive nature of the phosphors that you can’t ever match on an LCD. An LCD is never going to be an exact match for a CRT and there is something to be said for accepting when something is good enough.

You can continue to obsess over minutiae and chase the developer’s intentions to your heart’s content, no one is stopping you. That’s what we do around here.

These color settings are display-specific and can’t be universally applied. What looks good to you on your display isn’t going to work for everyone else.

I’m not sure where the generally hostile and combative tone is coming from, frankly. Maybe you think I’m disagreeing with you even after I acknowledged that the cooler colors are an improvement after allowing your eyes to adjust. Is it completely wrong unless we do things your way? It’s a lot easier for me to just increase the blue channel slightly and decrease the red channel slightly using my display’s OSD. Essentially doing the same thing you’re doing with the color mangler shader but with less fiddling, and it’s no more or less “accurate.” The colors on my display basically match those in your corrected Cadillacs shot but aren’t quite as desaturated, which is what I prefer. I’m not suggesting this method is superior, either. Eventually I’ll get around to actually calibrating this display for 9300k since the preset modes are all pretty awful.

1 Like

It seems like what Venom wrote has become your mantra, but every time you quote him you conveniently forget a very important detail from his statement: Trying to match CRT colors on a non-wide color gamut / sRGB monitor is a futile mission.

You can most definitely match the crt colours in every way, although you need a wide gamut monitor. And even with an sRGB one, you can get very close. You will only have to deal with a little bit of clipping. Mainly in the green channel, according to him. That’s low level stuff, at any rate. I never said I have achieved it. What I have achieved however, is to match the perceived tones of crts, as proven by the many side by side comparisons I have posted. Let us see yours.

In fact, colour is a more likely 100% match than many other crt characteristics. You just seem to not be as interested in the former as you are in the latter, for whatever reason.

And I’m not even considering the fact that even sRGB is overkill when it comes to representing the very limited palettes of retro systems (65536 or 2^16 in the mighty Neo Geo vs 16,777,216 or 2^24 in sRGB).

I can guarantee that simply doing that will result in a very clear improvement in colour balance. And yes, it’s universal, at least as long as people have access to decently calibrated screens. Like I already told you once, that is the point of color-managed workflows: consistency among content providers and also between them and the end user. And I’m not being combative. But on one hand your frequent negativity rubs me the wrong way, and on the other someone has to call you out when you say things like “Retro gaming is not an activity where color accuracy is critical”

I don’t have any calibrated flat panels anyway, let alone wide-gamut, so for me eyeballing is good enough. I don’t think absolute perfection/accuracy is going to be possible, due to the analog and variable nature of CRTs, but I also don’t think that’s a necessary bar to clear. Obviously, what one person thinks is “good enough” is likely to be nowhere close for someone else.

2 Likes

This is equivocation and/or hair-splitting, IMO, and I don’t really have the energy to respond to it.

Consistency matters for content creation and reproduction but it gets somewhat murkier when talking about the consumption of that content, particularly when you’re talking about matching something that was highly variable in the first place (a CRT display). Furthermore, the same color correction won’t work for different displays calibrated to the same standard because two different displays calibrated to the same standard will still be different. So you have variability in the thing you’re trying to match and in the thing trying to match it; this isn’t an exact science.

It seems like any minor differences in opinion that I have are being perceived by you as “negativity.” It hasn’t been my intention to merely be negative and I apologize if it came across that way. Color accuracy is not something I obsess over to the same degree as you; I have other things I obsess over.