New CRT shader from Guest + CRT Guest Advanced updates

[Jobima]

@Nesguy

some colors become more desaturated than others

that also in PAL

and in ntsc there will be also some hue changes too in some colors (as you can see in my konami image)

[Nesguy]

Corrected to say “composite” video

[Nesguy]

A little extra on the decoder’s “resaturation stage”:

You don’t need anything fancier than a uniform saturation multiplier to reproduce this stage. That’s exactly what the fixed chroma gain was doing — applying a constant chroma amplitude scale.

If you want to be authentic:

1. Apply a uniform multiplier to the chroma vector ( I/Q , U/V , or Cb/Cr ) before conversion to RGB.

• Example: chroma *= 1.2; // equivalent to ~20% chroma gain

2. Optionally, make that value configurable per “TV model” to simulate manufacturing variation:

• Consumer TVs might use 1.1–1.3× nominal gain.
• Professional monitors (PVM/BVM) would be closer to exactly 1.0×.

[guest.r]

@Cyber

This new desaturation feature, does it replace the existing desaturation behaviour when reducing NTSC Resolution and Chroma Scale? Also, is there going to be a separate resaturation/colour boost knob or dial and is there any post desaturation, colour boosting/restoration being done automatically, by default in this new implementation?

It’s advancing in implementation, but it’s a pass1 separate feature, nothing to be worried about, even existing presets aren’t affected. There will be a knob for this, 100%.

[Cyber]

@guest.r

nothing to be worried about, even existing presets aren’t affected. There will be a knob for this, 100%.

Thanks, not worried about breaking presets anymore. Just curious about the implementation.

[guest.r]

New Release Version (2025-10-18-r1):

Notable changes:

• pal luma noise option added
• ntsc and pal versions: signal desaturation (safe voltages) feature added
• update: feature smooth parametrization
• update: “authentic” implementation

Download link:

https://mega.nz/file/RtQxwSAD#3rC2VytZWatAzAhEOWMmzSG0wBMoTvQCcob-DuS0Nng

Also thanks to @Nesguy fo inspiration.

[Azurfel]

@Nesguy

This is a great start! I dug up some additional info with the help of ChatGPT so it can be further refined

Please don’t do this. “AI” just makes things up out of whole cloth constantly, and there is no way to tell unless you have expert level knowledge regarding literally every single detail or laboriously verify every detail using real sources.

[Jobima]

@guest.r

update: “authentic” implementation

with new update

[Nesguy]

Thanks for the word of caution. The things to be careful of are the equations and such- I didn’t verify those, but everything detailing the processes involved looks good to me and matches what I’ve read elsewhere- or is there something specific that looked wrong?

I assume @guest.r knows to be cautious with answers provided by ChatGPT

[guest.r]

Yeah, it can be on shrooms or worse, no worries.

[Cyber]

Soooooo, with this new code addition, giving us more accurately modeled NTSC signaling and resultant colour, how would it affect what Grade does to the colour?

Would there be some sort of over, under or double correcting taking place?

[Nesguy]

I don’t think there’s any conflict (double correction, etc), you just want to avoid anything that’s doing it’s own YIQ conversion

EDIT: so, definitely leave “Signal Type” set to RGB in Grade

[Nesguy]

@guest.r

Thank you for this addition!

Looks great - can you verify this:

Do you need to add separate desaturation for I and Q to emulate strict NTSC (4.2/1.3/0.4 MHz)?

No.

• Pass 2 already implements this via:
  • dx1 offsets scaled by ntsc_cscalei and ntsc_cscaleq → wider for Q, narrower for I.
  • FIR taps per channel → I retains more high-frequency content, Q is more blurred.
• Pass 3 only adjusts I/Q locally at edges , it does not override the main asymmetric bandwidth .

Optional tuning:

• You could tweak ntsc_cscalei and ntsc_cscaleq to fine-tune I/Q bandwidth to match exactly 1.3/0.4 MHz.
• iqdesat can apply a small overall chroma roll-off but is not necessary for strict NTSC emulation.

Also, had some doubts creep in regarding this. Can you confirm?

The idea here is to use the existing “saturation” parameter (not NTSC saturation) to compensate.

[Azurfel]

AzMods20251018

Incorporating changes from crt-guest-advanced-2025-10-18-release1 (rev 5).

Readme with additional details

Built on top of:

• Image Adjustment (2024.02.07) by hunterk

• crt-guest-advanced-2025-10-18-release1 (rev5) by guest.r and Dr. Venom, based in part on Themaister’s NTSC shader

• Sony Megatron Colour Video Monitor (2023.10.09) by MajorPainTheCactus

