Shaders for various emulators

[guest.r]

I think i got it right now with mipmaps and blooming. If nothing works, i'll revert to step counting.
I also implemented the suggested parameter adjustmensts.
The shader is also setup in a more neutral state, since presets can be tweaked and saved.
Feedback is welcome, hope this is a good working version.

Edit: fixed CGWG mask parameter step.

[Dr.Venom]

OK, it's much better now, but still not quite as good as it was.

The remaining issue is that while the mslug test works good now, it doesn't work as accurate with rtype. Not sure if this will help but the issue is comparable to the one I posted about in post #176:

Originally Posted by Dr.Venom

While finetuning I noticed some interesting differences with different games, in the sense that mslugx is somewhat more lenient in the values you can choose to have it replicate the most prominent bloom fairly accurately, but with that more lenient setting (i.e. a higher luminance setting) it will "fail" with for example R-Type (Arcade).

In more detail: If you let R-Type run in demo mode and look at the score bar at the bottom, than on a real CRT this is very solid (no jittering) during the demo levels, apart from the occasional explosions or white flashing happening when some opponents get hit. Thus the score bar at the bottom is say for 90% of the time during demo mode not jittering at all. This can actually only be replicated - when bloom is at 2% or 3% - by having the Luminance factor at 1.

With the current shader I cannot get rtype to show the accurate response described above.

So the testcase would be that there should be NO jitter in the bottom score bar at the part below, with bloom at 3%, apart from a very rare very tiny jitter. It should be completely stable 90% of the time. Just a picture from the internet, but when referring to the first demo level I mean the one shown below:





On another note, I've been using the alternate scanlines method for somewhat longer now (alt.scanlines = 1) and I'm loving it! With some tweaking of the different parameters it gets the image (in action) perceptually even closer to real CRT. Awesome, I don't think I'll be going back to the default scanline method .

In that regards, could you possibly change the default step value for "CGCW Mask Str." from 0.10 to 0.05? I'm fiinding that with the Alt Scanlines option enabled I like to have the mask strenght at 0.45. ( ).

#pragma parameter CGWG "CGWG Mask Str." 0.4 0.0 1.0 0.05

Lastly, I can't help myself but showing the below pictures. While looking for the R-Type above image I noticed these screenshots of real CRT's. Just look at the size of the glow on objects!






The photographs do exaggerate the contrast on the glow, but if you look at a real CRT in a dimmed light room (more importantly no direct light reflecting on the tube) that radius of glow is really there.

I guess when it comes to perceiving (after)glow on CRT there's quite a bit of difference when looking at a CRT in "day" or "night" mode (the pictures above more resembling night mode..). Which implies that when matching glow etc to real CRT, it also depends in what light circumstances the comparison is made.

I never really noticed before, but I accidentally had a light bulb shining into the CRT, and interestingly the blackness and contrast evaporates. Move the direct light bulb away, and the CRT's contrast and blackness are back again. Glow and afterglow are much more perceivable with the latter.

Come to think of it, this is probably why in the Arcades in the 80's and 90's the Arcade cabinets were actually developed purposedly with the CRT monitor at the back, with sides and top of the cabinet preventing direct light onto the monitor. Anyway I'm digressing... (yeah, it's so easy with the topic of Analog CRT magic... .)

[guest.r]

Yeah it's difficult to grasp the voltage regulator dynamics within a shader. This step can be very slow if we want it to be more accurate. Mipmaps are calculated on average color basis afaik, then i introduced p2 (a.k.a color length) norm to give more weight to pure red, green or blue colors. Parameter "Raster Bloom Grade" is introduced to control the intensity a bit (lower = stronger). I think it could get really hard to understand the real CRT math behind.

In that regards, could you possibly change the default step value for "CGCW Mask Str." from 0.10 to 0.05? I'm fiinding that with the Alt Scanlines option enabled I like to have the mask strenght at 0.45.

NP, it's a decent proposal.

Personally i'm interested how this shader looks on a IPS /1440p+ display, since everything could look better there and integer scaling works a lot nicer.
Maybe some day.

I also think CRT TV's were there to play some tricks with our perception and higher resolutions, better viewing angles, higher refresh rates plus HDR will open some new dors to shader magic.

Back to the shader, i posted the new version above.

[Dr.Venom]

Thanks for continuing to look into this.

