New CRT shader from Guest + CRT Guest Advanced updates

The values for Jungle chip are just 0.00 to 9.00

I set it on 4.00 and contrast 0.95 instead of 0.80.

Sort of reaching the desire look ?

Either way, your base preset is just astonishing. Can’t believe how accurate the colors already look like. This is type of compositevideo looking always dreamed of to see again.

1 Like

Guest.r, I seriously suggest taking some features from my patchy-ntsc shader. (Fyi, “Patchy” is the username I’m going to switch to in the near future.)

The way to get the right rainbow artifacts is by having the scanline duration at about 47.7 microseconds (actually slightly lower), have the color carrier at about the standard frequency, always have the color carrier at the same horizontal offset, and carefully control how much the luma and chroma signals interfere with each other. The Genesis also has rainbow banding on solid colored backgrounds, which you can get by just adding a useless sine wave on top of the chroma signal.

The thing holding your implementation back is that you’re still using the hardcoded filters and color carrier offsets that originate from maister NTSC, and neither of them are matching the NTSC Genesis. I suggest you hardcode a new “1 phase” option to emulate the Genesis.

The settings are:

  • 0 = Rec. 601
  • 1 = Rec. 709
  • 2-3: A couple random Sony JP chips
  • 4-8: A few random US chips. 7 is the same CXA2025AS as the NES palette, but with dynamic color disabled, because no one knows how to emulate dynamic color. 6 and lower have drastically better-looking color and are from brands other than Sony.
  • 9: Custom

The chips’ data sheets only started including this information in around the mid-90s and later. My 1989 CRT looks like Japanese color.

3 Likes

jungle chip set to 2.00

2 Likes

Is it no longer possible to use this effect with “ntsc merge fields” activated?

2 Likes

No, the implementation is very different, i’m also improving on the issues. It also has no effect on 3 and mixed phases.

Edit: should work with merged fields in next release.

2 Likes

New Release Version (2024-09-07-r1):

Notable changes:

  • Improvements on new NTSC coloring/rainbowing implementation.
  • (visual improvements, merged fields support for rainbowing)
  • Old mixed phase luma bug fixed.
  • Low-taps count behavior improved.

Download link:

https://mega.nz/file/w5Y3RSaT#-2_hSK78-O-eV0LiJHV3XsgyexHOyhAwv__3r9EMAdQ

13 Likes

This update was the first thing I saw coming on here, nice way to start the day. Tried it out right away and the first thing I noticed is those weird vertical lines appear to be gone now. I’m getting full speed again with my composite rainbow preset but it still dips to about 55-56fps with my rf preset.

Speaking of rf preset I took the same pic @ynnad4 took in my thread and now see those rainbows over and under the log so you definitely accomplished that.

All in all I think this new rainbow iteration is pretty good.

6 Likes

Much better now. You always surprise us. :clap:t2:

RF

Composite

8 Likes

Best thing about it is I don’t have to update my presets at all for this effect, works right out the box lol. So @guest.r is this release final or do you plan to continue tinkering with it a bit more? Also does this release fix whatever that D3D11 issue users said they were having with colors looking wonky?

2 Likes

The fun part about the grade fix is, that the matrix part is really coded for optimizations, the fix is far from trivial. The funnier part is that fixing it without re-coding the whole grade section for D3D would probably break it for GLSL (ogl, vulkan).

Usually the matrix stuff gets properly translated to HLSL by SPIR-V, like with the regular guest-advanced pre-shaders, seems it fails to do so with code with some low level enhancements.

5 Likes

Welp, RIP Xbox Series X/S users and users that rely on that driver I guess. I’ll be pointing them right to this post whenever a user comes to me about that issue going forward. I’m done with that issue now then.

But yes, I’ve been further playing around with the new rainbows and I like how it blends better, even kind of helps “smooth” the overall image out a bit more. That’s a plus to me because it helps further differentiate it from my standard composite preset where they both looked exactly the same with one just having “rainbows” added to it.

I really don’t understand why you’re adding rainbows that way. Your NTSC implementation already has the rainbows, just at the wrong offsets. Here’s my way of doing it:

ntsc-pass1.slang:

diff --git a/../ntsc/ntsc-pass1.slang b/ntsc-pass1.slang
index f0fc3f4..55dc8a5 100644
--- a/../ntsc/ntsc-pass1.slang
+++ b/ntsc-pass1.slang
@@ -147,7 +147,7 @@ if (params.ntsc_phase == 4.0)
 
 if (MERGE > 0.5)
 {
-   float chroma_phase2 = (phase < 2.5) ? PI * (mod(pix_no.y, mod1) + mod(params.FrameCount+1, 2.)) : 0.6667 * PI * (mod(pix_no.y, mod2) + mod(params.FrameCount+1, 2.));
+   float chroma_phase2 = (phase < 2.5) ? (params.ntsc_rainbow1 < 0.5 ? PI * (mod(pix_no.y, mod1) + mod(params.FrameCount+1, 2.)) : 0.0) : 0.6667 * PI * (mod(pix_no.y, mod2) + mod(params.FrameCount+1, 2.));
    float mod_phase2 = chroma_phase2 + pix_no.x * CHROMA_MOD_FREQ;
    float i_mod2 = cos(mod_phase2); i_mod2 = mix(i_mod2, i_mod2*abs(i_mod2), mit);
    float q_mod2 = sin(mod_phase2); q_mod2 = mix(q_mod2, q_mod2*abs(q_mod2), mit);
@@ -165,7 +165,7 @@ if (MERGE > 0.5)
    }
 }
    
