I just pushed a commit to tune the selective blur size so that it works when displaying borders and not:
…but I’m unable to spot any difference in the waterfall look.
It is true that the rainbow shifted, but that happen anyway while sonic walks, so i would not bother; the size of the rainbow gradient also seem to match the scale (enough for me).
In this case it’s okay. It’s a weird resolution that I’m using indeed, and I fear any changes based on it might not look consistent for everyone. Sorry for the trouble, I’ll try your suggested safe way instead.
Accuracy is definitely my main goal, but at the moment, it’s only a goal, as I’m still educating myself on how this works, and I have only so much spare time to work on this. The noise is currently the least accurate part of my work by far with the worst performance, but it’s trying its best. Even if importing it here were possible, it would just be a bad idea.
The main things I’m trying to do to make the noise convincing are 1) to keep the noise pattern in sync with the standard timings of an NTSC or PAL video signal, 2) to make the noise get added onto the video signal and decoded with it, instead of just being added onto the final output, and 3) to have the noise interfere to the right extent with luma (Y) and chroma (UV/IQ), by controlling its frequency response.
My current code to make noise meeting those 3 requirements is jank, just adding together 300 random sine waves in a for-loop. The settings are for controlling the frequencies, amplitudes, and random seed of those waves. There are a lot of better ways to do this.
I just tried out koko-aio-ng one or two days ago, and there are couple other things I want to post here about it soon. For now, all I can suggest is that your noise should be implemented more like your rainbows and fringing/dot-crawl artifacts.
That’s what I was thinking since some time; but to keep things easy on the gpu, the ntsc code that generates artifacts here runs at 1x scale, so I don’t think adding some “big” noise particles would be pleasing 
-edit-
I was wrong, it looks nice, thanks!
I’ll need to check how it impacts on performance, since it is, indeed, in a loop here too.
Also, why 300 random sine waves? there are methods that mainly abuse fract(),dot() and a sin() that are quite convincing, but I think you know that.
Yes, I know about those fast ways to generate noise. I’ve been hurrying my code a lot lately because I have so little spare time to work on this project, but the gist is that, if I use sine waves, I can easily have the pattern sync with standard NTSC timings and scroll at the right speeds. Noise on real hardware tends to have noticeable scrolling patterns, and this was just one idea to get similar patterns. Still, looking at the CRT that’s right in front of me here, there’s still a long way for me to go with this. I’ll later have to try to take into account the way that RF modulation works, like with a certain carrier frequency and with other gradually changing frequencies in the environment that interfere with it. There’s surely a way to do this without being this insane.
Another note, please make sure you use my latest version. I posted an update just a day ago to improve performance, but the RF noise performance still sucks. (NES also is going to eventually be updated to pack multiple signal samples per fragment.)
I just drafted a pre-release, NG-1.9.50-rc1
I will wait some days for you to test it and if it is all alright, I’ll make the proper one and PR it to retroarch.
hello, do you know if there is some way to apply NES NTSC rainbows ?
If you mean 45deg. artifacts, then look for ntsc-2 presets in 4.1 folder or ntsc-generic ones in ng folder.
My personal take on Gameboy presets:
GB DMG
GB Light (edited)
GB Pocket
The last one doesn’t stray from the default pocket preset, but I adjusted the ambilight, if someone wants to try them and many others (or copy my overrides) I recently uploaded a new pack (and overhauled others).
Hi @Kokoko3k - first of all thanks for your wonderful work - I’m writing to ask a question, maybe it’s offtopic, but since I’ve gotten over the “smooth image” mania and I’m getting used to crispier and more realistic things (indie games’ fault), now I’m using your GM shaders a lot with Aperture Grill, SlotMask at screen resolution, and Shadow Mask. The question is, in which scenarios is it better to use one over the other to better embrace the intentions of the artists of the time, considering that I, like you, living in Italy have always used the PAL format and didn’t know until a few years ago what NTSC was. For example, I read on the net that arcade cabinets used Shadow Mask, as well as Aperture Grill was the Gold Standard of Consumer TVs during the 90s. If someone can shed some light on this with their experience, I’d be grateful. Thanks
@ROBMARK85 I think you should focus more on signal types than mask types if you want more of that “intended experience”, like composite (CVBS) which was the most common back then. Applying proper NTSC filters can help you achieve dithering transparency effects and such. Checkout all koko’s NTSC presets (ng and 4.1) to see examples.
Note: some cores use modern enhancements and solutions to deal with dithering, there’s also modern solution shaders (like some presets in shaders/dithering) which can keep the image sharp and blend dithering patterns at the same time (koko has a parameter for de-dithering too).
The original CRT image used to look smoother around the edges than the raw pixels you see in indie games today, thanks to “scanlines” and the lower quality video signals.
Thanks for the advice. I think that for us Europeans who own the PAL format, an important element to take into account is dithering. In particular, the one that was applied natively by the consoles (I could mention the dithering mechanism that was applied to the image by the first PlayStation) as well as the dithering generated by the connections since I remember that at the time I used S-Video to connect my consoles (in truth my console experience started with PlayStation since I was a PC gamer). This does not apply to everything, as demonstrated by the VGA system of PCs or arcade screens that were very similar to those of PCs. The only doubt about it, since in the future I would like to use the koko-aio shader with the Duimon presets that I appreciate so much, is whether to look for dithering using the shader options or rely on the emulation of these via the various cores.
Using the latest release of the Kokoaio package
Core: Swanstation with dithering Active
Preset : Monitor Screen Hmask Aperture Grill
#reference "shaders_slang/bezel/koko-aio/koko-aio-ng.slangp" DO_CURVATURE = "1.000000" DO_BEZEL = "1.000000" BEZEL_INNER_ZOOM = "-0.218000" DO_GLOBAL_SHZO = "1.000000" GLOBAL_ZOOM = "1.130000" DO_BG_IMAGE = "1.000000" BG_IMAGE_OVER = "1.000000" BG_IMAGE_NIGHTIFY = "0.700000" AMBI_BG_IMAGE_BLEND_MODE = "1.000000" AMBI_BG_IMAGE_FORCE = "0.200000" DO_CCORRECTION = "1.000000" bg_over = "koko-aio_packs/Arcade/textures/background-capcom1.png"
The same presets with the updated version from github look like this.
Did the Zoom parameters change? Is this temporary or will I have to adapt my presets?
New release just done on github and asked to be included in Retroarch online updater.
NG-1.9.50 changelog:
NEW: Add Horizontal “Mask helper” function to Halo section to exploit full mask brightness
NEW: Add “RGXB” mask Presets
NEW: Add an option to show simple test patterns
NEW: Convergence: allow to offset it more and blurring more near borders
NEW: Allow the choice betweeb FXAA and ddt-xbr-lv1
NEW: Add dot crawl emulation
NEW: Allow to zoom/shift fg/bg image when Rotate/flip is set to auto
NEW: RF noise: add a more sparkling “Snow noise” option, old one renamed to “Uniform noise”
NEW: RF noise: allow to move it before or after “blur/glow” stage.
CHANGE: Presets tuning
CHANGE: Slightly improved Halo blur quality
CHANGE: Global zoom is auto disabled when integer scaling is enabled
CHANGE: Better looking spot function
CHANGE: Removed bezel “Inner Zoom” parameter, “Frame Zoom” parameter renamed as “Frame Alignment”
FIX: Do not consider flipped titles as “rotated”
FIX: Fixed common “blurs” aspect ratio
FIX: Fix override content aspect options when neither ambient light nor bg/fg images are used
FIX: Spot: corrected spot placament for 90 and 270 rotated titles
FIX: Correct reflection area shade placements for 270 deg. rotated titles
PERF: Refactored shader passes to gain speed, previously saved full presets need to be remade, sorry.
PERF: Big speedup to FXAA code by just removing unused search loop.
Performance went up by almost 4% on my haswell with my standard tests.
I’m not able to try your latest version right now, but the last version I tried had the dot crawl scrolling to the left. On my real CRT, it scrolls up, and it only behaves this way in interlaced/480i video, not progressive/240p.
On my comb-filtering CRT, I get dots whenever one scanline is surrounded by two differently colored scanlines, like in one of the NES Mega Man games for example. I might post a picture this weekend.
To my understanding, the cause of the upward scroll is a combination of the color carrier rotating 180 degrees each line, every second frame having an extra line in interlaced video (total 525 lines every 2 consecutive frames), and the interlacing effect itself. All these three things combined result in the upward scrolling pattern.
(Just an hour ago, I posted this in the wrong thread on accident, because I was in a hurry.
)
My memory tells me it scrolled downwards, go figure.
For that reason, it takes a speed parameter that switches from horizontal (<-) for positive values to vertical for negative ones.
Also, in every shader implementation I’ve seen there was no scroll at all; just a flip/flop of the checkerboard happening at every frame which may give the impression of a scrolling when the content is moving (that is achived by setting the speed to max)
…still my memory tells me different things, but my systems were PAL.
I’m pretty confident that it scrolls only up in NTSC. Someone will have to read into PAL or look at an original PAL set to see whether it scrolls up or down, but I doubt it would be horizontal.
This is right, at least for NTSC. When you add interlacing to this pattern, and flip the checkerboard every two frames instead of one frame (because each pair of frames adds up to 525 lines when interlacing), you should get scrolling, if I understand this right. Whether it scrolls up or down depends on whether the top field or bottom field has that extra signal line.
Scrolling horizontally doesn’t make sense to me at all, in this case at least.
Also, this is only about standard NTSC signals that alternate the phase 180 degrees each line, which isn’t exactly what every console does. I still need to read about PAL.
