New CRT shader from Guest + CRT Guest Advanced updates

[Cyber]

Greetings @guest.r just asking out of curiosity, is it possible to produce a Dot Mask Subpixel Layout CRT Shader Mask compatible with QD-OLED’s triangular subpixel layout?

https://www.reddit.com/r/OLED_Gaming/s/xMx8d5qnop

Secondly, my presets using your NTSC section plus Sony Megatron Colour Video Monitor and the rest the shader stack I use always end up looking the best to me even after I experiment with other Shaders. I must also add that I was able to essentially match what I did with the Megatron/Guest-NTSC combo almost verbatim using CRT-Guest-Advanced-NTSC plus some other shaders so that says a lot about the potential of CRT-Guest-Advanced-NTSC.

However, I was recently trying out @DariusG’s CRT-Consumer-1w-NTSC-XL in which he has modeled different NTSC clocks and settings on a per console basis. I can’t currently verify the accuracy of his implementation but it does allow full blending of PC-Engine/TurboGrafx-16/Turbo Duo dithering with NTSC colour and fringing artifacts without introducing diagonal artifacts in the dedithered areas via decreasing the strength of the comb filter.

His implementation simulates all NTSC artifacts all the time except when in S-Video mode and one must decrease the Comb Filter Strength to increase the strength of the artifacts. He has also implemented 2 PCE clock modes PCE256 and PCE320.

Any chance we’re going to see further evolution of CRT-Guest-Advance’s NTSC module/implementation now that we seem to be in a period of renaissance where that is concerned once again?

P.S. I tried out mixed mode to try to improve the “m” in the Turbo Duo BIOS screen but I ended up going around in circles as Mixed Phase is inherently blurrier than 3 Phase and I think I have achieved the sweet spot for maximal blending of PCE dithering, prodcucing new colours and sharpness.

However, after trying out CRT-Consumer-1W-NTSC-XL then going back to my regular stack, the “m” didn’t look so bad at all after all. It’s legible and it might be that I’m aiming for a sort of idealised look with the perfect colour blending, plus sharpness but at the expense of sharpness in certain niche cases in order to facilitate this perfect blending.

[guest.r]

Hey @Cyber, thanks for stopping by!

I would really need someone with the mentioned subpixel display to test a couple of things, but my intuition says that first tries should just use the RGB layout. Physical subpixel layouts can be hard to “emulate”, even harder by just following intuition. It should do, but close-up photos will suffer from, khm, the target display hard-wired properties a bit.

You are somewhat right about some features of the ntsc shaders. Over the recent period of enhancements i didn’t focus too much on the good ole’ backbone. I might incorporate some ideas from my recent PAL shaders, also add an option or two. You know that this also allowed very nice backwards preset compatibility and even small changes could require after preset re-tweaking. But i guess it’s plausible to take some steps.

[Cyber]

Thanks for considering backwards preset compatibility in all of your endeavours but sometimes things just need to move forward for the greater good I guess.

While you’re in the lab, you might want to consider what these folks seem to think about a good adjustable notch filter vs comb filters.

I think @NESGuy recently said something similar or came to a similar conclusion that for older systems, Notch Filters seemed to be better than Comb Filters. Kinda similar to how Dot Mask TVs seem to work just as good if not subjectively better than Aperture Grille and Slot Masks for older consoles.

I don’t think there’s anything wrong with trying to push CRT-Guest-Advanced beyond the subjective and objective limits of what was visually possible on even the best CRTs you know. With Shaders we do have that flexibility to be accurate if we want to but also to be better than accurate while not spoiling the presentation.

That’s what I try to aim for in my presets and is one of the reasons I enjoy doing this so much. Sometimes I wish I could stop though (and just play the games) but seeing these games come to life in ever improving forms is just as pleasant as listening to music that I love.

[guest.r]

Ntsc adaptive work a bit differently. I think i will improve the current design a bit, dunno what will be in a year or two.

[Jobima]

@guest.r

