Depends if you want to recreate a messy composite. Perhaps lower comb filter strength and reduce chroma resolution even more?
e.g. here is same game, on same TV on composite on Sega CDX (almost invisible rainbow) and Genesis model 1 which had the worst composite available at the time. It’s not they wanted it to be there, it was a side effect of using a cheap/junk composite encoder, probably leaving tons of cross talk between Y and C or even (most definitely) in-between C.
Added a PAL switch for those old ZX Spectrum games heh, some Stella specific Atari 2600 frequencies too.
While FUSE outputs a 320 resolution, that’s not accurate as Spectrum would output like 352 with borders, and active 256, strange the artifacts only appear properly on PAL and PCE256 (same clock with SNES256) mode (seems active pixels is the defining factor). All frequencies are adjusted for PAL 4.43Mhz while PAL=On.
Try this heavier version that uses a real time FIR in the likes of “ntsc-adaptive” (but not precalculated). Tell me what you think. Probably more what you are after
Press CTRL-SHIFT-S to download it and use it before some CRT shader
Simply, PERFECT. Thank you, buddy.
Thanks to you, Guest and all geniuses around. You simply make miracles to happen.
Greetings @DariusG, I just wanted to share my gratitude and appreciation for your work after taking 3 of your new shaders for a spin.
I have a few questions and comments but I can’t get into them now.
The things I’m wondering about the most are the different PCE clocks. How is a user supposed to know which one is the correct one to use in any given situation? Can this parameter choice be automated?
Also can the settings be internally normalized so as to provide consistent settings (blending, chroma artifacts and sharpnes) if a game is switching modes on the fly for example?
Sure it can, just need to set a switch as “PCE mode” then internally
pcemode==1.0? OriginalSize.x < 300.0 ? PCE256 : PCE320;
320 should be ntsc x 2 while 256 should be SNES clock. MD320 should be ntsc x 15/8.
The difference of PCE is it does (afaik, and most other systems do the same)
227,5 (180’ steps per line, ntsc default, dot repeats pattern ever 2 lines)
instead of 227,333 of SNES (120’ steps per line, diagonal, dot repeats pattern every 3 lines).
//clock
//MD/MS256/PCE256 & SNES/NES256 ntsc x 1.5
//MD320 ntsc x 15/8
//PCE320 ntsc x 2
//ATARI 2600 ntsc, but stella outputs 320 so same with PCE 320
pixPos = floor(vTexCoord.x*SourceSize.x)*PI*2.0*ntsc/clock
//all use 2 phase 227,5 except SNES/NES 3 phase (120')
line = mod(floor(vTexCoord.y*SourceSize.y),2.0)*PI*2.0 // 2 phase
line = mod(floor(vTexCoord.y*SourceSize.y),3.0)*PI*2.0 // 3 phase
vec2 burst = vec2(cos(pixPos + line), sin(pixPos+line);
These people that designed this ntsc color transfer were absolute genius, not appreciated as they should imo
Crt_consumer has a slang version? I thought it was glsl-only, damn. That means I can put it through its paces properly 
Thanks for your amazing work.
Are there updates for crt-consumer-1w-ntsc glslp ?
I thought to leave it as it is, simpler and faster. Of course the newer version is better, perhaps if there is demand i’ll port the new version to GLSL too.
You are the best .
I hope update glsl version if you want any time
Yes, there is demand for continuous development and improvement for CRT-Consumer-1w-NTSC-XL.
Here is another composite secret on these 2 screenshots.
Raw rgb, dithering is pretty clear and obvious
A gray scale representation, look how dithering is almost gone invisible, how close dithered pixels are. Not by luck, that’s the artist’s brilliance there. This is our luma representation in a composite signal. Add some bluriness to this due to luma filters, add the colors of chroma on top, that is more like drawing with a crayon or something due to low bandwidth and you got dithering blend.
In conclusion, when Luma dithered pixels difference is large it won’t be able to blend. When in S-Video the signal evades some Composite Luma filters as it is clean already so it stays sharper, not blending that easily as in composite.
raw
Real early Genesis model 1 Composite screen capture
crt-consumer-1w-ntsc-XL after reducing Luma bandwidth a bit (and increase comb filter)
Some small changes and added reflection from crt-cyclon
https://github.com/metallic77/shaders_glsl-slang/blob/main/1084s.zip
Even better with the reflection - thank you so much.
Will there ever be a fully modular reflection shader that can easily be appended / prepended to any shader / preset?
Probably hard to implement without messing scanlines etc.
Works better on integer-overscale, “mask” aligns better and creates a more convincing effect.
Thanks for the clarification and for your work - in fact using integer scale max is even better - great work and thanks
A note about masks and why they are mostly inaccurate on most shaders at 1080p (the reason they feel “weird”, you can feel something is wrong).
The gap between the triad of pixels is around the same size of one R/G/B strip, in reality it’s around 20% of the total pixel size. Long story short, in order to be accurate the gap should be minimum 1 pixel and 3 pixels should be used for RGB stripes on every screen, that makes 270 TVL accurate pixels possible on a 1080p, 360 TVL on 1440p and so on. Every other way e.g. CGWG mask etc will create a mosquito mesh pattern as the gap will be same size with all 3 RGB stripes.
270 TVL but accurate on 1080p, around what a cheap low end 14" crt would do.
while 1440p will start looking more like a 20" crt at 360 TVL.
A 4K will do 2160:4 = 540, around a 14" PVM or 1084S but accurate.
So when using another mask like CGWG on 1080p we’re only trying to force the monitor to do something that isn’t capable of doing. The “pixels” are not accurate in any way and will feel weird. Should always be Red-Green-Blue-Black on every screen. Or the other way on BGR panels.