Unfortunately the updated version still exhibits the screen jitter in the r-type demo roll first level. It's especially when the whole screen is filled with the green dots (about half way in that first level demo roll), then it is continually zooming in and out multiple times per second.

Is that level completely rock solid for you (no jitter, like real CRT)? If so, maybe the mipmap method (still) works different for your card?

Sorry to keep hammering on about this, because apparently it's working good enough in your setup, but for my setup it's just quite a step back from the #182 post version. More importantly like in the Rtype level it's just too much off and I get unnerved by the continuous jitter in some parts of the level, that I'm forced to set the feature to off.

Is there a possibility that you could implement both that previous method and the current method and have the user switch between them if they like? I imagine it could possibly involve having two different presets and subfolders in the shader package, or would that complicate future development too much?

Personally i'm interested how this shader looks on a IPS /1440p+ display, since everything could look better there and integer scaling works a lot nicer.
Maybe some day.

Definitely, I'm very much interested in that also.

That said, the current shader is just amazing for what it does within 1080p, ticks all the important boxes and provides such a great experience already that personally I'll be fine to stick with 1080p for some time to come.

[Dr.Venom]

Small, but important update.

I just copied the old "avg-lum.glsl" (from the 29th dec version) into the current "guest" folder (overwriting the current one) and now the Bloom works again like it did before! Both testcases mslug and R-Type are working properly now!

Now I'm wondering, would this be a proper solution for me, just keeping the "old" (29th dec) avg-lum.glsl, or does doing that have an adverse effect on other parts?

Another small thing I noticed with the alternate scanlines method is that there's a little "banding" when not using integer scale. I know from MAME's hlsl shader there's a setting called "oversampling" that does away with banding mostly in the mame hlsl shader, so I looked it up here:

https://github.com/mamedev/mame/blob...3d/d3dhlsl.cpp


If you look at the code at line 1657 it does this:

int source_width = width;
    int source_height = height;
    int source_screen = screen;
    int target_width = int(prim->get_full_quad_width() + 0.5f);
    int target_height = int(prim->get_full_quad_height() + 0.5f);
    target_width *= oversampling_enable ? 2 : 1;
    target_height *= oversampling_enable ? 2 : 1;
if (win->swap_xy())

It seems it's doubling the internal source width and height it's working with to do away with most of the banding?

Could such an "oversampling" feature possibly be included with the current shader, to do away with the minimal banding that's occuring when using the alternate scanlines method? (At non-integer scale at least.)

[guest.r]

It can't be controlled by shader parameters, since they can't affect buffer sizes. It could be hard-coded into the preset, but i'm avoiding it, since it might break things.

You can try to modifiy the preset:

shader8 = shaders/crt-guest-dr-venom.glsl
filter_linear8 = true
scale_type8 = viewport
scale8 = 2.0

I tested it and the scanlines are more even, but masks are broken.

A good compromise is to introduce integer scaling with smart overscan (this is doable). There are still many scanline issues with 1080p in general.

[Dr.Venom]

Well at least it was worth a try

A good compromise is to introduce integer scaling with smart overscan (this is doable). There are still many scanline issues with 1080p in general.

Sounds great, what would the smart overscan do?

Btw I noticed that just adding back in the old avg-lum.glsl takes a bit of a performance hit. At least now I know the 1070 also has a fan haha. I guess that's why there were 3 passes with 0.5 size in the old setup? I tried adding those back in also, but now all I get is BLUR ART. I knew it wouldn't be that simple .

[DamienD]

Ok, considering there has been no movement regarding splitting all "non-WinUAE" shaders / posts from this thread: Corrected shaders for WinUAE

...I've now done it myself.

It's now up to you guys; specifically guest.r + Dr.Venom; to go through this new thread and let me know if there are still any WinUAE shaders located here; which I'll then move accordingly

[guest.r]

@DamienD: Yea it went a lot off, thanks for splitting the thread. If posts from #18 to #33 could be moved back, it would be great. Thanks again for understanding.

@Dr. Venom:
This is the latest "stable version". Blooming is back to the old ways, but should be a bit faster now or fast enough (still needs testing).
I introduced the "Smart Integer Scaling", since i noticed in the past that these ways have it's fans. It does some "decent" overscan withs "half" of the games, but seems OK otherwise.

[DamienD]

Originally Posted by guest.r

