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.
I’ve seen it scrolling horizontally with an Amiga 500+A520 PAL RF modulator connected to a cheap lg panel
…the weird Amiga scrolling dots were probably due to this particular pattern over the 1px blue line, see the naked one:
However with the speed set to 8.0 and screen set to 50hz, in koko-aio it looks exactly like the following video.
https://mega.nz/file/lT9QjCwD#Uzv-IBasfmlaoqS_r-1Dm8tMONZzwqfKVnYHPRKbpks
An old PAL Colecovision doing something similar:
https://mega.nz/file/oeUnlCSI#XBHYYCfwXWV9l-TYfglNMnY6UTtIR8x6oOvecBH7u-o
It would be totally possible that the Tv itself was doing something weird with the analogue signal tho.
I remember @DariusG to have tried a similar setup, maybe he can confirm or not if that happen with CRTs.
I see what’s happening now. It’s a difference between NTSC and PAL.
Take this with a grain of salt since it’s from Wikipedia (which has failed badly at documenting video standards in past years), but Wikipedia’s pages for NTSC and PAL show that NTSC has 227.5 color carrier cycles per line, while PAL has 283.75 color carrier cycles per line. (Note: 283.75 is stated explicitly, but 227.5 comes from dividing the color frequency by the line frequency.)
In NTSC, the .5 at the end of 227.5 is what causes the phase to turn 180 degrees each line, resulting in a checkerboard. PAL has 283.75 instead, which causes diagonal lines, not a checkerboard. The video of the Colecovision shows that these diagonal lines are scrolling to the right, even in non-interlaced video, unlike NTSC where the checkerboard only scrolls upwards in interlaced video.
About that. On your video of the Amiga, the white line under the words “Easy Living” has dots scrolling on it. That’s probably caused by comb-filtering in the CRT. (Edit: I realized what you meant by posting that screenshot. The cause probably isn’t a comb filter, then.)
On the other hand, the fact that your ColecoVision is scrolling right, while the Amiga is scrolling to the left, must be caused by the ColoecoVision and the Amiga somehow. The console is what determines the color carrier’s offsets and rate.
I want to make one last note here that the games Battletoads and Battletoads Double Dragon on NES (while you’re playing a level) in NTSC has a similar scrolling diagonal line pattern, but it’s a 1/3 offset instead of 1/4.
It’s 227 at odd and 228 at even (vertically) to be precise. So every other line there is 1 pixel shifted. That’s not a pixel actually, it’s color info. Pal switches phase every other line too (+ PI). Tried to do something like that in ntsc-simple pal systems like zx spectrum, check it out. Not far from real screenshots.