Raster Bloom is an effect, where the entire screen enlarges with bright scenarios and shrinks when image is darker. Mimics the behaviour of some CRT TVs with worn voltage regulators. It’s authentic, I could observe it first hand on my device.

Yes, It’s authentic, but seems there is something missing, in real CRT enlarges and shrinks is not unified (at least horizontally and with very bad cases)

https://www.reddit.com/r/crtgaming/comments/pqsvcz/my_crts_picture_grows_and_shrinkes_when_the/ and https://youtu.be/7l5C5skeK7M?t=840

in any case thank you for adding it in the first place seems yet no one else did this crt effect in shaders

[guest.r]

@Cyber

P.S. I tried out mixed mode to try to improve the “m” in the Turbo Duo BIOS screen but I ended up going around in circles as Mixed Phase is inherently blurrier than 3 Phase and I think I have achieved the sweet spot for maximal blending of PCE dithering, prodcucing new colours and sharpness.

I harnessed the potential of Gemini to go through the relevant internet sources about PCE and phase shifts. I’m just posting here, what it found out:

The horizontal resolution (256px vs. 320px) does not change the 180∘ line-to-line phase shift.

In both modes, the PC Engine’s video encoder (the HuC6260 chip) still outputs a standard, NTSC-compliant composite signal. That 180∘ shift per line is a fundamental part of the NTSC standard, and the PCE adheres to it.

So, what does change?

You are correct that the PCE has different dot clocks (pixel clocks) to create these different horizontal resolutions:

• 256px mode (e.g., Bonk’s Adventure ): Uses a dot clock of 5.37 MHz (the same as the NES/SNES).
• 320px mode (e.g., Street Fighter II’ ): Uses a higher dot clock of 7.16 MHz .

While this changes how many pixels are “drawn” during the active part of the scanline, it doesn’t change the timing or phase of the NTSC color subcarrier (which is always ≈3.58 MHz) or the 180∘ shift that occurs at the start of each new line (the H-sync).

The Real PC Engine Phase-Shift Trick

Interestingly, while the horizontal resolution doesn’t affect the phase shift, the PC Engine has a different, more advanced trick up its sleeve for managing composite artifacts.

The video chip has a register bit that can change the total number of scanlines in a frame from 262 lines (even) to 263 lines (odd) .

This is the real “artifact correction” mechanism:

1. Standard 180∘ Shift (per line): Like any NTSC console, the phase is inverted 180∘ on every new line.
2. Even Frame (262 lines): The console draws 262 lines. Let’s say the frame ends with the phase on “normal.”
3. Odd Frame (263 lines): The console draws 263 lines. Because it draws one extra line, the 180∘ inversion pattern is flipped. The frame ends with the phase on “inverted.”
4. Result: The phase of the color subcarrier is now inverted relative to the entire previous frame .

By flipping the phase of the entire picture every other frame, any static composite artifacts (like dot crawl or rainbowing) are also inverted. To the human eye, these opposing artifacts blend together and “average out,” resulting in a cleaner, more stable image with less shimmering.

So, you’re right to be curious about its video tricks, but the magic wasn’t in the horizontal resolution—it was in this clever 262/263-line switching, a feature far more advanced than its 8-bit and 16-bit rivals.

So i’m not rushing, it’s just one evaluation of the situation, but it’s still an evaluation.

[Cyber]

@guest.r

You are correct that the PCE has different dot clocks (pixel clocks) to create these different horizontal resolutions:

• 256px mode (e.g., Bonk’s Adventure ): Uses a dot clock of 5.37 MHz (the same as the NES/SNES).
• 320px mode (e.g., Street Fighter II’ ): Uses a higher dot clock of 7.16 MHz .

While this changes how many pixels are “drawn” during the active part of the scanline, it doesn’t change the timing or phase of the NTSC color subcarrier (which is always ≈3.58 MHz) or the 180∘ shift that occurs at the start of each new line (the H-sync).

Well I guess this corresponds with what @DariusG posted here:

A new little shader i did (glsl)

A new little shader i did (glsl)