• with additional functions based on or inspired by Grade by Dogway

All included “CRT Megatron” presets are currently tuned for the LG C1 and other similar displays (WRGB subpixel layout, with approximately 800 nits Peak Luminance).

The included version of Image Adjustment has been modified to allow for finer control of the effects as i found appropriate.

crt-guest-advanced-ntsc has been modified to add or expand the following options

GPGX MS color fix

Corrects Genesis Plus GX’s Master System color output, which includes minor errors i discovered while implementing the Sega MS Nonlinear Blue Fix.

• 0=off
• 1=on (color saturation scaled to a maximum value of RGB 255)
• 2=sat239 (scaled to a maximum value of RGB 239)
• 3=sat210 (scaled to a maximum value of RGB 210)
• 4=sat165 (scaled to a maximum value of RGB 165)

Sega MS Nonlinear Blue Fix

An implementation of the behavior described in Notes & Measures: Nonlinear Blue on Sega Master System 1 & Other Findings by bfbiii.

This setting automatically adjusts to work with the GPGX MS color fix settings.

Sega MD RGB Palette

An implementation/approximation of the Mega Drive/Genesis RGB palette as discussed here.

Downsample Pseudo Hi-Res

As i understand it, 15KHz CRT displays would treat double-horizontal resolution modes (512x224, 640x240, etc) as tho they were not doubled, resulting in a blending effect, called pseudo hi-res. A number of SFC/SNES games are known to have used this behavior for transparency effects, including Breath of Fire II, Jurassic Park, and Kirby’s Dream Land 3, and as far as i know it is the correct behavior for any device originally meant to be displayed on a 15KHz CRT TV/monitor.

• 1 = off

• 2 = Triggers the blending effect whenever the horizontal resolution is more than twice the vertical resolution. This works well with cores that either always output a pseudo hi-res image for compatibility (such as bsnes-jg), or cores that only use pseudo hi-res for pseudo hi-res content (such as SwanStation). True high-resolution/interlaced content is not effected.

• 3 = Triggers the blending effect whenever the horizontal resolution is 480 or higher. This is needed for cores that display pseudo hi-res content in a true high-resolution container (such as Mesen-S and a number of bsnes variants). Unfortunately, this halves the resolution of true high-resolution/interlaced content, as there is no way to differentiate pseudo hi-res and true high-resolution/interlaced content in these cores.

Internal Resolution

Modified to allow up to 1/16th downsampling. (It’s a surprise tool that will help us later.)

Sony Megatron has been modified to add or expand the following options

HDR: Content Color Gamut

Out of the box, RetroArch and Megatron clamp colors to the Rec. 709 gamut (Expand Gamut set to Off in RetroAtch, or HDR: Original/Vivid set to Original in Megatron), or stretch that Rec. 709 gamut to an unusual non-standard gamut created by someone at Microsoft (?Chuck Walbourn?) called Expanded 709 (Expand Gamut set to On in RetroArch, or HDR: Original/Vivid set to Vivid in Megatron).

Obviously, this is undesirable, as all of the major “retro” color gamuts include colors that fall outside of Rec. 709.

Serendipitously, i found that it was possible to turn this problem into it’s own solution by simply adding additional color gamuts to the “HDR: Original/Vivid”, renaming it “HDR: Content Color Gamut” to better reflect it’s newfound purpose.

When using this setting, Colour System should be set to 0/r709, and Phosphors should be set to 0/NONE.

Options are as follows:

