PlainOldPants's Shader Presets

[Hyllian]

Very nice evolution in speed! I didn’t test much. I have only one thing at first that bothered me: it’s very dark! I only tested the snes preset, and had to increase the contrast to 1.0 to get something playable.

I’ve seen the Contrast at 1.0 only works using Device 1. For Devices from 2 to 9, if you increase Contrast above 0.50, the reds clamp someway. So, you ends up with a very dark picture.

Is there a way to control the red push as the first version? It may be accurate, but I can’t remember it was so red when I played in the 80’s or 90’s, or even now in my CRTs (even on composite cables).

Overall, it looks very analogical, real and alive. Congrats!

EDIT: Nevermind the red push thing. I just found the param that desaturate the reds!

EDIT2: Here’s a useful preset I’ve got running with crt-hyllian-new-mask. I had to descrease saturation and increase contrast plus tweaking the red push param to decrease clipping:

preset patchy-new-crt-hyllian-new-mask

shaders = "6"
feedback_pass = "0"
shader0 = "shaders_slang/ntsc/shaders/patchy-ntsc/p68k-fast/p68k-fast.slang"
filter_linear0 = "false"
wrap_mode0 = "clamp_to_border"
mipmap_input0 = "false"
alias0 = ""
float_framebuffer0 = "false"
srgb_framebuffer0 = "false"
scale_type_x0 = "source"
scale_x0 = "2.000000"
scale_type_y0 = "source"
scale_y0 = "1.000000"
shader1 = "shaders_slang/crt-hyllian-new-mask/shaders/support/multiLUT-linear.slang"
filter_linear1 = "false"
wrap_mode1 = "clamp_to_border"
mipmap_input1 = "false"
alias1 = ""
float_framebuffer1 = "false"
srgb_framebuffer1 = "false"
scale_type_x1 = "source"
scale_x1 = "1.000000"
scale_type_y1 = "source"
scale_y1 = "1.000000"
shader2 = "shaders_slang/crt-hyllian-new-mask/shaders/crt-hyllian-base.slang"
filter_linear2 = "false"
wrap_mode2 = "clamp_to_border"
mipmap_input2 = "false"
alias2 = "CRTPass"
float_framebuffer2 = "true"
srgb_framebuffer2 = "false"
scale_type_x2 = "viewport"
scale_x2 = "1.000000"
scale_type_y2 = "viewport"
scale_y2 = "1.000000"
shader3 = "shaders_slang/crt-hyllian-new-mask/shaders/support/glow/threshold.slang"
filter_linear3 = "true"
wrap_mode3 = "clamp_to_border"
mipmap_input3 = "false"
alias3 = ""
float_framebuffer3 = "true"
srgb_framebuffer3 = "false"
shader4 = "shaders_slang/crt-hyllian-new-mask/shaders/support/glow/blur_horiz.slang"
filter_linear4 = "true"
wrap_mode4 = "clamp_to_border"
mipmap_input4 = "true"
alias4 = ""
float_framebuffer4 = "true"
srgb_framebuffer4 = "false"
scale_type_x4 = "viewport"
scale_x4 = "0.200000"
scale_type_y4 = "viewport"
scale_y4 = "1.000000"
shader5 = "shaders_slang/crt-hyllian-new-mask/shaders/support/glow/blur-glow-mask-geom.slang"
filter_linear5 = "true"
wrap_mode5 = "clamp_to_border"
mipmap_input5 = "false"
alias5 = ""
float_framebuffer5 = "true"
srgb_framebuffer5 = "false"
scale_type_x5 = "viewport"
scale_x5 = "1.000000"
scale_type_y5 = "viewport"
scale_y5 = "1.000000"
pf_console = "1.000000"
pf_contrast = "1.000000"
pf_color = "0.800000"
pf_connection = "1.000000"
pf_clipping = "2.000000"
pf_signalfringing = "1.000000"
pf_signalartifacting = "1.000000"
pf_videostd = "4.000000"
LUT_selector_param = "0.000000"
BEAM_MIN_WIDTH = "0.720000"
SCANLINES_STRENGTH = "0.860000"
MASK_STRENGTH = "1.000000"
BRIGHTBOOST = "1.000000"
GLOW_ENABLE = "0.000000"
textures = "SamplerLUT1;SamplerLUT2"
SamplerLUT1 = "shaders_slang/crt-hyllian-new-mask/shaders/support/LUT/Sony_Wega_29FA310_no_gamma-v2.png"
SamplerLUT1_wrap_mode = "clamp_to_border"
SamplerLUT1_mipmap = "false"
SamplerLUT2 = "shaders_slang/crt-hyllian-new-mask/shaders/support/LUT/Sony_Wega_29FA310_no_gamma.png"
SamplerLUT2_wrap_mode = "clamp_to_border"
SamplerLUT2_mipmap = "false"

