Shaders for various emulators

[Dr.Venom]

Originally Posted by guest.r

I reworked this a bit, using some "free" HW abilities to speed things up. Now default STEP is 2.0 but an average of 2x2 colors is instantly calculated by using a bilinear sampler, so every pixel counts. Previously some were left out by using non-1 steps. Default value is working very well now, but i left room for even more speed.

Awesome, the speed up is definitely noticable versus the previous version. Quite an essential improvement, much appreciated!

I wanted to say i changed the horizontal filter too with gaussian one, is a bit slower, but works better with lottes masks at low sharpness. They were not very usable before tbh. Horizontal sharpness range changed also, now it's from 2 to 20 (1 to 5 before) due different processing. And i renamed the "package".

Great change also, the masks definitely look better.

And thanks, I'm honored

Edit2: better halation, better blooming, possibly a nvidia fix.

Thanks a lot for these further improvements, after recalibrating to my personal preferences I'm super pleased with how it looks. In motion it sometimes looks even more impressive, thanks to the dynamic glow and bloom effects. Pure joy to look at..

There's one last thing that I noticed with this version that could be sort of a regression versus the previous version, and it's that the gamma curve seems to exhibit "jumps". You'll notice when running the pluge test and change the "Gamma Input", previously it would sort of gradually change the output, but now it exhibits jumps at certain points.