• 0=Rec 709/sRGB (SDR HDTV/Windows gamut)
• 1=Expanded 709
• 2=NTSC 1953 (The OG color system that was only really used for like 5-8ish years back when basically no one owned a color TV anyway. If you are Brazillian or from a SECAM region, it may also match some old CRT TVs you’ve used with really weirdly intense greens? Hard to say. This sort of thing is kind of underdocumented.)
• 3=RCA 1958 (?1961?) (Millennial’s grandparent’s old TV with weird colors #1.)
• 4=RCA 1964 (Millennial’s grandparent’s old TV with weird colors #2.)
• 5=SMPTE C/Rec 601-525 line/Conrac (Baseline standard gamut for Analog NTSC.)
• 6=PAL/Rec 601-625 line (Baseline standard gamut for Analog PAL.)
• 7=Dogway’s NTSC-J (Baseline standard gamut for Analog NTSC-J.)
• 8=P22_80s (Dogway’s Grade gamut for 1980s-early 1990s TVs.)
• 9=Apple RGB/Trinitron PC (Should approximate basically any Trinitron monitor from 1987-the mid to late 1990s. By the early 00s, they were SMPTE C instead, at least for high end monitors like the FW900.)
• 10=guest’s Philips PC (Gamut used by a number of extremely popular monitors that used Philips tubes, including Philips CM8533, Philips VS-0080, and Commodore 1084)
• 11=P22_90s (Dogway’s Grade gamut for mid 1990s TVs with tinted phosphors.)
• 12=RPTV_95s (Dogway’s Grade gamut for late 90s/early 00s rear projection TVs that game manuals said you shouldn’t play games on due to burn in risk.)
• 13=Display P3/P3-D65 (Common wide color gamut. Variant on the gamut used for film with shared primaries. Might be useful in the future if someone makes a WCG pixel game that looks best with a CRT shader?)
• 14=Rec 2020 (HDR gamut. Again, might be useful in the future if someone makes a WCG pixel game that looks best with a CRT shader.)

Gamut Overshoot Fix

A fix MajorPainTheCactus came up with to deal with the color errors i noticed using lilium’s HDR analysis shader. (Sony Megatron Colour Video Monitor)

He decided not to implement it at the time, as he didn’t think it wouldn’t make a perceptible difference, but a friend and i both came to the conclusion that it makes certain test pattern colors look more like they do with no shaders applied, so i have continued to use it. There should be no downside. (Sony Megatron Colour Video Monitor)

• 0=no fix
• 1=the 7-decimal clamp
• 2=the 6-decimal clamp (results in non-zero blacks, perceptible in a sufficiently dark room)

Scanline Multiplier/Divisor

Multiplies or divides the number of scanlines.

Useful for cases like DOS games meant for 31KHz displays, which output 320x200 that was then double scanned to 640x400.

The divisor options are handy for displaying increased internal resolution output from 3D cores that don’t include a good downsample option, such as PPSSPP. I strongly recommend using this setting in conjuction with crt-guest-advanced-ntsc’s Internal Resolution setting to reduce shimmering.

• -1,0,1=1x (Default/off)
• 2=2x (Doublescan)
• 3=Auto 2x (Automatically doublescans any content with a vertical resolution of less than 300, while leaving higher resolution content unchanged)
• -2=1/2 (Reduces the scanline count to one half default)
• -3=1/3 (Reduces the scanline count to one third default)
• -4=1/4 (Reduces the scanline count to one quarter default)
• -5=1/5 (etc.)
• -6=1/6
• -7=1/7
• -8=1/8
• -9=1/9
• -10=1/10
• -11=1/11
• -12=1/12
• -13=1/13
• -14=1/14
• -15=1/15
• -16=1/16

[Nesguy]

I think the NTSC saturation parameter is more akin to the automatic color control (I may have gotten some terms swapped/confused, there’s also an automatic gain control, I think we’re still ok). The regular Saturation parameter is like the TV knob to make “artistic” adjustments.

Also, is this currently only working for 3 phase?

[Azurfel]

@Nesguy

Also, is this currently only working for 3 phase?

The Safe Voltage Desaturation setting appears to be working identically for all five phase settings using crt-guest-advanced-2025-10-18-release1 (rev5) or the decoupled version in AzMods20251018.

[Nesguy]

Yep, got my files jumbled up, I should go to bed

[guest.r]

I did some chroma signal inquries regarding different consoles:

Confirmed measurement ranges

Modern captures and scope measurements of front-port NES (USA) units show:

• Burst ≈ ~300 mV pk
• Peak chroma on saturated pixels ≈ 450–600 mV pk → That is ~1.5 to ~2.0 × burst

Some units drift hotter or colder depending on aging and motherboard revision.

Comparison to other consoles

Console	Chroma boost vs burst	Comment
NES (NTSC)	1.5–2.0×	Very hot
SNES	1.25–1.4×	Mildly hot
Genesis / Mega Drive	1.3–1.5×	Similar strategy
PS1	~1.2–1.3×	More broadcast-legal
PS2	~1.1–1.2×	Tends more legal, esp. late revisions

100% legit or not, it’s most appropriate to add this parameter option as the main “safe voltage” control knob.

[guest.r]

New Release Version (2025-10-19-r1):

Notable changes:

• pal luma noise option added
• ntsc and pal versions: signal desaturation (safe voltages) feature added
• ‘safe voltages’ chroma output boost can now be configured

Download link:

https://mega.nz/file/B0J3gaiI#aUib5-55gs20UyFE2zCKMiwFW9NB3TchIzN5Ji9YxU0

[Azurfel]

Was this buried somewhere on NesDev or system11 or?

The only things i’m seeing on google for (“450–600 mV” nes) are an unrelated technical paper on monitoring soil condition and an also unrelated German dissertation.