[PlainOldPants]

I need to point out, the “red push” is not just some red color enhancer, but it’s the CRT’s way of approximating the NTSC standard from 1953 while compensating for using a bluer white than the standard. The default settings are calibrated against that, so that’s why you have to turn down saturation and adjust tint to make SNES games look anything like they’re supposed to, since those are often made for plain RGB. For NES, on the other hand, I would assume most games want standard NTSC settings.

Or maybe you’re from a PAL region, where (as far as I know for now) they fixed this problem a long time ago. In NTSC regions, SMPTE-170M only fixes this sometimes, but apparently CRT manufacturers never got the memo here. My Panasonic CRT from 2000 still has this “red push” over all 3 of its composite inputs, and the only bypass is YPbPr component.

I can say for sure that all settings in this are either 1. based on video standards, 2. based on my real CRTs, 3. based on real video decoder chips and their brand’s known phosphors, or 4. otherwise made as an educated guess. It’s accurate.

[PlainOldPants]

I just added in a simple hack to more easily darken over-saturated reds without needing to desaturate as much, in case that helps you. https://www.mediafire.com/file/u0c981wllep9a2q/patchy68k-1pass-2025-05-29-r2.zip/file

Also I see that you’re applying 2.4 gamma in this, but my shader already does gamma. You should change the gamma in my shader instead, unless you know what you’re doing.

I’ll do a fix soon to make it possible to skip gamma and/or NTSC color.

Edit: Here’s a version that can skip gamma and NTSC color. You can’t just set my shader’s gamma to 2.2; you have to enable “Skip all gamma correction”. To skip NTSC color, make sure you pick “Dummy” and not “SMPTE C”. https://www.mediafire.com/file/qlwkoqs77hdx1nb/patchy68k-1pass-2025-05-29-r3.zip/file I’ve realized that this shader does a poor job with double-resolution SNES games. I suggest prepending a SNES hi-res blending shader for now.

[Hyllian]

Thanks. I’m still learning how to integrate your shaders with others. That was a first approach. I know it has room for improvements. Thanks for the tips, I’ll test tomorrow that new version.

One thing I’d like to know about fringing: does it only manifests if you move the screen? I don’t remember very well if in real crt those artifacts change fase even if you pause the game.

[PlainOldPants]

The fringing artifacts are constantly there, but on most consoles, they are quickly flickering between two different offsets. Because of that, while holding still, artifacts visually cancel themselves out a little bit, and they become more jarring while moving.

For an example, I suggest looking up the cave in Battletoads on the NES. This particular NES game switches between 3 offsets instead of the usual 2, but it’s still a neat example of this effect. I know Game Grumps played it on original hardware at least once.

A few consoles, such as the Genesis/MegaDrive and Master System, have the phase constantly at one offset, so the artifacts don’t cancel themselves out while holding still.

Speaking of fringing, you should try adjusting the sharpness setting too. I’ve improved it over patchy-ntsc.

[bactino]

[Hyllian]

The new params are great, thanks. One thing I noticed in the r3 version is that it offset the source someway and cut part of it horizontally.

[PlainOldPants]

@Hyllian

One thing I noticed in the r3 version is that it offset the source someway and cut part of it horizontally.

