New CRT shader from Guest + CRT Guest Advanced updates

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
4 Likes

I was also reffering to this post:

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

1 Like

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.

6 Likes

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.

4 Likes

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.

1 Like

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

1 Like

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.

2 Likes

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

10 Likes

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.

1 Like

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)

1 Like

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:

3 Likes

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.

1 Like

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.

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.

2 Likes

When using the PAL Preset without changing any parameter beside lifting the basic black level to 0.05 any Mask type other than 0 gives heavy flaming effect on moving objects on dark backgrounds. With your other presets i haven"t that effect. I use the latest version of your shaders

1 Like

If you mean wave-like effect, then you can try to set fringing to 0.0 or similar.

Alternately, delay line / merge options might also help.

Hi @guest - I would kindly need your help - I would like to replicate a Sony Trinitron look as faithfully as possible at a 1080p resolution, and digging through this thread over the years I found these suggestions: starting from the standard settings, set the Scanlines value to 2, the color profile to 5, and use mask 0 or mask 5 (they are the same but I have seen that it makes a difference in color management). I usually activate magic glow with your shaders to give better brightness. Are there other parameters to modify in your experience (I don’t have the possibility of having a real Trinitron in front of my eyes)? And if so, what values should I set them to? Thank you so much for your help and for the tireless work you share with us.

1 Like
4 Likes

It’s a good start, also don’t forget scanline saturation, it’s quite pronounced with trinitrons.

With SDR display modes it’s also adequate to reduce mask strengths. You can also set mask strengths to full and use mask bloom or similar instead. Parameters to be considered are also Mask Boost and Mask Gamma.

Optional tweaks are also deconvergence and clip saturated color beams if you want more! scanline saturation.

4 Likes

Perfect - thank you so much for your help, both of you. One last question for @guest: do you recommend setting the scanline saturation value to 2 or higher? As for the rest, I’ll have to check at home because I have the option of using HDR. Thank you so much.

3 Likes

You can raise scanline saturation like beyond 1.5, but it’s also connected with scanline shapes. If the image gets too saturated, then throw in some clip saturated color beams.

4 Likes