More precisely if you run the 240p suite (see here: http://junkerhq.net/xrgb/index.php?t...40p_test_suite ) for SNES, and choose "Test patterns -> pluge", you'll see the below picture:




Notice the vertical grey bars (3 on the left, 3 on the right), if you press the fire button twice it switches between grey and blue bars, I'm using the one with the dark blue bars.

Between Gamma Input of 2.4 to 2.27 none of these vertical bars show, but when switching Gamma Input from 2.27 to 2.26 the first blue vertical bar suddenly appears (relatively bright). Then until Gamma Input of 1.77 nothing changes again, but when switching from 1.77 to 1.76 both the second dark blue bar and grey bar both appear (relatively bright).

With the previous shader version the gamma changes would occur much more gradually, i.e. you could adjust Gamma Input very precisely to have the darkest blue bar to be just visible.

Hopefully this last remaining issue/regression can be fixed?

[guest.r]

Hopefully this last remaining issue/regression can be fixed?

Needed to take a thought on this one. Using sRGB buffers speeds things up, but in my understanding they containg 8 bits per color channel only and require a proper conversion. Gamma of 2.4 is correct (minus some nitpickying), using anything else might disturb the colors.
Luckily there is a simple answer to it, a float framebuffer can be used instead (something to be seen only with Retroarch on general). Also means this shader could be no longer usable with GLES or lower versions of GLSL, but it's worth it, since input gama can be tweaked properly.

To setup the gamma look to one's liking there are several viable options now:
- input gamma
- output gamma
- brightboost
- gamma tweak

I advise to use the gama tweak since it doesn't mess up saturation (and i spent some time adjusting it). But, like i said, everything should influence the output.

And a happy new year.

[Dr.Venom]

Originally Posted by guest.r

To setup the gamma look to one's liking there are several viable options now:
- input gamma
- output gamma
- brightboost
- gamma tweak

I advise to use the gama tweak since it doesn't mess up saturation (and i spent some time adjusting it). But, like i said, everything should influence the output.

Thanks man, I think you nailed it (again!). The default gamma as how it's now set is spot on when doing the pluge tests on my monitor. Good to know the preferred way to tweak it, but for now, I'll leave it as it is

Personally I think you've achieved CRT shader perfection. Thanks again, will be enjoying this a whole lot!

HapPy NeW YeAr!

[guest.r]

Hello there again!

I asked hunterk (at libretro forums) about afterglow possibilities with GLSL and there is some.
Total of 7 frames can be used at once for the effect which is enough for approx. 0.1 sec. of afterglow. Long trails can happen with fast sprites only.

So i implemented a tweakable version, looks nice with games which use black color as background. In general we don't want to desaturate an image, so there is a threshold value for the effect.

Some minor changes were also implemented.
First the blooming got faster due to a nice suggestion from hunterk, next is a cool option for the horizontal filter ("Substractive sharpness" - optional), so a gaussian filter can have a cubic/lanczos look. Looks good with cgwg mask.

Cheers...

[Retro-Nerd]

Fantastic work, guest. The glowing effect looks awesome. I think it's time to move the last few sites to "Retrogaming General". This deserves a new thread.

[DamienD]

Originally Posted by Retro-Nerd

Fantastic work, guest. The glowing effect looks awesome. I think it's time to move the last few sites to "Retrogaming General". This deserves a new thread.

I agree, considering a lot of posts here aren't really WinUAE related.

...but I'm not sure which ones to move; can one of you who's been following this thread PM me with the post numbers and I'll move accordingly?

[mcbpete]

I think pretty much everything bar the first two pages is GLSL/RetroArch related....

[Retro-Nerd]

I don't think so. Mostly the last 4-5 pages are Retroarch only. Hard to split. Maybe take the last 2 pages, if you don't want to cut single posts.

[Ian]

I've been thinking about doing something with this thread, I propose this though, Guest.r if you wouldn't mind making a new thread with just your WinUAE shaders in the first post, then I will sticky it in the WinUAE sub forum, then this entire thread can be moved to to another more suitable "emulation" section.

No need to do any massive clean up then, or even think about it too much.

Shaders are listed in the first post, you should be able to edit it at a later date to continue adding to the first post, so it will be very handy for people.

[Retro-Nerd]

There are more WinUAE shaders than you can see attached in post 1 (which was his old and now dead EAB account). Actually the first post is from 2011. Guest did many more since the last 2-3 years.

[guest.r]

Originally Posted by Ian

I've been thinking about doing something with this thread, I propose this though, Guest.r if you wouldn't mind making a new thread with just your WinUAE shaders in the first post, then I will sticky it in the WinUAE sub forum, then this entire thread can be moved to to another more suitable "emulation" section.

No need to do any massive clean up then, or even think about it too much.

Shaders are listed in the first post, you should be able to edit it at a later date to continue adding to the first post, so it will be very handy for people.

Sound like a great idea. I will make a new thread with shaders attached to the first post. Sorry for the OT...

[Ian]

Hehe it happens. I think your efforts are appreciated by those of us who have become graphics whores in the pc era. I know I probably couldn't pay an Ania game now with our some kind of filter in effect.

[Dr.Venom]

===========================================
@DamienD / Moderators. Another option is to cut this thread from post #166 to this very end and move it to the general section under something like "Realistic CRT shader".

That will give you minimum fuss and from post #166 and onwards it's only discussion about this latest (great) shader while not being related to WinUAE. Should provide for a clean discussion onwards and you can keep this thread as is (post #1 to #165 is 90% WinUAE related..)
===========================================

Originally Posted by guest.r

Hello there again!

I asked hunterk (at libretro forums) about afterglow possibilities with GLSL and there is some.
Total of 7 frames can be used at once for the effect which is enough for approx. 0.1 sec. of afterglow. Long trails can happen with fast sprites only.

Great news on the afterglow possibilities. Very cool to have them in GLSL already!

I've been trying out this latest version and the afterglow looks very promising. I did some more extensive tests which leads me to some observations / comments, see below.

Some minor changes were also implemented.
First the blooming got faster due to a nice suggestion from hunterk

Unfortunately Bloom is broken for me in this version . It is jittering like crazy, so bad that it will give me epileptic seizures if I look at it too long..

Changing the Blooming grade doesn't help unfortunately. I can make the jittering somewhat less bad with low values, but the smooth transitions from the previous version are also gone. I guess hunterk's suggestion may not work with all graphic cards (I'm on GTX 1070)?

For me the previous version was really perfect, so hopefully you know of a solution? Otherwise, in "worst case", could you possibly re-instate the previous version? (I would only ask because the previous version was working so well..)

So i implemented a tweakable version, looks nice with games which use black color as background. In general we don't want to desaturate an image, so there is a threshold value for the effect.

Thanks for implementing the afterglow feature . I have been doing some more indepth comparison with a real CRT, but found that with the current implementation I can't replicate some obvious cases when comparing side by side with a real CRT.

In summary the shader is showing afterglow on objects where a real CRT won't, or if you adjust the settings accordingly, will not show afterglow on objects where a real CRT will. With the current implementation it is not possible to have both.

Below is a specific case that illustrates it. The comparison is done with some MSX games on the real CRT. You'll need the BlueMSX libretro core to run these games.

If you start the game Salamander (MSX) and let the intro start you'll see the moving stars as shown in the screenshot below. These stars have very bright and long trails.

These can be replicated by setting the afterglow parameters to somewhat higher values, such as the default values. So far so good.





But then, if you load the game Athletic Land and look at scene one (press "1" on main screen to start the game) it will show a very bright afterglow on the kid when walking / jumping with the shader. On a real CRT there is NO afterglow when walking / jumping with the kid. Having the trails on the kid is actually quite distracting.

The only way that I could replicate that with the current shader is to set both red and blue to zero and green at a very low value. Then it actually will show NO afterglow on the kid, and a very light afterglow on the ropes, which is quite accurate. But then if you go back with these setting to Salamander then there's hardly any afterglow on the stars...

So there must be something else that we're not quite catching yet.

I guess as a testcase, to get closer to real CRT afterglow behaviour, would be to have clear afterglow on the stars in de demo of Salamander, but at the same time NO afterglow when walking / jumping with the Kid in Athletic Land.

With the current shader afterglow implementation this is not possible.

Maybe there's a possibility that in reality only the brightness of green is determining visible afterglow on objects on a real CRT?

Just a wild guess, as I really have little clue how color really works, maybe you have a better idea what could be going on..

next is a cool option for the horizontal filter ("Substractive sharpness" - optional), so a gaussian filter can have a cubic/lanczos look. Looks good with cgwg mask.

Cheers...

That's really cool, thanks for these further improvements!

[Dr.Venom]

I found a nice research paper from 1982 (!) that goes (mathematically) in-depth into the effect of phosphor persistence on image quality. It's more of a theoretical construct modelling the the effect of phosphor persistence on image quality. So no actual data on phosphors used in consumer TV's or anything.

From a quick glance I learned the difference between fluorescence and phosphorescence. Also called "rise time" and "decay time". The latter is of course the "afterglow". It has some graphs and formulas in there how the luminance value is dependant on the luminance history of the phosphor pixel. So when a phospor has a decay time longer than the field rate (16.67ms), this will come into effect.

There are unfortunately no concrete values presented for consumer TV's / Monitors. It would be nice if we could get some actual information on the type of phospors used in consumer grade televisions and monitors. I'm sure the information must exist somewhere, as according to this document the phosphor types are numbered based on their characteristics from 1 to 45. See Table 2 in the document.

Again looking at the blue phosphors, the longest decay time is 80 microseconds, so I guess we can safely dismiss blue as a factor of importance for afterglow from the shader as the decay times for blue phosphor are WAY shorter than a field. Saves another config parameter

Anyway here's the link:

Analysis of image smear in CRT displays due to scan rate and phosphor persistence

[guest.r]

Hi there. I must admit there are some limitations on the Retroarch GLSL framework and shader/buffer implementations, which make a faithfull representation of the afterglow effect very hard or nearly impossible.

The main problem lies in the fact that the frame history in glsl is limited to 6 previous frames (a total of 100ms history) and that buffer/display "discrete" timings differ from "real analogue" phosphor phenomena. There is no simple adequate bijection.

For example, a fast moving dot of white color on black surface has an afterglow time greater than 50ms on real crt, but fixed 16,7ms with a shader - there is no trail but quickly dying dots. No way around that because even extra passes can't handle the timing - they process too fast by default and any extra delay would make the shader stutter the gameplay.

A characteristic of the shader is that slow "sprite" pacing from frame to frame produces more visible effect than fast pacing.

I implemented the shader anyway, because it produces an interesting effect.

Last but least, can you try if this version fixes the blooming? Another AMD/nVidia discrepancy.

[Dunny]

Consumer CRT TVs were badly affected by interference and cross-talk on the RF cable. That has not been emulated yet by any shaders, just attempts at doing phosphor glow.

I'd love PAL RF emulation too.

[Dr.Venom]

Originally Posted by guest.r

Last but least, can you try if this version fixes the blooming? Another AMD/nVidia discrepancy.

Unfortunately it doesn't, still the same issues with extreme jittering, and transitions also being very "on/off" where the good version would do it very smoothly. With regards to that smoothness: like the Metal Slug video example the previous good shader would do it very smoothly like in the video, and now that part sort of transitions between "blown-up" and normal. There's no smooth gradual rise and decay. Changing the blooming factor doesn't help.

Hi there. I must admit there are some limitations on the Retroarch GLSL framework and shader/buffer implementations, which make a faithfull representation of the afterglow effect very hard or nearly impossible.

The main problem lies in the fact that the frame history in glsl is limited to 6 previous frames (a total of 100ms history) and that buffer/display "discrete" timings differ from "real analogue" phosphor phenomena. There is no simple adequate bijection.

For example, a fast moving dot of white color on black surface has an afterglow time greater than 50ms on real crt, but fixed 16,7ms with a shader - there is no trail but quickly dying dots. No way around that because even extra passes can't handle the timing - they process too fast by default and any extra delay would make the shader stutter the gameplay.

A characteristic of the shader is that slow "sprite" pacing from frame to frame produces more visible effect than fast pacing.

I implemented the shader anyway, because it produces an interesting effect.

I think I understand your reasoning. I see there's a limitation in the "step" fading caused by the frame based emulation, opposed to the analog continuous fading that real phosphor shows.

That said I feel there's one thing that may be worth considering.

In the current approach I guess you're taking the lightness of the RGB value/colors combined as the "input value" to decide how much afterglow to apply. For which that afterglow the user then can modify to have only show Red, Blue and Green, or in other words modify the "output value".

In the shader this causes for example a fully blue sprite to show afterglow on red and green, even if the user sets blue to zero. This behaviour is very much opposed to how real phospor will show NO afterglow at all on fully blue objects.

As such would it be possible -as a testcase- to add the lightness of Red, Green and Blue as separate configurable "input options" (i.e. such that for example the lightness of Green can be the only factor from which it is calculated how much afterglow will be applied to the output ("RGB" factors)?

This would allow to keep the output options on red and green high, while not having the shader artificially adding red and green afterglow to blue objects.

From a theoretical perspective it seems relevant to be able to configure the afterglow on the "input side" also, rather then only on the "output side" (as currently?). It would be the only way to properly simulate the effect for blue phosphor? That said I don't know whether this is realistically achievable from shader technical perspective.

Btw currently I'm achieving the most realistic effect by having only green active at <= 0.07 and saturation at zero. It's like 80% close to the real deal, so I'm very happy to have the feature in there, let me be clear about that!

While playing with the saturation on the afterglow it got me noticing something on the "normal" glow on a real CRT for saturated colors. It seems generally that for saturated colors the glow is actually de-saturated. So I was wondering whether the saturation parameter that you have in there for afterglow, could you implement that for the normal glow also? (No worries if you feel that's being overdone, I'm just asking..)

To be honest, I frequently have to pinch myself to realize this shader is for real .

[Dr.Venom]

Finally found specific information on phosphors used in Color TV's, which may help in creating a more authentic afterglow in the shader. Things are a little bit different from what we think.

The book Flat-Panel Displays and CRTs by Lawrence E. Tannas lists the phosphors user in Color TV's in Table 6-2 of the book. Below is a screenshot with the important features highlighted.


As you can see the "Decay time" is defined as the time required for the intensity to decrease to 10% of its peak luminance. Now look at the times for R, G and B; they are respectively 0.9 milliseconds, 60 microseconds and 25 microseconds!

This effectively means that what we're seeing and calling "afterglow" is the dying out of the phosphor from its 10% luminance level to zero! I guess this is quite different from what most people would think/assume... (assumption is the... )

If I'm right this means that for proper shader simulation the very first frame out of the 6 history has already decayed to 10% of max luminance, i.e. the 1-6 frames of history are decaying from 10% to zero, instead of 100% to zero.

[guest.r]

Hello again. I've been bussy lately, so sorry for the late reply.
I'll need a bit of tinkering not to spoil the current effect.
Discrete timings of modern displays/gpu's really make hard cuts on analogue sensibilities. The time step is fixed to 16.7ms with 60Hz emulation, so microsecond delays for example can't be implemented.

Currently i'm very interested to fix blooming on late nVidia cards, so a feedback is welcome.

As a bonus i added the "different scanlines" option, using an alternate formula.

In the shader this causes for example a fully blue sprite to show afterglow on red and green, even if the user sets blue to zero.

"Blue" colors can have +50% of red and mostly green as RGB values. Theese values are then calculated into the afterglow. It's best tested with a screenshot and RGB palette "analyzer".

Anyway, anyhow i'll try to add some more options to the shader in the future (like glow saturation, new afterglow timing formula etc.).

[Dr.Venom]

Originally Posted by guest.r

Hello again. I've been bussy lately, so sorry for the late reply.

No worries .

Currently i'm very interested to fix blooming on late nVidia cards, so a feedback is welcome.

Unfortunately it's still not working. It's about the same as previously.

The last excellent working bloom version is the one from post #182.

The current version exhibits the issues I mentioned in previous posts. I'm not sure if it will help but I noticed that if you go back to the version from post #182 and set the "Avg. Luminance step" to a very high value (i.e. "less accurate"), it somewhat gets more like the current version. It is jittering more and the fades are not very smooth, only the current version is even worse in that respect.

Another example is that in the Metal Slug X, when the title screen is printed (the letters banging on the screen) and then the fade to fully white and back to normal, with the good version the raster bloom would also be VERY smooth, in line with that fade to white and then smoothly back to normal. Now that part zooms (blooms) much more quickly than the screen color fade.

I also noticed that on some screens it even starts to bloom (off/on) when only little things like the tiny "insert coin" are blinking. All in all it's way off

Is there any possibility that you could go back to the one you initially implemented? (In post #182). I'm just a little worried that hunterk's suggestion, even when it will "work", is just not going to be as accurate as your initial implementation (which was really perfect!)

As a bonus i added the "different scanlines" option, using an alternate formula.

That's really cool. I'm liking how this simulates more of the look of a Trinitron / high(er) TVL set . Very good option to have in there!

"Blue" colors can have +50% of red and mostly green as RGB values. Theese values are then calculated into the afterglow. It's best tested with a screenshot and RGB palette "analyzer".

Of course, I see what you mean..


Lastly, I'm finding that I like experimenting with some settings for the shader that go slightly outside the default boundaries you've set. So with regards to these range settings could you possibly change the default ranges for Glow and Radius from

// Parameter lines go here:
#pragma parameter TAPSH "H. Glow Radius" 4.0 1.0 6.0 1.0 
#pragma parameter GLOW_FALLOFF_H "GLOW_FALLOFF H" 0.30 0.10 1.0 0.01

to

// Parameter lines go here:
#pragma parameter TAPSH "H. Glow Radius" 4.0 1.0 10.0 1.0 
#pragma parameter GLOW_FALLOFF_H "GLOW_FALLOFF H" 0.30 0.01 1.0 0.01

(And the same for the vertical).

And change the step value for D65-D50 from 10.0 to 5.0?

#pragma parameter WP "D65 to D50 strength %" 0.0 -100.0 100.0 5.0

It would save me changing those ranges manually with the new releases. (For example for glow it seems on my monitor, which is quite bright, that glow at 0.02, radius at 8.00 with falloff of 0.02 seems quite accurate to the real CRT monitor that I have next to it..)