The version that I just uploaded fixes that and add a bunch of generic 2-phase and 1-phase options, but unfortunately, there’s a bit more performance overhead on this one. At least, I’m including a “speedup” version which slightly helps with that, but on that version, you have to manually fix the Color (Saturation) setting. The code is getting pretty messy and can use some optimization.

About that bug, it was a mistake with how the shader tries to automatically detect cropped/uncropped overscan and compensate for it. Notice how all the presets since r2 (or r3, I don’t remember) all have hardcoded absolute horizontal resolutions, unlike r1 which was a simple 2x multiplier. That way, you can set the horizontal resolution to whatever you want, and the shader will automatically either add pillarboxes or cut off the edges.

If you don’t want that behavior, you can instead change “absolute” to “source” and do 2.0x or 1.3333x, depending on which one you pick. (For the 2-phase or 3-phase ones, those multipliers are wrong. Instead, look at the “custom” settings at the bottom, and divide pixelSize by sampleSize to get the correct multiplier.)

Just be careful because the SNES can output either 256px or 512px, and making the resolution constantly 2x is going to cause 512px games to lag. The overscan compensation on top of that was just so that everything would stay in integer ratios for the shader to function right, but I guess it might also be a helpful feature for making presets, just maybe.

I’m curious, can anyone here from an NTSC region testify if they actually had this cursed brown Battletoads as a kid? (I’m pretty sure this doesn’t happen in PAL.)

I would guess many adjusted their TV’s tint setting to make it green, but if you did that, TV over the air would start looking messed up. For a lot of retro gaming, you might set your TV’s settings differently depending on whether you were playing video games or watching TV, and you wouldn’t know why it worked that way.

[Cyber]

@PlainOldPants

I’m curious, can anyone here from an NTSC region testify if they actually had this cursed brown Battletoads as a kid? (I’m pretty sure this doesn’t happen in PAL.)

I don’t see anything wrong with the picture but I’m going on very old and unreliable memories.

What does the “uncursed” version look like for comparison?

[PlainOldPants]

Standard 1953 NTSC colorimetry: (This is closer to the CXA2025AS palette’s representation of this, unless you’re on Nestopia where they have their own CXA2025AS palettes)

Uncorrected: (This is more like FirebrandX’s palettes and Wavebeam)

I assume the second one is the intended result, since this game was developed in Europe by Rare.

Notice how even if you have the brown ground, there are strips of green in it

[Cyber]

@PlainOldPants

I would guess many adjusted their TV’s tint setting to make it green, but if you did that, TV over the air would start looking messed up. For a lot of retro gaming, you might set your TV’s settings differently depending on whether you were playing video games or watching TV, and you wouldn’t know why it worked that way.

This wasn’t a thing at all.

Normal kids didn’t adjust their sets or tint for Retrogaming. We just played our games. There was no reference to tell us we weren’t seeing the right colours.

I know I used to adjust brightness to get better black levels though and I might have adjusted the colour to make things nice and vivid but I wouldn’t have known to adjust tint to get BattleToads colours corrected and definitely were not adjusting tint between gaming and regular TV watching.

Back then we used NTSC colour bars when TV signed off and eyeballing to get colours to look right.

A good reference might be a BattleToads review on Nintendo Power, E.G.M. or GamePro.

[PlainOldPants]

@Cyber

Normal kids didn’t adjust their sets or tint for Retrogaming. We just played our games. There was no reference to tell us we weren’t seeing the right colours.

I thought this might be the case. This makes me glad that I’ve worked so hard over these months to figure out the decoder’s intended settings based on the broadcast standards. The default settings have the tint and color settings for broadcast, and the brightness for the game to become approximately 2.2 gamma.

The problem is with 16-bit onward, where some games become just obviously wrong, even if you have no reference for how it should look. That’s why my posts about “white trash” have those color test charts: You can’t tell if it’s calibrated/matched, but there are certain colors where you have a general idea of what they should look like and can tell if they’re messed up badly beyond a certain threshold. (I should also clarify, that post has the tint and color settings set to make the test chart results become as acceptably close as possible.)

