CRT-Yah! A new shader chain

[anikom15]

@Squalo

wow cool stuff Can it simply be added to a chain so that any crt shader will take advantage or does it need to be implemented by the dev?

It can but you need to do it in this order:

1. Any chain of shaders as long as the final output is gamma corrected
2. phosphor-luma.slang
3. phosphor-chroma.slang
4. A linearization shader that applies a 2.4 power gamma correction, because the output from phosphor-chroma is in linear space
5. Any chain of shaders

This is because these shaders are part of Scanline Classic and there is a shader called scanline-advance that comes after it (does interlacing, geometry, and upscaling) and it requires a linearized input and does the gamma correction as the last step.

You also need to use float_framebuffer = true for both shaders.

[Squalo]

@Jezze it was a driver issue after all. Tried them all and under d3d/glcore jitter breaks when prepending shaders, at least on my AMD-based computer. Works perfectly fine in vulkan. I hope some nVidia/Intel users will report their experience. I also updated my review. It’s now more accurate, in accord with our findings

Wow that was quick, appreciate it. I will try the new version today when I get home, but yeah it sounds exactly like what I had in mind. Edit: you actually made it a slider, instead of a simple switch like I had proposed. That way we get the best of both worlds. This is perfect.

I have a quick question regarding brightness compensation. I configured a chain for a really bright game and when I apply it to different ones I notice that they still look great. Your implementation is adaptive, right? If I understand it correctly, it’s in fact more than just compensation, and can be used (to a certain extent) as an automatic brightness control. Kind of like a compressor-limiter in audio terms, if you know what I mean.

@anikom15 cool, will try that too. What kind of visually perceptible changes should I be looking for?

[Jezze]

Good to know the jitter problem is only caused by certain video drivers. I usually only use Vulkan, because it compiles 10 times faster than others, at least on my machine. I will keep looking into this problem with the other drivers, maybe I find a solution, but I cannot promise.

I’m glad you like the new parameter for the Black Lightening. I’ll raise a pull request in the upcoming days.

In regards to the brightness compensation: It’s mainly influenced by the shaders own settings for scanlines and mask. However when using the “additive” mask blend mode, the brightness of the current pixel is also taken into account.

[Squalo]

I’m actually switching to vulkan for all the cores that get along with it. I had been thinking about it for a while anyway. Your shader (which I will be using a lot) is the straw that broke the camel’s back, so it’s perfectly fine by me if scanline jitter stays as a vulkan exclusive, and I can’t see anyone complaining about it

@Jezze

In regards to the brightness compensation: It’s mainly influenced by the shaders own settings for scanlines and mask. However when using the “additive” mask blend mode, the brightness of the current pixel is also taken into account.

Nice. It does an excellent job.

[Squalo]

Just a little update. Scanline jitter is fixed in glcore with latest AMD drivers.

[Jezze]

Just raised a PR with the new “Black Lightening” parameter. The default setting of 1.0 keeps the original appearance.

@Squalo That’s interesting and confusing at the same time. Because the only thing the jitter code does is alternating the texture coordinate over time depending on the frame rate. But good to know that it now works, at least for the glcore (and vulkan) renderer.

[Squalo]

Yes it is. I’ve been testing things thoroughly to be sure that my analysis/review was fair and consistent. Another weird little spin is that the effect is less obvious in glcore than vulkan. I. E. you have to lower the beam filter parameter to achieve the same “jitter intensity”. It’s working great nonetheless with the new drivers. Again, it would be nice if more users tested it, but the forum seems a little quiet these days.

[ynnad4]

hi, i’ve looked and its nice.

do you think is possible to incorporate ntsc rainbow effect on future ?

i mean for megadrive or nes/snes

[Jezze]

I’m not exactly sure how the “rainbow” effect is defined. But you can set the following parameters and get something similar; the rainbow lines go diagonal though.

NTSC_PROFILE = 5.0
NTSC_QUALITY = 3.0

NTSC_PROFILE = 5.0 increases the fringing and artifacting (the slider only allows a maximum of 3.0) and NTSC_QUALITY = 3.0 makes use of 3-phase modulation with field merge (which basically deactivates the flickering).

[ynnad4]

I checked but didnt give something remotely close. Diagonal rainbow is for NES, though.

Rainbow banding with composite video - Presets for Sega Genesis Games

There’re quite a couple of recorded playthroughs on Original Genesis Console, but most specially with Rainbow Banding + composite video, in case any of these are useful for current presets or make new ones. All credits to their original authors. Links in file: (all youtube) https://1drv.ms/t/s!AtKS8lBxejvUg2Z_fxWsiGEYu60P?e=Jjqqog

That’s a small text file where i saved several original Genesis Rainbow records, in case can be useful to see how the effect does.

Unless you referred to something else as “not sure how rainbow is defined”.

Still, look very good with dithering alone