@DamienD: Yea it went a lot off, thanks for splitting the thread. If posts from #18 to #33 could be moved back, it would be great. Thanks again for understanding.

Thank you and done

Do you want this thread renamed to something else?

[Retro-Nerd]

Originally Posted by guest.r

Personally i'm interested how this shader looks on a IPS /1440p+ display, since everything could look better there and integer scaling works a lot nicer.
Maybe some day.

I can assure you that it looks great on my 4K Panasonic LCD TV in 2160p. Awesome shader.

[guest.r]

Originally Posted by DamienD

Thank you and done
Do you want this thread renamed to something else?

I think it's OK as it is since Retroarch really covers a lot of different emulator cores. Maybe other shaders will be dicsussed here also...

I can assure you that it looks great on my 4K Panasonic LCD TV in 2160p. Awesome shader.

Thanks for sharing.

Anyway, i optimized the shader to run more faster, put it into a "neutral" position, explained some parameters, added a -1.0 (no)mask option.

I'm avoiding to put too much stuff in it because standard control trough parameters (in contrary to editing the #definers) in conjunction of shader code flow (like "if" statements) doesn't work like on cpu's, but garbage code is also computed-discarded.

I guess this could be the end version for the time being, good comments are welcome though.

[Dr.Venom]

Hi,


Thanks for this latest version. The Smart Y Integer Scale feature is working lovely, very useful with some games/cores, especially when using the alternate scanlines option.

BUT, you left out the "Substractive sharpness" . I really settled on the look of it and generally am using between 0.15-0.20 of it. If you'd rather not have it in for speed reasons or something, is there a possibility to have it in there, but commented or something. I wouldn't mind commenting/uncommenting someting in the shader to have this feature enabled.

Preferably it's just in there of course

I guess this could be the end version for the time being, good comments are welcome though.

In its current state it really feels complete, so I understand to finalize it.


In that regards I think the "Do R.Bloom Overscan" may be more clear if it would say "R. Bloom Overscan Mode"? Just to have the "Mode" in there so that people understand it's a way of how the bloom sizing is handled (outside-in or inside-out or in the middle..) and not a generic "size of overscan" setting (people may think 0=off, and 1 and 2 size).

And just for aesthetics maybe also change the "GLOW_FALLOFF H" and "GLOW_FALLOFF V" parameter titles to something more readable?


Other than that perfect!

[guest.r]

Hello there,

substractive sharpness is a bit glitchy, but i think i've made it better now. Has the same glitch as crt-hyllian glow, which is that some pixels turn out a bit "isolated and thin". Needs a special case scenario to notice it though. If this is disturbing, lower value is to be used.

As i said it works a bit different now, so if one was before using 0.25, now 0.10 should do the same. I'll leave this as it is for now, since it's a interesting hack in general.

About renaming the parameter descriptions, done and done. I decided to use the term "grade" instead of falloff (like from dictionary description: "The next hill has a really steep grade.").

As always, good comments are welcome.

[Dr.Venom]

Hi again,

Thanks for adding back in the substractive sharpness, I've recalibrated my settings and it looks great!

BTW, the version from the previous post showed some scaling issue when running PS1 stuff, but I also noticed on libretro git an updated version of the shader (also downloadable via the online updater), so I've been using that one.

For the blooming it still does that bobbing in places sometimes, but to be honest it's working so very great that I happily decided to stick with it. Very very nice to have the TATE mode in there also (it was something I was about to ask! )

Originally Posted by guest.r

About renaming the parameter descriptions, done and done. I decided to use the term "grade" instead of falloff (like from dictionary description: "The next hill has a really steep grade.").

Works for me

Now there's one last thing that I'm wondering if it could be worthwhile to look into some more. It's about Dot Pitch and more specifically the difference in Dot Pitch between CRT Televisions versus CRT monitors and CRT in general versus (high resolution) digital LED displays.

This is all a bit speculative, but maybe there is something to improve the shader further.

I've been making some very high resolution screenshots of my real Sony 14" Trinitron connected to a PS1 that helps illustrate things.


The effect of Horizontal Dot Pitch

If you look at the below close-up shot of my Trinitron 14" CRT you can clearly see the stepwise increase in blackness between phosphor dots (horizontally) when going from 1) "triple RGB" dots, to 2) "dual (RG, RB or GB)" dots, to 3) "single (R, G or B)" dots.




