PlainOldPants's Shader Presets

[PlainOldPants]

I’ve made some random progress on my NTSC shader. Hopefully I’ll have it finished enough by the end of this month to where I’m comfortable submitting a PR to the slang-shaders repository.

• Did a better job at simulating NTSC colors. I’ve done a much better job at simulating the colors of my 1985 Toshiba Blackstripe and 1989 RCA ColorTrak, and I have made better approximations of standard NTSC color.
• Added support for comb filtering with NES and SNES, but I’m not sure if real CRTs worked this way or not.
• Added interlacing. If the vertical resolution is over 300 pixels, interlacing is enabled.

The NES simulation still needs more work. In particular, it is missing row-skew in its colors, so you won’t get a very accurate NES palette with this.

Download here: https://www.mediafire.com/file/3e652wqa2kfpxuh/p68k-fast-multipass-2025-10-07.zip/file

One of the included presets lets you do only the NTSC color correction. It contains a lot of confusing settings, but there is only one that really matters much: “Video decoder/region (see list below)”

• US consumer - Options 3 and 4 are based on real US NTSC consumer CRTs that somewhat break the NTSC standard. Option 3 gives the stronger “consumer” feel with a 9300K whitepoint, and I believe it appears in many Sony and Toshiba consumer CRTs in the US.
• Japan consumer - Option 7 is a guess at what a Japanese consumer CRT could look like.
• US or Japan PVM - Options 2 and 6 are based directly on the US and Japan standards respectively. While these were always the standard for professional NTSC CRTs, I assume it didn’t become widespread in consumer CRTs until the later half of the 90s.

[Nesguy]

Took it for a spin with some Genesis games, looks VERY authentic.

The comb filter stuff is neat- first time seeing those atrocious hanging dots emulated correctly. The artifacting in general looks better than any current implementation I’ve seen.

Really good stuff.

@PlainOldPants

adding HDR support actually is a great idea

Any progress on this?

[ynnad4]

Always following up your content, buddy. Even though not commenting regularly. Thank you for your amazing work, time and tenacity. Really appreciate this content related to composite video experience.

[beans]

@PlainOldPants

Added support for comb filtering with NES and SNES , but I’m not sure if real CRTs worked this way or not.

I have been thinking about this, and I think you are doing it correctly (if my understanding of what you are doing is correct). I wasn’t sure at first if the comb filtering would work for consoles that didn’t correctly flip the chroma phase each line (i.e. have line times of 227.5 periods of the chroma subcarrier). But, here’s my reasoning now. The key is that all sources respect the chroma subcarrier frequency but may alter the hsync or vsync intervals.

• For analog comb filters, the delay line (e.g. a glass delay line) was probably specified to have a delay time of 227.5 / 3579545 ~= 63.556 µs. The delayed value should have the opposite phase of the current value, although it will not be directly vertically adjacent if the line time is not ~63.556 µs.
• For digital comb filters, this gets trickier. I suspect that the sampling rate was locked to 4 * 3579545 Hz (at least for the early ones). If they could sync the sampling to the chroma subcarrier, this would allow easy QAM demodulation of I and Q without multiplications or trigonometric functions. The “window” into the line would be slightly shifted each time. So looking at the same index in the delayed line would again get you a value with the phase inverted, but not necessarily directly vertically adjacent. There are some extra things they would need to take into account to make this work without adding jitter or desyncing, and this purely speculation on my part.

So the tl;dr is that the delay is based on the chroma subcarrier, rather than the hsync interval as I had previously thought.

[Superdonkeyjack]

Long time no see, Pants. IDK why I’m getting like the NTSC output on your shaders. Am I doing something wrong?

[PlainOldPants]

If you’re playing on NES, make sure you set your emulator’s palette to “Raw”. It should work right with Mesen or FCEUmm, and maybe Nestopia. If you’re still getting glitchy output after that, then that means I did something wrong.

Edit: Also make sure that your emulator’s own NTSC filter is turned off, so that you don’t combine two different NTSC filters together.

While I’m here, here’s an update to my latest multipass shader which now has mostly complete NES support.

https://www.mediafire.com/file/q1lsxv4t7a5y064/p68k-fast-multipass-2025-10-19.zip/file

Also read this:

@PlainOldPants

It contains a lot of confusing settings, but there is only one that really matters much: “Video decoder/region (see list below)”

• US consumer - Options 3 and 4 are based on real US NTSC consumer CRTs that somewhat break the NTSC standard. Option 3 gives the stronger “consumer” feel with a 9300K whitepoint, and I believe it appears in many Sony and Toshiba consumer CRTs in the US.
• Japan consumer - Option 7 is a guess at what a Japanese consumer CRT could look like.
• US or Japan PVM - Options 2 and 6 are based directly on the US and Japan standards respectively. While these were always the standard for professional NTSC CRTs, I assume it didn’t become widespread in consumer CRTs until the later half of the 90s.

[anikom15]

You might be interested in the comb filter discussion here:

https://www.extron.com/article/ntscdb3

https://www.extron.com/article/ntscdb4

If you want to do adaptive comb filtering, determining the correlation between lines is what you want to do. I believe a mix of comb and notch filtering was also done by some TVs. You can do the two in parallel and mix them together. You’d need a notch filter with minimum group delay, so probably implemented only digitally in newer CRTs.

