So, do I have to go into settings or wait for your update, Mr. Pants?
Notice: As of 2024-08-05, this has been reuploaded to fix a glitch that only happened to me on Windows.
Apparently, when I run Windows, I’m not able to multiply and divide individual columns of a mat3. This problem didn’t happen on Linux for me. I had to edit the code to multiply all 3 columns instead of only the 2 I needed to multiiply. I’ve also noticed that this performs horribly on Windows, whereas on Linux it ran smooth, despite being on the same laptop.
Notice 2: Another reupload to change default NES brightness from -0.05 to 0.15 (positive). This is a big difference from the default Genesis/MegaDrive brightness of (negative) -0.20.
Notice 3: My presets for BlastEm are currently bugged on certain RetroArch installs (but not all). If you do not see rainbows on Sonic 1’s waterfall, switch to Genesis Plus GX and make sure to crop overscan.
https://www.mediafire.com/file/g4pwhqptjoh4yjc/PlainOldPants_2024_08_04.zip/file
I might have accidentally flipped the sign on the user’s hue rotation setting in this update.
Changelog:
- Added code that uses linear regression to automatically sync up to color bars. (Why didn’t I think of this a long time ago?) You’ll get this color if your hue and saturation are both set to the default value 0.
- Changed default brightness from -0.05 to -0.20 on non-NES presets.
Even with the linear regression to sync up standard color bars, the difference is still noticeable. To get closer to how it was before, rotate your hue in the negative direction.
NES looks significantly better now. On NES, the ground in Battletoads is always green, the ground in Duck Hunt and Contra (USA) is brown, and the Battletoads title screen is half green, half cyan. That brown in contra and that green ground in Battletoads are in the same hue column of the NES palette, but they manage to be very different colors. This looks close to the CXA2025AS palette that’s already in Mesen and FCEUmm. From playing a little with this, I’m guessing that some people, especially in Japan, probably rotated their hue slightly in the negative direction to make their dirt and trees look more brown in many games.
On Genesis, red is still oversaturated af, but something new is that the enemies at the beginning of Rocket Knight Adventures are now distinctly cyan, not just a light green. This seems about right.
One thing I forgot to note about my 1989 RCA Colortrak is that I can’t get the red smear effect on it at all, no matter how high my contrast and saturation are.
3 Likes
Thank you, Commander Pants. I am in your debt, sir.
August 15 Update: New NTSC shader with configurable lowpass/bandpass filtering and colorburst rate/offset
I have just done some final touches on a new NTSC shader which I’m calling Patchy NTSC. It started out as an attempt to combine the features of artifact-colors and mame-hlsl’s NTSC passes into one shader, but I ended up making it much more advanced than I meant to. I plan to submit a poll request of it (so that it can officially get into shaders_slang), after getting a little bit of feedback on this forum and making some final changes and fixes.
Using the settings, you should be able to convincingly match specific consoles’ NTSC video signals. I’ve included presets that emulate the NES/FC and Genesis/MegaDrive (the latter by eye, not quite accurate, too much blur and too little luma fringing), and I’ll allow anyone to post their own settings for more consoles.
Download here. Some quick and dirty CRT presets are in the main folder, and the NTSC implementation itself is located at resources/patchy-ntsc/patchy-ntsc.slangp. For more info about what’s in the resources folder, read the included readme and changelog.
Full list of settings and features
- Automatic detection and adjustment for cropped overscan, assuming the same amounts were cropped on opposite sides.
- There are a few built in test patterns
- NES support. Hue error amounts for 2C02G and 2C02E are emulated. There is a manual toggle for the different artifact pattern seen in Battletoads.
- Genesis/MegaDrive jailbars on solid backgrounds.
- Customizable color carrier, to match a real console’s artifact pattern. You can adjust its offsets (initial, per-line, and per-frame), amplitude (now x0.2 by default), and frequency, and you can adjust the duration of the on-screen part of the scanline.
- (Edit: Calculating from the CXA1145’s data sheet, the correct amplitude is 1.0, but this causes much more interference into luma than I get on my real Genesis. 0.2 is more like a guess; I think it’s more like 0.5, but for something this fundamental, we should be using real data, not guess-and-check.)
- Customizable low-pass filter on the luma signal (Y) before adding chroma onto it. Low-pass filters to choose from include the sinc window from artifact-colors, Guest.r’s gaussian blur, aliaspider’s GTU signal resolution, and the 3 band equalizer from NTSC-CRT. For the 3-band equalizer, you might or might not want to go into patchy-ntsc-inc-filters.inc and increase HISTLEN.
- Customizable filters to separate the luma (Y) and chroma (IQ or UV) signals from each other. To get luma, you get the same low-pass filters as above, plus a simple crappy “2-point comb” filter. To get chroma, you can use the sinc window bandpass from artifact colors, a simple “2-point comb”, or the 3-band equalizer from NTSC-CRT. For the 3-band equalizer, you might or might not want to go into patchy-ntsc-inc-filters.inc and increase HISTLEN.
- After getting decoding YUV (not YIQ), a customizable R-Y/G-Y/B-Y correction is applied, using data from real jungle chips’ data sheets. The default decoding is automatically sync’d to standard color bars, although the resulting RGB values are still prone to getting clamped.
- Contrast, brightness, color, and tint can be customized. Tint 0.0 and saturation 1.0 are matched to standard color bars.
- A problem on old CRTs where bright red (and some bright blue) bleeds to the right can optionally be emulated. A working CRT should not have this problem. I’m not sure of this, but what I believe happens is, whenever RGB values go over some threshold (1.0 by default), whatever is over that threshold will instead get added onto the next pixel, so when there is a long line of these exceedingly bright pixels, they will keep compounding, resulting in a long smear to the right.
- Gamma and the phosphor gamut are emulated. Grade’s EOTF function is used for gamma, and Chthon’s gamutthingy lookup tables based on Trinitron phosphors are used for the phosphor gamut. Chromatic adaptation can be toggled on or off.
A separate shader called Patchy Color can be used for just the color grading features.
Screenshots of the included presets (JPEG-compressed, unfortunately)
This game would get panned and called offensive in 2024. It has a LOT of dithering that the SEGA Genesis smooths over, as well as a lot of undersaturated reds that look fully saturated on 90s hardware (though that might be unintentional).
Also, there’s this jailbar pattern, even on solid backgrounds. This happens on many model 1s prior to the VA6 revision.
I don't know much about electricity, so could someone please click here and explain what's happening in this circuit?
These screenshots are from a schematic of the Model 1 VA3 and from the data sheet of the CXA1145. I believe this might be the part that’s causing the jailbars, but I don’t understand what this is doing.
The disgusting red bleed can easily be turned off in the settings. It only happens on CRTs that are wearing out and have their contrast too high.
The artifacts on the NES flicker rapidly, so they become much more jarring when looking at an individual frame. Notice this distinct diagonal-line pattern that the NTSC NES has.
(These screenshots are using hyllian instead of advanced.)
Note: the NES mode requires you to set your emulator’s color palette to “Raw”. The shader needs that information to emulate the NES’s colors correctly.
Edit August 16
There are some details I want to note about my implementation, in case anyone in the future is going to work on this.
The most important rule of Patchy NTSC
The most important rule of Patchy NTSC is that NTSC for video games shouldn’t be emulated using the broadcast standards, but they should instead be emulated using things like service manuals, data sheets, and other documentation about actual CRTs and video game consoles. Neither video game consoles nor consumer CRT TVs implemented the standards exactly right; they were more like a hack. Notice how I’ve intentionally not used different bandwidths for I and Q, and I’ve included nonstandard color changes that the CRTs actually did.
Regarding the console’s modulator chip
I’ve looked at the NTSC chips that appeared in the SEGA Genesis and SNES. (SNES ones can be found here. Genesis ones can be found with a few google searches.) They all use about the correct YUV matrix, albeit with some slight variation, probably not intentional. I’ve chosen to skip this slight difference and use the standard YUV matrix instead.
Even so, these consoles didn’t all use these chips in the exact same way. The Genesis in particular has been known for its messy composite signal, which varied from good to bad across its different hardware revisions. Inside this post, I’ve included a screenshot from the CXA1145’s data sheet and a scre aboveenshot from a schematic of the VA3 Model 1 Genesis, showing the part that I think causes the worse signal. The data sheet wants you to put a delay line on Y and a band pass on C, but the Genesis seems to have replaced the delay line with some other filter that I don’t understand. I haven’t properly learned what these electrical components do.
To emulate the VA3 Model 1 Genesis’s jailbars, I simply added a sine wave onto the signal. It’s nothing complex.
Regarding clamping in the jungle chip
- In the jungle chip data sheets that I’ve looked at, there are clamping levels at every step. That is, the Y signal input is clamped, the C signal input is clamped, the resulting R-Y and B-Y are clamped, and the final R, G, and B are clamped.
- The setting for Tint goes to the demodulation of R-Y and B-Y, so it affects those values before they’ve been clamped. The Saturation setting, on the other hand, is applied right before converting from Y, R-Y, and B-Y to R, G, and B; in other words, Saturation is is applied after clamping Y, R-Y and B-Y.
- My current implementation is assumes that R-Y and B-Y never reach their clamping levels in practice as long as the video signal is sane; in other words, they’re never clamped at all. In other words, no clamping happens until the final RGB are output. This made the shader easier to implement.
- The main problem with the above is that the NES’s video signal is not sane. Determining where R-Y and B-Y get clamped on NES will be a hassle, since different chips have different clamping levels for it. I don’t even know how the jungle chip interprets the NES’s square wave colorburst. Patchy NTSC doesn’t clamp anything until the final RGB.
- One more problem is that I’m assuming that these data sheets are not hiding any of the chip’s features. These data sheets are giving the impression that things are only getting clamped whenever they’re input into a pin on the chip, but are there things happening in the chip that aren’t being detailed in the sheet?
- One last thing: This implementation doesn’t demodulate R-Y and B-Y directly. Instead, it demodulates standard YUV, and it uses a matrix to convert from YUV to RGB with the correct R-Y, G-Y, and B-Y factored in. This is possible to do because of R-Y and B-Y not getting clamped.
About bright red bleeding to the right
This is a problem that happens on some old CRTs. Judging by the fact that only bright red smears, and not just the red component of bright white, this is evidence that these CRTs allow their RGB to be oversaturated well over 1.0 before (possibly) getting clamped, and they probably clamp well above the actual maximum values, if those clamping levels are even ever reached at all in practice. As for how the smear happens, I’m assuming that three parts of the CRT that correspond to each of the three RGB colors are getting worn out over time, and this means that if it receives an amount of electricity that’s more than it can handle, it’ll only pass on the amount it can handle, and the rest gets delayed.
My shader implementation sets the maximum possible handled RGB to 1.0 by default, with an option to raise that above 1.0. I don’t know whether I should’ve put three separate limits for R, G, and B.
6 Likes
2024-08-26: Final update, for now
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.
https://www.mediafire.com/file/8o1ii5670motujs/PlainOldPants_2024_08_27.zip/file (Updated on August 27 (one day since this post): Quick fix for improved Genesis/MegaDrive accuracy)
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.
I’ve submitted a poll request for Patchy NTSC in hopes that it’ll end up in shaders_slang: https://github.com/libretro/slang-shaders/pull/627
PS: The correct amplitude of the color carrier is (spoiler alert) 1.0. This became obvious after I added the bandpass on chroma.
4 Likes
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.
2 Likes
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.
3 Likes
Only one little advice.,… or question.
- 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.
2 Likes
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.
Let me know if it doesn’t work for some reason.
https://www.mediafire.com/file/6mvyncuhd93t8ok/patchy-with-noise-2024-09-07.zip/file
3 Likes
i checked them out buddy.
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
trilinearLUT-switchable doesnt load.
1 Like
this is just spectacular job from your side!
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.
2 Likes
@sonkun please take a look on the SNES preset. It should work for NES too. This is type of looking I get with RF.
Noise feature is what I feel like RF gets the most distinguishable with respect to Composite video.
2 Likes
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.
2 Likes
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
shaders = "7"
feedback_pass = "0"
shader0 = "../ntsc/shaders/patchy-ntsc/patchy-ntsc-pass1.slang"
filter_linear0 = "false"
wrap_mode0 = "clamp_to_border"
frame_count_mod0 = "1000"
mipmap_input0 = "false"
alias0 = ""
float_framebuffer0 = "true"
srgb_framebuffer0 = "false"
scale_type_x0 = "source"
scale_x0 = "8.000000"
scale_type_y0 = "source"
scale_y0 = "1.000000"
shader1 = "../ntsc/shaders/patchy-ntsc/patchy-ntsc-pass2.slang"
filter_linear1 = "false"
wrap_mode1 = "clamp_to_border"
frame_count_mod1 = "1000"
mipmap_input1 = "false"
alias1 = ""
float_framebuffer1 = "true"
srgb_framebuffer1 = "false"
scale_type_x1 = "source"
scale_x1 = "1.000000"
scale_type_y1 = "source"
scale_y1 = "1.000000"
shader2 = "../ntsc/shaders/patchy-ntsc/patchy-ntsc-pass3.slang"
filter_linear2 = "false"
wrap_mode2 = "clamp_to_border"
frame_count_mod2 = "1000"
mipmap_input2 = "false"
alias2 = ""
float_framebuffer2 = "true"
srgb_framebuffer2 = "false"
scale_type_x2 = "source"
scale_x2 = "1.000000"
scale_type_y2 = "source"
scale_y2 = "1.000000"
shader3 = "../ntsc/shaders/patchy-ntsc/patchy-ntsc-pass4.slang"
filter_linear3 = "false"
wrap_mode3 = "clamp_to_border"
frame_count_mod3 = "1000"
mipmap_input3 = "false"
alias3 = ""
float_framebuffer3 = "true"
srgb_framebuffer3 = "false"
scale_type_x3 = "source"
scale_x3 = "1.000000"
scale_type_y3 = "source"
scale_y3 = "1.000000"
shader4 = "../ntsc/shaders/patchy-ntsc/patchy-ntsc-pass5.slang"
filter_linear4 = "false"
wrap_mode4 = "clamp_to_border"
frame_count_mod4 = "1000"
mipmap_input4 = "false"
alias4 = ""
float_framebuffer4 = "true"
srgb_framebuffer4 = "false"
scale_type_x4 = "source"
scale_x4 = "1.000000"
scale_type_y4 = "source"
scale_y4 = "1.000000"
shader5 = "../ntsc/shaders/patchy-ntsc/trilinearLUT-switchable.slang"
filter_linear5 = "false"
wrap_mode5 = "clamp_to_border"
frame_count_mod5 = "1000"
mipmap_input5 = "false"
alias5 = ""
float_framebuffer5 = "true"
srgb_framebuffer5 = "false"
scale_type_x5 = "source"
scale_x5 = "1.000000"
scale_type_y5 = "source"
scale_y5 = "1.000000"
shader6 = "../ntsc/shaders/patchy-ntsc/linear-to-srgb.slang"
filter_linear6 = "false"
wrap_mode6 = "clamp_to_border"
frame_count_mod6 = "1000"
mipmap_input6 = "false"
alias6 = ""
float_framebuffer6 = "true"
srgb_framebuffer6 = "false"
scale_type_x6 = "source"
scale_x6 = "1.000000"
scale_type_y6 = "source"
scale_y6 = "1.000000"
pn_width_uncropped = "256.000000"
pn_height_uncropped = "240.000000"
pn_nes_enable = "1.000000"
pn_scanline_dur = "47.700001"
pn_connection_type = "-1.000000"
pn_noise_rand_offset = "273.000000"
pn_noise_min_amp = "0.300000"
pn_noise_counter = "120.000000"
pn_noise_severity = "0.500000"
pn_demodulator_luma_filter_level = "2.150000"
pn_demodulator_chroma_filter_width = "4.000000"
pn_demodulator_std = "6.000000"
pn_knob_contrast = "0.700000"
pn_knob_brightness = "-0.150000"
textures = "PhosphorSamplerLUT1;PhosphorSamplerLUT2;PhosphorSamplerLUT3;PhosphorSamplerLUT4;PhosphorSamplerLUT5;PhosphorSamplerLUT6"
PhosphorSamplerLUT1 = "../ntsc/shaders/patchy-ntsc/P22_80s_D65.png"
PhosphorSamplerLUT1_linear = "false"
PhosphorSamplerLUT1_wrap_mode = "clamp_to_border"
PhosphorSamplerLUT1_mipmap = "false"
PhosphorSamplerLUT2 = "../ntsc/shaders/patchy-ntsc/P22_90s_D65.png"
PhosphorSamplerLUT2_linear = "false"
PhosphorSamplerLUT2_wrap_mode = "clamp_to_border"
PhosphorSamplerLUT2_mipmap = "false"
PhosphorSamplerLUT3 = "../ntsc/shaders/patchy-ntsc/P22_J_D65.png"
PhosphorSamplerLUT3_linear = "false"
PhosphorSamplerLUT3_wrap_mode = "clamp_to_border"
PhosphorSamplerLUT3_mipmap = "false"
PhosphorSamplerLUT4 = "../ntsc/shaders/patchy-ntsc/TrinitronP22_D65.png"
PhosphorSamplerLUT4_linear = "false"
PhosphorSamplerLUT4_wrap_mode = "clamp_to_border"
PhosphorSamplerLUT4_mipmap = "false"
PhosphorSamplerLUT5 = "../ntsc/shaders/patchy-ntsc/P22_J_D93.png"
PhosphorSamplerLUT5_linear = "false"
PhosphorSamplerLUT5_wrap_mode = "clamp_to_border"
PhosphorSamplerLUT5_mipmap = "false"
PhosphorSamplerLUT6 = "../ntsc/shaders/patchy-ntsc/TrinitronP22_D93.png"
PhosphorSamplerLUT6_linear = "false"
PhosphorSamplerLUT6_wrap_mode = "clamp_to_border"
PhosphorSamplerLUT6_mipmap = "false"
aspect ratio: 16:9 (flat screen)
Mesen NES core options:
Palette: Raw
Top overscan: 8px
Bottom overscan: 4px
Sound output sample rate: 22050
2 Likes
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.
https://www.mediafire.com/file/sdjy957a250onkw/patchy-fixed-noise-2024-09-08.zip/file
I see that cgwg-famicom-geom has some kind of comb filtering of its own. I’ll investigate this more sometime later.
1 Like
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.
I noticed that too after uploading this. Here’s a better performing one. (Actually, never mind, maybe it’s not fixed.) https://www.mediafire.com/file/1pn4wlvbdvalahf/patchy-performance-fix-2024-09-09.zip/file
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
2 Likes