So I imagine the size of the Dot Pitch can have some impact on how a picture looks:

If I imagine some theoretical Dot Pitches like e.g. case A: 0 (zero) versus case B: 10 mm (keeping monitor size constant) and a completely single R, G or B color image (i.e. completely blue), then it isn't hard to imagine the blue screen will look different for Case A and B. In Case A the screen will be continuous blue, while in Case B there will be large black gaps between the individual dots.

If the above is the case than any other (smaller) variance in Dot Pitch will also cause a difference, how detectable largely depends on the size of the difference I guess?

Differences in Dot Pitch

Here are some Dot Pitch values for different sets* (see crt faq here and wikipedia on Dot Pitch here):

1. CRT Monitor: 14" Sony Trinitron - 0.25mm
2. CRT TV: 13 inch GE - .60 mm.
3. CRT TV: 19 inch Samsung - .75 mm.
4. CRT TV: 25 inch RCA - .9 mm.
5. LED screen: 15.4" 1920x1200 WUXGA - 0.17mm

Conclusions and relevance for shader authenticity:

A - CRT TV has about double the Dot Pitch of a CRT Monitor
B - There's a difference between the Dot Pitch of same size CRT monitors versus LED monitors.
C - Dot Pitch results in "Dynamic" spacing between dots (i.e. depends on video content) and this specific effect is different from the STATIC Aperture Grill, that is always there and of the same size (in the case of Trinitron dividing each set of red, green and blue stripes). Albeit perceptually the one may reinforce the other?

The important question then is, is there a possibility to improve the authenticity of CRT shaders by incorporating a proper simulation for A and B above?

Since they may perceptually reinforce eachother, a possible route could be a more configurable CGWG mask? (It's the only mask for me currently that gives a faithful impression of real Trinitron on 1080p).

Some things to possibly explore:

Maybe it would need an additional dynamic mask that only gets applied for level 2 and 3 source pixels, on top of the CGWG mask?

Or would only applying the CGWG mask every other two pixels give a good approximation of "TV mode"? This would allow for a combination with a higher Mask Strength setting, possibly resulting in a more coarse "double Dot Pitch / TV mode", while remaining brightness largely?

Have three levels of user configurable strength settings for the CGWG mask, such that the level 2 and 3 dots can be emphasized with darker mask settings:

1. CGWG mask strength parameter for {R, G, B} source pixels that are {pos, pos, pos}
2. CGWG mask strength parameter for {R, G, B} source pixels that are either
   {0, pos, pos}
   {pos, 0, pos}
   (pos,pos, 0}
3. CGWG mask strenght parameter for {R, G, B} source pixels that are either
   {pos, 0, 0}
   {0, pos, 0}
   {0, 0, pos}

I'm not sure if any of the above can help in making the shader (even) more authentic, but if you would see a possibility for incorporating something it would be great if it could be with the version from the libretro git repository, since that's the one I'm now calibrated to..

Last but not least I've attached a very high resolution close-up shot from one of the loading screens at the beginning of Adventures of Lomax (PS1 game by the makers of Lionheart on Amiga) on the 14" Trinitron. Beam dynamics extravaganza!

[guest.r]

Yeah, i have been having similar ideas too for a while. If you look at crt-classic for fs-uae you can see some mask "experiments" in this direction.

I updated the shader, now masks 5 and 6 are added, should have a bit of a more trinitron look (especially mask 6).

A decent look can be achieved with tweaked alternate scanlines and some increased gamma-out.



Edit: new version of alternate scanlines (2.0). Should produce a more even image at non-integer scaling.

[Retro-Nerd]

Ah, thanks for the more Trinitron mask style. Looks great.

A decent look can be achieved with tweaked alternate scanlines and some increased gamma-out.

Indeed. Looks pretty close to CRT-Royale now with alternate scanlines. But i think your afterglow effect is better.

[guest.r]

Thanks for giving it a try.
Feedback and suggestions are always welcome, good or bad.

[Retro-Nerd]

I don't like screen curvature. But it looks nice anyway.





Any chance that you could add the Sony WEGA mask from their flat CRT TV series? Looks pretty nice too. (as always: a second click to enlarge). Shader file attached.

[gimbal]

These screenshots are hitting me right below the nostalgia belt. It hurts so good.