Since my university courses are just starting, I need to become less active on this project for now. What I am sharing now is an updated version of Patchy NTSC with another couple rushed presets for NES and Genesis, but more accurate this time. I still don’t think I’m quite done with Patchy NTSC, but it’s at a good stopping point.
To install, simply drop the PlainOldPants folder into your shaders folder, next to shaders_glsl and shaders_slang. If you already have a PlainOldPants folder, merge it.
When selecting a shader in RetroArch, go into /PlainOldPants/2024_08_27, and pick the preset that corresponds to your emulator. The non-SignalOnly presets are set with a basic CRT-advanced preset with a thick slot mask. If you prefer a different CRT shader (such as hyllian, royale, or lottes), pick a SignalOnly preset, and append one of the presets from the CRT_Sanitized folder. Regardless of what you’ve picked, make sure to go into the shader settings and customize it–the main settings for end users are all at the top of the settings list.
I’m hoping that some people can refine the settings on this while I’m gone, to hopefully match the Genesis more closely, and share their custom settings to roughly match more consoles. Honestly, I hardly even tried with the Genesis’s chroma bandpass settings.
Please don’t give up the work on here and I’ll be happy to see your progress till the final release, if ever being done of course.
Thanks for sharing.
Edit:
Thanks for the credits by the way, on initial post:
“dannyld - Source of the settings in ntsc-md-rainbows, a preset for mame-hlsl’s NTSC passes that approximates the Genesis’s NTSC artifacts. This gave me the idea for customizable color carrier settings.”
But the thread that was made is just a basic level of presets modding. I just luckily found Mame HLSL just some years ago and it was a time where I literally found 0 preset/shaders around that could somewhat replicate the Sega Genesis Rainbow Banding, besides there seem to be quite some shader/presets that could deliver dithering at least.
In any case, that old thread may be useful in case you want to take up different (completed) presets across the thread, being based on different sources I could find. I dont have a Genesis console anymore, but these presets were made by experience or external sources (all credits to the authors who recorded their real Genesis gameplays).
Be that as it may, these threads may help you in case you want other additional sources for the NTSC-Rainbow banding looking, which I think this project is so great to have around:
My rainbow composite video thread:
In the last post in there, I posted a text file with all Rainbow banding - composite video demonstrations being recorded by people. All credits to them:
guest.r has also developed across the years, a version that also exposes some way more accurate rainbow lines for the Genesis games, on his CRT guest advanced NTSC preset:
Koko’s presets also have some very beautiful rainbow presets. The NTSC ones:
And of course, sonkun with his tenacity on several of his wonderful rainbow presets:
Hope this helps and thanks again for your project.
Thank you for linking those. I knew of some of it but not all. I haven’t completely stopped working on this. I’ve only slowed down to focus on other things.
I haven’t downloaded guest’s latest shader yet, but the version I have downloaded still emulates NTSC in a slightly weird way. You see, the way consoles like the Genesis were reducing their signal artifacts was by filtering the luma (Y) and chroma (IQ or UV) signals before adding them together into a composite signal, and the way a CRT reduced its artifacts was by doing almost the same kind of filters, but for separating instead of adding. The ntsc-adaptive shaders in guest’s CRT shader takes shortcuts for better performance, by never fully adding the signals together, instead just cross-talking them, like luma = luma + fringing * chroma, chroma = chroma + artifacting * luma, and then it does those separation filters using hardcoded, precomputed arrays. Normally, composite signals with lower interference also have to be blurrier, while sharper signals have to have more interference, but using ntsc-adaptive, you can create composite signals that are physically impossible. My newest custom NTSC shader is the only one I know of that does the whole filter, add, and filter again process instead of shortcutting it.
That post you just replied to has messed up Genesis settings on accident. My latest Genesis/MegaDrive and NES shaders at the moment are in shaders_slang, not here. Over there, I manually matched the Genesis settings to my own CRT by eye. Nope, the ones here are fine. I forgot that I did the fix here too.
About a week from now, I’m going to connect my real Genesis to my Dazzle DVC100 video capture and try matching the rainbows on that, and I’m going to redo my NES colors capture too.
Is there some way to set your whole folder into a sub folder from main “Shaders” folder ?
I tried it but then can’t use the presets. I rechecked several times the addresses for each shader on some of the presets and it still happens. Something specifically is triggered if your main folder is placed on main Shaders folder. Would appreciate it.
And very recently I found your “Patchy” presets that have been updated into the main repository and they’re available in shaders/NTSC sub folder. What is the difference between those 2 over there (patchy blastem and GPGX presets) and the ones from your last updated folder ?
The .slangp files are already meant to be in a subfolder in the main shaders folder (“shaders” not “shaders_slang”) called PlainOldPants/2024_08_27. They reference .slang files both inside my “resources” folder and inside shaders_slang. If you meant you want them in shaders_slang, then you can put them in shaders_slang/2024_08_27.
The difference is that BlastEm and Genesis Plus GX are outputting their colors differently. Genesis Plus GX outputs the console’s internal raw RGB, while BlastEm outputs the intended levels. The Genesis Plus GX preset does a correction to get BlastEm’s colors. Grade has a correction for this too, but I found that Grade’s correction wasn’t working right, so I looked in both BlastEm’s code and Genesis Plus GX’s code to make a correction of my own.
One last thing to mention, Patchy NTSC in shaders_slang is currently more up to date, but it only has the video signal. To use it with my “sanitized” CRT presets, you should append resources/afterglow-update before you append the CRT preset. I’ve been using “thick-mask-crt-advanced” on my 1440p (2560x1600) laptop, but it should be alright if not better on a bigger screen. Don’t forget, I have an NES preset too, in shaders/nes_raw_palette, and I have a shader just for the color changes in shaders/misc.
I just threw together this updated version of Patchy NTSC with noise settings. It also has all the other updates I’ve done up to this point, but it mostly works the same as before. Change connection type to RF to enable noise, then start messing with the noise settings.
I didn’t take coding this very seriously at all. It’s a mess, but it works. For now, it is just adding a bunch of random sine waves. Ideally, I would want to better understand how RF modulation works and understand what exactly causes RF interference.
The noise, at least on Genesis games look very good. I dont know how you managed to make it look like this, but before unpacking the NES again, this noise effect reminds me quite a lot how it looked like the other day when shared those Kirby videos. This is top type of RF Noise and I wish was present in so many more preset/shaders.
Just found some bugs around:
patchy-color address issue on the #include. It wasn’t searching correctly for the file.
patchy-ntsc address issues
It had some issue with the address from shader5: “trilinearLUT-switchable.slang” AND
it’s trying to find some phosphor files that are not included in the package
The image is just now vibrating the same as with the NES that is being seen right now.
Not sure if this has to do with your new code to make the rainbows, but THANK YOU so much ! I couldn’t believe would ever see this replicated ever again, but this is the very best feature i’ve seen in such a long time, aside of the Rainbows from composite video.
If there’re other people who experience this type of Noise, this is by all means a must-be feature in any of these CRT presets, specially being destined to RF-composite video looking.
Please use the patchy-mesen-raw-palette preset on NES instead. Using the SNES preset on NES causes incorrect colors and less correct artifacts. Demodulator/jungle chip 0 is like Composite Direct or Original Hardware, and chip 7 is the CXA2025AS in US mode. Chip 6 is my favorite, the TA8867AN. And of course, use the Mesen emulator and set the emulator’s color palette to “Raw”.
If you’re not getting noise on NES, try redownloading my zip. My initial upload was missing noise on NES, and I fixed it quickly after. Only the files in the “patchy-ntsc” folder need to get replaced for the fix.
After messing for a while, this is a little preset, with the most accurate version could get so far with respect to TV, real NES RF connection. This preset should be placed in the same folder from nes_raw_palette sub-folder from PlainOldPants
This update fixes a glitch that was happening with me, where the noise would slowly disappear over time until suddenly reappearing, in a 1000-frame cycle. It also removes some vertical lines that were happening for me.
I’ve also experimented a tiny bit with comb filtering. That post from Guest about checkerboards getting distorted got me thinking about this. My 1989 CRT definitely does have distortion on checkerboard patterns, but, if memory serves, my 2000 CRT with a better comb filter doesn’t have much distortion in checkerboard patterns. I think my Dazzle DVC100 didn’t have much checkerboard distortion either, but I’ll just have to see.
It’s not actually any good yet, but if you want to try my basic comb filters: The demodulator filter types 5 on luma and 2 on chroma are a 50-50 average of two consecutive scanlines, and luma filter type 6 and chroma filter type 3 are a 25-50-25 average of three consecutive scanlines. I suggest increasing the B-Y R-Y filter width to 2 or 3 when using these.
ynnad4 just posted their RF preset above, but this update might break it.
This new update pushed up GPU to the limit of capacity. Once Noise is enabled, it stabilizes at around 51 fps. Even though I just have a GTX 1050 2GB mini
Edit:
Its nice now that the presets can work INSIDE of the new project updated folder. It’s just like CRT-guest presets. They can work in an independent customized sub-folder. Thank you for this fix.
And yeah, it can be in an independent folder now because I removed the #include reference to shaders_slang/include/colorspace-tools.h
I am still working on fixing the performance. Apparently, the noise isn’t the only thing at fault, but it’s a big part.
Here’s another fix. I moved the noise into a separate pass this time. The key to making sure this performs well is to keep your screen resolution low. Increases in vertical resolution are mostly okay (for instance, interlaced mode on Genesis), but increases in horizontal resolution can cause bad slowdown. If you’re playing a console with a big horizontal resolution, like the N64 which can get as high as 640, you’ll want to go into the slangp file and change the resolution multiplier from 8.00000 to 4.00000 or something like that. https://www.mediafire.com/file/ejc2xdctliwbll2/patchy-second-performance-fix-2024-09-09.zip/file
In any case, I’m not asking for a cheap low end set of presets for low performance computers like mine.
I dont ask to cut off extra additional features in your presets if that’s what make them as accurate as possible to either your CRT or the real consoles.
This behavior didn’t happen 2 updates ago, though. I could still use about 50% of GPU in there.
I will keep attempting to check how the noise accuracy works with current update, in case GPU doesn’t go 100% usage.
That’s three updates ago. I was getting crappy performance too on my laptop’s GTX 1650 (which my laptop can’t even fully utilize; turned out it’s just an advertising point) until I did one more change today. Since I just edited it onto my previous post instead of making a new post, I’m sorry if you missed it.
My latest one should perform even better than the update that originally added noise, because noise is an entirely separate pass now.
Another thing contributing to the performance drop was that I’d doubled the horizontal resolution factor from 8 to 16. I did that to make my newly added comb filters work better. I’ve reverted it back to 8 now.
Have you gotten better results with the minimum amplitude lower or higher? My intuition has been that we get closer to real hardware if we have min amp at exactly 0 and min rate at something lower, like about 20. But even if we do that, my implementation isn’t based in real physics at all, so I don’t know.