Sure it can, just need to set a switch as “PCE mode” then internally pcemode==1.0? OriginalSize.x < 300.0 ? PCE256 : PCE320; 320 should be ntsc x 2 while 256 should be SNES clock. MD320 should be ntsc x 15/8. The difference of PCE is it does (afaik, and most other systems do the same) 227,5 (180’ steps per line, ntsc default, dot repeats pattern ever 2 lines) instead of 227,333 of SNES (120’ steps per line, diagonal, dot repeats pattern every 3 lines). //clock //MD/MS256/PCE256 & SNES/NE…

@DariusG did you know about this part?

@guest.r

The Real PC Engine Phase-Shift Trick

Interestingly, while the horizontal resolution doesn’t affect the phase shift, the PC Engine has a different, more advanced trick up its sleeve for managing composite artifacts.

The video chip has a register bit that can change the total number of scanlines in a frame from 262 lines (even) to 263 lines (odd) .

This is the real “artifact correction” mechanism:

1. Standard 180∘ Shift (per line): Like any NTSC console, the phase is inverted 180∘ on every new line.
2. Even Frame (262 lines): The console draws 262 lines. Let’s say the frame ends with the phase on “normal.”
3. Odd Frame (263 lines): The console draws 263 lines. Because it draws one extra line, the 180∘ inversion pattern is flipped. The frame ends with the phase on “inverted.”
4. Result: The phase of the color subcarrier is now inverted relative to the entire previous frame .

By flipping the phase of the entire picture every other frame, any static composite artifacts (like dot crawl or rainbowing) are also inverted. To the human eye, these opposing artifacts blend together and “average out,” resulting in a cleaner, more stable image with less shimmering.

So, you’re right to be curious about its video tricks, but the magic wasn’t in the horizontal resolution—it was in this clever 262/263-line switching, a feature far more advanced than its 8-bit and 16-bit rivals.

[DariusG]

@Cyber

did you know about this part?

Isn’t this what all NTSC consoles did on interlace, i mean since total NTSC lines are 525, one field has to be 262 and the other (next frame) 263? One field renders that 1 extra line. Since you choose a field to render upon it (there is only one field used on double strike mode), it has to be either 262 or 263 AFAIK.

Maybe the (PCE modes agnostic) encoder used on the PCE has that register for interlaced mode?

------- line 1 drawn on frame 0
------- line 2 drawn on frame 1
------- line 3 drawn on frame 0
------- line 4 drawn on frame 1
.... 
------- line 525 drawn on frame 0

[guest.r]

I was also reffering to this post:

@beans

TurboGrafx16/PCEngine is difficult because games can set whether a frame is 262 or 263 lines. We can’t tell just from the core output, though. This affects how the chroma phase shifts between frames. I don’t know what to do about that.

It’s something to be considered, or maybe just do a “standard” per-frame shift regardless…

[DariusG]

@Cyber

However, I was recently trying out @DariusG’s CRT-Consumer-1w-NTSC-XL in which he has modeled different NTSC clocks and settings on a per console basis. I can’t currently verify the accuracy of his implementation but it does allow full blending of PC-Engine/TurboGrafx-16/Turbo Duo dithering with NTSC colour and fringing artifacts without introducing diagonal artifacts in the dedithered areas via decreasing the strength of the comb filter.

Blending on composite occurs because of Chroma bandwidth, check these revealing screenshots (that’s an ntsc shader mockup i did, i do these every now and then to practice lol).

Raw RGB

Check how colors are blended where only colors (chroma) is at play, but wherever luma exists it won’t because of higher luma bandwidth, e.g. check the forehead here. That’s why composite blends but still manages to be sharp.

Of course the shader takes in to account the different bandwidths and applies them, like 7 passes of 0.5*SourceSize.z for chroma, if we do the calculation, it’s 3.5 times less than original horiz. size, e.g. 256.0/3.5 is ~ 80 color samples for IQ (chroma), near to what it is supposed to be.

1.2 mhz / 4.2 mhz is ~1/3, a bit more so 3,5