-   float chroma_phase = (phase < 2.5) ? PI * (mod(pix_no.y, mod1) + mod(params.FrameCount, 2.)) : 0.6667 * PI * (mod(pix_no.y, mod2) + mod(params.FrameCount, 2.));
+   float chroma_phase = (phase < 2.5) ? (params.ntsc_rainbow1 < 0.5 ? PI * (mod(pix_no.y, mod1) + mod(params.FrameCount, 2.)) : 0) : 0.6667 * PI * (mod(pix_no.y, mod2) + mod(params.FrameCount, 2.));
    float mod_phase = chroma_phase + pix_no.x * CHROMA_MOD_FREQ;
 
    float i_mod = cos(mod_phase); i_mod = mix(i_mod, i_mod*abs(i_mod), mit);
@@ -189,7 +189,7 @@ if (params.ntsc_phase == 4.0)
        yiq.x = lum; yiq2.x = lum;
 }
 
-   if (MERGE > 0.5) { if (params.ntsc_rainbow1 < 0.5 || phase > 2.5) yiq = 0.5*(yiq + yiq2); else yiq.x = 0.5*(yiq.x + yiq2.x); }
+   if (MERGE > 0.5) { if (phase > 2.5) yiq = 0.5*(yiq + yiq2); else yiq.x = 0.5*(yiq.x + yiq2.x); }
    
    FragColor = vec4(yiq, lum);
 } 

ntsc-pass2.slang:

diff --git a/../ntsc/ntsc-pass2.slang b/ntsc-pass2.slang
index 17635ef..d6c434e 100644
--- a/../ntsc/ntsc-pass2.slang
+++ b/ntsc-pass2.slang
@@ -216,19 +216,6 @@ float luma_filter_3_phase[25] = float[25](
    0.220176552);
 
    float dy = 0.0;
-
-   if (params.ntsc_rainbow1 > 0.5)
-   {
-      vec2 xx = vec2(params.OriginalSize.z, 0.0);
-      float c0 = get_luma(texture(PrePass0, vTexCoord     ).rgb);
-      float c1 = get_luma(texture(PrePass0, vTexCoord - xx).rgb);
-      float c2 = get_luma(texture(PrePass0, vTexCoord + xx).rgb);
-         float ybool = 1.0; if (c1 == c0 || c2 == c0) ybool = 0.0;
-      float line_no  = floor(mod(params.OriginalSize.y*vTexCoord.y, 2.0));
-      float frame_no = floor(mod(float(params.FrameCount),2.0));
-      float ii = abs(line_no-frame_no);
-      dy = ii * params.OriginalSize.w*ybool;
-   }
    
    float res = ntsc_scale;
    float OriginalSize = params.OriginalSize.x * auto_rez; 

And, with Artifacting=0.6 and Fringing=0.1, here are some screenshots.

Screenshots (spoiler)

4 Likes

It’s mostly because some implementations distort checkerboards really badly. While testing the “offset implementation” you really have to do these checks too.

Been there, done that :wink: :

Current implementation has more or less all the ordinary 2-phase quirks and properties while being able to do the rainbow effect in desired situations.

8 Likes

Lol , just signed up to ask you about this. Just updated your shaders and saw the colors were wacky on my Xbox.Is it something I can fix by downgrading or is it something else.

1 Like

You’re Xbox user number 4 to now ask me about this, I might have to put in big black letters on my main page that “it’s over” for Xbox users lol. Unfortunately I have no idea what exactly is causing it besides possibly some setting.

I also didn’t know this was a issue from the “grade” shader once again (first issue was the contrast setting causing black screens to Linux users) until guest.r just pointed it out above. One user pointed out that by switching the Color Display setting to 0 got the colors right but that then darkens the image.

What I can suggest is going into the parameter settings and default each setting (press start/enter on it) until you get to the “LUT Toggle” setting. Skip the “Color Display” setting, I want to see if some other setting triggers the colors back. This method was how I pinpointed the contrast issue from last time.

Of course if you want you can always go back to the last pack if all else fails, I personally would never touch that pack again though. Also maybe try reinstalling RetroArch from scratch to the latest version if you don’t have it already.

1 Like

I think mi display resolution might be too high for mask 2 as setting this will show either magenta pixels in the in betweens or weird Pixel patterns if set in bgr my screen res is 1920x1200

1 Like

Okay thanks for the tips. Wasn’t really sure what’s going on so I thought I’d check, I only use the Xbox as a backup. I’ll triage some of this later, these shaders look incredible by the way, really cool stuff.

1 Like

Maybe try reinstalling RetroArch from scratch with the latest version. Someone in a YouTube comment said they had wonky colors and a fresh install solved everything.

Screenshot would help a lot more here. To be sure you can check if slotmask isn’t enabled.

1 Like

It might not be the case as it happens in all fresh installations I had made so far

1 Like