I don’t think you should take the video standards as prescriptive. They were more descriptive, to get everyone to align on the same assumptions. In this sense, it’s best not to worry too much about when exactly standards were adopted in regards to consumer equipment.

I notice you filter on the encoding. Not all systems filtered their output like this, but I think the later consoles started to (PS1?). If you separate the filtering from encoding and moving all filtering to the decode, you can avoid needing to store intermediates in a larger framebuffer. You can also benefit from simplifying math by cascading the filters. How the frequency response changes on cascade depends on the filter. Cascaded Gaussians, for example, give you a Gaussian with summed standard deviations.

EDIT: Another thing I noticed is that you are doing some kind of gamma correction before the encoding stage, but the levels from emulators should already be gamma-correct. All the YUV encoding should be done on the gamma-corrected levels, not linear. The only gamma correction needs to be done if the emulator’s gamma is incorrect compared to output voltage from the console. AFAIK the consoles didn’t have any gamma correction circuitry, they just had simple RGB to YPbPr converters. You could offer a gamma correction for the user’s own display, (e.g. if they normally use a 2.2 gamma monitor but want 2.4 for games) but this should be done at the very end of the chain.

The piecewise gamma functions were used by encoders so that video cameras would mimic the slight contrast gain from traditional video production. This is because in the old days, television signals were captured with video cameras that had CRTs inside of them! These reverse CRTs had a similar gamma characteristic as TVs, but just slightly different. This is why the gamma encoding functions are piecewise and with a differ power value compared to the simple power law function of actual CRTs.

[beans]

@anikom15

I notice you filter on the encoding. Not all systems filtered their output like this, but I think the later consoles started to (PS1?).

The schematics for the SNES and Genesis definitely show filters.

SNES (see B5)

There were two identical filters on R-Y and B-Y, before modulation, as well as what looks like a luma trap filter.

Genesis (right side)

There was a bandpass filter on the modulated chroma and a luma trap filter.

On some systems I barely notice a difference when eliminating the filters, but on others it is quite visible. There is a lot more chroma contaminating the luma, but if the chroma phase flips 180 degrees each frame it isn’t very noticeable outside of a bit of flickering. On systems like Genesis, though, it is very obvious on high contrast chroma transitions. Maybe less so with comb filtering.

The luma trap also contributes to the Genesis’ look. Especially on the early models, it rolls off the luma pretty early and blurs the output quite a bit. Someone modded a Genesis to “fix” the luma trap.

How effective the chroma filters on the SNES and Genesis were is, I think, an open question. I’ve tried to simulate them and they have less attenuation than I would expect. I asked an electrical engineer I know for help, so maybe we’ll see.

Interestingly, one system I can’t find any filtering on is the N64. There weren’t discrete filters on the circuit board (the chip no longer supported looping the signals back in) and I couldn’t find any mention of filtering in the ENC-NUS datasheet (you can find it here, previously posted by @PlainOldPants). It might have internal filters; I have no idea.

[Superdonkeyjack]

What about for Snes9x emulator? Turn off the NTSC filter?

[PlainOldPants]

For SNES, turn off the NTSC filter, and use p68k-fast-mp-snes.

[anikom15]

@Beans the question is how much the output filters on things like the SNES and Genesis affect the output. But thank you for sharing the info. It’s an important consideration. The unfiltered, square output of the NES certainly affects how it looks. For one, using square waves effectively shifts the perceptual phase (depending on how it’s detected) and square waves are also more susceptible to interference. For a sine wave, you need to distort the frequency of the sine, for a square, distorting any of the harmonics within band is enough to cause distortion.

The N64 has a nice output. I would be surprised if it’s not filtered.

[Superdonkeyjack]

Is it supposed to look like this?

or This?

[Superdonkeyjack]

It actually crazier than what I’ve posted it and Idk why.

[PlainOldPants]

That looks completely wrong. This is what it looks like on my computer:

I have no idea what could be causing the output to look so terrible on your end. For now, all I can suggest are generic things, like resetting RetroArch’s settings to defaults, or updating your GPU drivers, but I don’t expect any of that to help. It’ll probably only waste your time.

Maybe, try loading the built-in shaders_slang/ntsc/ntsc-256px-composite shader and appending my ntsc-colors-crt shader. If you do that, you get Maister’s SNES NTSC signal and my NTSC colors.

[Superdonkeyjack]

I had HDR enabled like an imbecile

[anikom15]

@beans I took a look at the SNES schematic and it looks like the chroma is definitely lowpass filtered. It looks to be around 2.6 MHz, wider than standard but possibly enough to have a visible impact.

I’m not seeing any luma trap though. There is filtering, but it looks like it’s outside the range of the video signal, i.e. DC and EMI rejection filters, not a notch filter centered on the colorburst. I could be missing something though. I’ll look at the Genesis one when I get a chance.

[Superdonkeyjack]

Can I do the same with your NES stuff too?

[Nesguy]

I’m eagerly awaiting HDR support for this (no rush!) so I can give it the “100% mask” treatment

[Superdonkeyjack]

Speaking on HDR, I need a new upgrade to either the LG G5 or Samsung QD-OLED. The monitor that I have is mediocre but it’s 4K so I roll with it.

[Nesguy]

Just make sure whatever you buy next says “Vesa DisplayHDR 1000” or whatever somewhere on the box and you should be good