NTSC shader

RetroArch Additions Shaders
#26

Are you using the 0.9.8.4? You need that version.

http://www.mediafire.com/?ax85bh2r7qx4pyh

Download those. Replace your regular Retroarch exes with it. These are the Win 64 versions.

#27

I’ve ported the NTSC shader to Cg. It’s in common-shaders under NTSC/. PS3 still needs floating point FBOs for this to run correctly though.

#29

I’ve updated the NTSC shader on common-shaders.

  • Change chroma modulation frequency. This greatly helped a particular NES NTSC test.
  • Change to 32-tap decode filter.
  • Change per-frame chroma phases to {0, 180} deg instead of {0, 120}. Excessive fringing is fixed.
#30

Oh man, looks good! It fixes pseudo-hires transparency now:

#31

Oh, that’s nice :smiley: Not sure if it’s really correct though. It scales by 4x horizontally, but for SNES, you’d might want fixed 1024 px output width.

#32

So, I’ve been working on the NTSC shaders lately. There are presets for

  • Gauss scanlines or not (an adapted CRT-geom might be better later)

  • SVideo or not (artifacts/fringing removed, but that’s it)

  • 256px/320px or not.

  • ntsc.cgp and ntsc-svideo.cgp are basically equiv to gauss + 256px, gauss + svideo + 256px respectively.

The 256px/320px stuff requires some explanation. 256px presets force 1st pass to output to 1024px width. This avoids hires material to act differently than regular stuff.

Similarily for 320px. Use it for both 320/640 px width material (N64/PSX). The difference between 256px and 320px is a different chroma carrier wavelength (relative to pixels), and they need different filters, etc. I don’t know of any NTSC filters/shaders intended for N64/PSX, so I cannot compare.

Another difference between 256px and 320px is how burst phases are done. In NES and SNES, it’s 120 degree change per scanline, and offset per frame is 0/120 degrees. For 320px, I’ve used 2 phase with 180 degree offset per frame. Not sure if this is correct.

Some might think this is too blurry. I’m not sure how to filter away the chroma carrier and keep things sharp without looking very ugly. Also, I’m not sure how correct it is for the image to be “sharp” with NTSC, considering the bandwidth is kinda narrow to begin with.

A difference between my approach and Blargg’s is that he samples at a multiple of chroma frequency, while these shaders sample at multiple of luma. That could change some complexity, dunno.

Remember that all screenshots with NTSC will be more artifacty. You need to blend two successive frames to get an impression on how it will look on screen.

The old “diagonal lines” on screen were caused by chroma demodulation. After revising the filters, the stripes are now completely gone.

EDIT: Here’s ntsc-256px.cgp on tvpassfail NTSC test ROM (https://github.com/christopherpow/nes-test-roms/tree/master/tvpassfail). It’s not blended.:

1280×960

#33

Wow, you’ve done quite a bit, and it all looks really nice. The use of includes is a good idea, keeping all of the shaders short and simple without all of the code dupe.

I’m assuming ntsc-256px-gauss-scanline.cgp needs line 4 to go from this:

shader2 = ntsc-pass3.cg

to this:

shader2 = ntsc-pass3-3phase.cg
#34

My ntsc-256px-gauss-scanline.cgp doesn’t look like that here.

Anyways, updated the decode filters to 64-tap. Should be quite a lot less blurry now at least. Will increase the GPU requirements a bit, but this shader was already quite heavy.

#35

This tweaking never ends … Sigh Figured the result was way too “ringy”, so took a different approach. Cosine rolloff filter is very nice for reducing ringing, at the expense of wider transition band … Changed to a gaussian smear for chroma.

I’ve included the MATLAB files I use to design the filters, so if anyone knows what they’re doing, it’s easy to tinker :stuck_out_tongue:

(For those interested, chroma carrier is Wn = pi / 3 in 3-phase, 4.0 * pi / 15.0 in 2-phase, which explains the cutoffs.)

#36

Oh, dude, I think you really nailed it. The colors look spot-on. Dunno if that’s a result of the chroma smear or what, but it looks great.

#37

Thanks Maister, the shaders rock. I am a bit partial to what I came up with for emulating the look of old televisions but one thing I like about yours is your color correction seems more accurate to what I remember an old NES looking like for instance, is there anyway to get that function in one single .cg shader I could stack onto mine? I’ve already run out of my 8 slots and would have to sacrifice a shader, don’t think I could manage 3-4.!

#38

@solid12345 I don’t think you could ever get it below 3, just by virtue of the way the shader functions. However, if you wanted to incorporate it, you could free up at least one slot by moving the border/background to use the overlay system instead of a shader.

@maister I did some comparisons with blargg’s filter and the differences are very slight at this point. I’m trying to track down someone with an NES flash cart to see how that test ROM looks on actual hardware, since that’s the only example I’ve found where the results are appreciably different. Both versions clearly “pass,” though.

#39

Straight CGPs can have up to 12-13 passes actually. We only expose 8 in RGUI due to GUI clutter. I’ve never tested a CGP with that many passes, so it might not work.

NTSC needs 3 passes to save performance.

#40

Silly me I didn’t know that, I’ll have alot more fun (and headaches) tweaking now!

#41

This shader works great on (s)nes, genesis. How to modify it for PC Engine or Atari 2600/5200/7800? TIA

#42

It should work on any of them. What’s the problem on PCE/Atari?

#43

Scapetti has made updates to NTSC shader

Link1 = PAL shaders Link2 = Updated NTSC shaders

Maybe someone can comment more on exactly what got changed and why.

I thought S-Video can’t do dither bar blending but the new shader screenshots show otherwise??

#44

Well, he replaced the gaussian scanlines pass with crt-lottes, which is fine, and he replaced the ‘stock’ pass with an old version of the image-adjustment shader. Other than that, the changes don’t make a lot of sense to me. He fiddled with the chroma_phase values in the ntsc-pass1-encode-demodulate.inc, which is what causes the lines to rotate, IIRC.

The original values were chosen for a reason (i.e., how NTSC signal modulation/demodulation actually works), so I find the claim that these are “more accurate” or that these changes constitute an “update” to be dubious, to say the least. I’d be open to an explanation of his decisions, though.

#45

Thanks hunterk for the explanation. I stick with the trusted professional version. :wink:

How to modify it for PC Engine

Checked Megadrive using 240p test suite - color bleed test (320px - 2phase ntsc shader). Dithering blends pretty well.

PCEngine using 240p test suite - color bleed test (not so great result). Modified Megadrive shader scale_x0 = 1280 --> 1360. And PCE dithering now looks pretty similar to Megadrive bars, checkers. I tried lots of other values but nothing else gave me the exact same dithering clarity.

“The Dynastic Hero” looks a little clearer now too imo. Is this what you were aiming for??

(Atari has no 240p test suite so I wouldn’t know about dithering there)

#46

Hey, just stumbled across this on google. I know it was a few years ago, and also I’ve updated my versions of the filters since too, but I wanted to chime in and explain my decisions. I used multiple youtube videos for reference, as to me, the filters just weren’t quite right. The 320px version didn’t even seem to be working correctly at all, so through tedious trial and error I matched colour banding as close as I could to videos of real hardware, to create the closest effect possible. To me it looks more accurate but that is just me and I do not claim to be an expert on how these things work. I flipped the lines for the 256px version to match videos of real hardware also.

1 Like