Luma will do like 2 or 3 0,5*SourceSize.z to simulate that small detail loss, or do the full 7 passes and adjust the gaussian weight or whatever is used, to be sharper.

If we extend out math and chroma lives around 3.579 mhz with a range of 1.2 mhz symmetrically, it means it lives in 3.0 to 4.2 mhz range, so if we supposedly cut those freq. to erase Chroma from luma, we got

3.0/4.2, around ~1/1.5 so there we got our 3 passes of 0.5 for luma.

[beans]

@DariusG

Isn’t this what all NTSC consoles did on interlace, i mean since total NTSC lines are 525, one field has to be 262 and the other (next frame) 263? One field renders that 1 extra line. Since you choose a field to render upon it (there is only one field used on double strike mode), it has to be either 262 or 263 AFAIK.

Most systems didn’t let the developers choose, as far as I know. The Mega Drive and SNES always had 262 lines per frame (unless interlacing, then they had 262.5; the half line is what triggers interlacing). What’s interesting about the PCE is that the game devs can choose. They might even change in the middle of the game, as far as I can tell.

263 lines per frame will result in fewer visible artifacts, and maybe that’s what most used. That might be a good default.

[guest.r]

I guess this “default” makes the integration of PCE much smoother. It’s a big deal regarding gameplay, but code changes are more cosmetic. Still need to test some things though.

[Cyber]

@DariusG , @guest.r I see you’ve mentioned 256px and 320px modes for PC-E/Turbo Duo. What about it’s 352px mode?

Mednafen PCE-fast with overscan visibility

I updated a modification I made to display Mednafen pce-fast full overscan. It shows 352 pixels width for games in that resolution, like Ninja Spirit: 341 pixels before modification / 352 now (initial/last scanline at 0 & 242 in core options) And it gains 1 line that was lost (in mednafen source, not a libretro error) at the bottom for games at the standard resolution: Pc Genjin 2 with initial/last scanline at 3 & 242 in core options (first 3 lines are blank) Default screen ratio is now 6:5…

[DariusG]

That should be covered by the 7mhz clock already (same with the Amiga that can do 352 on same clock). About that 262/263 register on PCE chip, did some research, it’s a switch to force interlace mode, but no PC Engine game ever used it AFAIK.

[guest.r]

New Release Version (2025-11-02-r1):

Notable changes:

• ntsc: mixed phase mode 5.0 replaced by PCE mode
• ntsc: custom fast sharpen sharpen/deblur works better with high resolution content
• pal phase mode rework, it’s now auto, progressive, interlaced.

Download link:

https://mega.nz/file/R9R3iLrB#C5ygYpKaXZ86iea-UUGyWcVzLSU3043EqeY4tFancRk

[guest.r]

@DariusG

About that 262/263 register on PCE chip, did some research, it’s a switch to force interlace mode, but no PC Engine game ever used it AFAIK.

PCE visible line game resolution is usually 240 (like first scanline to display is 3, last 242), it can be checked with MegaBezel presets very nicely. Hard to tell what happens with the switch in an emulator or core, since this is more or less on register debugging level.

[Jobima]

@beans

(unless interlacing, then they had 262.5; the half line is what triggers interlacing)

see here and https://junkerhq.net/xrgb/index.php/240p_video

it’s all about the info in that half line to do 240p (double-strike or non-interlaced) or 480i, which seems only work in analog tv (others will see 240p as 480i)

[Cyber]

@guest.r

New Release Version (2025-11-02-r1):

Notable changes:

• ntsc: mixed phase mode 5.0 replaced by PCE mode

Hey @guest.r, thanks a lot man! You’ve finally given me enough of a reason and incentive to make the big upgrade to New Release Version (2025-11-02-r1)!

Initial impressions are that mode 5 looks and works great! In hindsight, Mode 4 probably wasn’t so bad either, I probably just needed to fine tune the resolution scale like I did with Mode 5 to get maximal blending while keeping the “m” sharp enough to be legible as I already did with Mode 3 (which was what the Auto setting triggered).