The main question that’s unanswered for me is how you dealt with bright red at the time. Perhaps it’s not a problem for NES, but definitely elsewhere. On this old PR, I included a game that takes advantage of MegaDrive rainbow banding while also having oversaturated reds: https://github.com/libretro/slang-shaders/pull/627 Hyllian posted just a day ago that they don’t remember having red saturated that much, and the preset in that post has it down to 80%. Did you guys watch TV with 80% saturation on TVs that had an on-screen display?

About the games looking obviously wrong when your TV is set for standard NTSC, I’m wanting to share screenshots of that, but for some reason, everything suddenly just looks good for some reason. I could’ve sworn I saw some games getting screwed up badly when I tried these same color filters with Chthon’s color correction (particularly when using my reverse-engineered US 9300K color settings), but now that I’m trying again with my NTSC composite video filtering added on top of that, I’m having trouble finding games that look wrong. I thought for sure Moto Racer 2 looked absolutely horrible with standard NTSC color correction, but I’m starting to think now that the game is meant to have NTSC correction.

As I’ve said before, I grew up in the 2000s (in other words, Generation Z), so CRTs were only still around for a brief part of my life. I distinctly remember Crash Bandicoot being a deep red on those CRTs, not this lighter red that we see in emulation and the PS4 remakes, which points to the CRT not having been adjusted specifically for games. Still today, I generally play PS1 games with my CRT’s default settings (which are based on standard NTSC), or sometimes with color turned down a bit. NES and Genesis absolutely benefit from lower saturation on that CRT.

Can I just say, the PS4 Crash remakes are just… gross. All those goofy cartoonish death animations suddenly become like a realistic horror film, with some Baldi’s Basics style weirdness thrown in. I wanted to remember Crash Bandicoot, not KidPix Deluxe 4 Home Edition.

[Hyllian]

@PlainOldPants

Hyllian posted just a day ago that they don’t remember having red saturated that much, and the preset in that post has it down to 80%. Did you guys watch TV with 80% saturation on TVs that had an on-screen display?

Even as a kid, I’ve always calibrated (by eye) my parent’s TVs to a neutral color position. And that worked for movies and games. If the set hadn’t the knob to adjust the tint, my only option was to desaturate all colors to some safe position.

[PlainOldPants]

Since we were discussing calibration, I’ve worked on this alternative multi-pass shader that more faithfully implements the NTSC video standard. The idea was to look up YouTube videos, watch them through the WindowCast core, and try my best to calibrate the tint and color dials by eye. The original video is converted into NTSC color, filtered with the standard filter characteristics before modulating, lowpassed under 4.2 MHz as if broadcast over air, demodulated with only narrowband filtering, and finally corrected back to sRGB in the same way a consumer CRT corrects NTSC color. All that’s missing right now is interlacing.

What I didn’t expect to come out of this was a substantial improvement in performance. What the heck just happened? https://www.mediafire.com/file/fdvi71hyi4bi3bs/p68k-fast-multipass-2025-06-12.zip/file SNES and mostly-standard 240p are supported well in the “multipass” subfolder, along with an incomplete NES implementation. If you’re looking for accuracy on NES, you should instead look inside the “presets” subfolder in this zip, and use the NES options in there, which have also been updated slightly.

I’m just very happy that this has unexpectedly happened. I’ll make a more serious, more complete post later.

P.S.: The way to disable gamma correction has changed. Simply change the CRT EOTF type from BT.1886 to the power law. These two things are default, but also make sure that the power is 2.2 and that the output sRGB EOTF is also a 2.2 power law. I’ve said before, but I suggest increasing sharpness a little, especially if using the 170m 240p preset which will have less artifacts.

P.P.S.: Some comments in the source code of the multipass shader are just blatantly wrong. There’s no need for the resolution to divide 2560 evenly, and there is no automatic letterboxing or cropping. Arbitrary cropped overscan compensation works completely different from that: It is now an optional feature which is handled similarly to Maister NTSC or NTSC Adaptive, with an added feature to detect if the resolution has been scaled by an arbitrary integer.