Mode 4 seems to have chroma artifacts from Mode 2 which may not be accurate for PCE though but it’s probably useful if enough time is spent with it. Maybe the slot can be used for another system if you find figure out a more accurate way to do things for it.

Now for Mode 5, I love the fact that I can now have NTSC Artifacts and Fringing with PCE without the diagonal artifacts messing everything up.

I noticed that by default with Merge Fields set to Auto or No, I’m getting lots of dot crawlly, interlacey flickering in the dithered areas. This goes away with Merge Fields set to Yes, which I think is the correct behaviour for the PC-E/Turbo (at least it looks correct to me while the flickering artifacts look wrong).

I find the Chroma artifacts to be quite subtle, giving a very clean look to the signal, even with “Composite” Resolution Scale settings, which is the way I remember real hardware to be.

Is it possible to Automate or force Merge Fields On for PCE?

Lastly, for a while now I’ve always wondered if you could have normalized the Resolution Scale 1.0 setting to be the (minimum) setting at which all systems blend all dithering, while maintaining a fofused look.

At the moment 1.0 works for Genesis but for PC-E 3 phase, it needs to be at around 0.95 while for Mode 5, this needs to be Around 1.10. Or at least somewhere between 1.08 and 1.10.

1.12 - 1.15 is very good for the clarity of the “m” but there might be a slight compromise on the dedithering front especially if viewing from up close to the screen.

I know you’ll share your thoughts on this so I don’t even need to ask you to feel free to provide some feedback on these ideas.

Just to further support my idea that I think that PC-E should be Merging Fields is this article here:

Nintendo NES/Famicom These don’t look so bad in composite, thanks in a large part to the colour burst averaging that happens between successive frames on the NES/Famicom/SFC/PCE. Still, colours become faded and much less distinct. For example, hover over the Rockman 3 composite shot (without looking at the RGB shot.) What are the true colours of Magnet Man’s and Shadow Man’s eyes?

https://www.chrismcovell.com/gotRGB/rgb_compare.html

Not sure if this applies to all dot clock modes and resolutions or just the ones with the same 256px ~5Mhz clock modes as the NES/SNES as mentioned here:

New CRT shader from Guest + CRT Guest Advanced updates

Well I guess this corresponds with what @DariusG posted here: [ntsc_phases] A new little shader i did (glsl) @DariusG did you know about this part?

[anikom15]

You shouldn’t think of it as pixel modes. Think of it as three different clocks: slow, medium, and fast, where you can render an arbitrary number of pixels up to a limit.

@guest.r My understanding is that the old NTSC shaders all assume a two field repeating cycle, but sometimes you actually need a longer cycle to accurately show the effects of the rainbow colors on certain systems/games.

[guest.r]

@anikom15

@guest.r My understanding is that the old NTSC shaders all assume a two field repeating cycle, but sometimes you actually need a longer cycle to accurately show the effects of the rainbow colors on certain systems/games.

I have some dedicated code for rainbow colors, so they can be optional on most situations. Some still show up regardless with a 2-phase design and horizontal “movement” or sometimes on other moving patterns.

At least regarding Genesis, rainbowing can be considered as an quirk.

https://www.reddit.com/r/SEGAGENESIS/comments/1b8cl4a/a_potential_solution_for_rainbow_banding_on/

These are some reasons the dedicated portion of code for the rainbow effect is more on the efficient side.

@Cyber big thanks for testing things out. Merging fields with PCE phase mode is tricky at least, since it won’t allow composite or RF like artifacting/fringing. Nevertheless, i’ll see if i can improve this or resolution scaling a bit.

@Cyber

At the moment 1.0 works for Genesis but for PC-E 3 phase, it needs to be at around 0.95 while for Mode 5, this needs to be Around 1.10. Or at least somewhere between 1.08 and 1.10.

You can also try 1.02 and then continue with adaptive sharpen or deblur. With 1.0 there is little foothold for some effects to develop.