Shaders for various emulators

[guest.r]

Originally Posted by Retro-Nerd

The Afterglow effect looks quite nice. But in motion/scrolling on a pure black background you can see ghost images/smearing.

Is this adjustable tweaking the Afterglow settings (which ones) without degrading the effect too much?

Sadly, the afterglow effect doesn't know about the objects involved, it applies on black background triggered wheather by a spaceship or a wall etc.

You can tweak some variables (first 7 parameters in the shader are for afterglow) like persistence or strength (per color channel).

It's more a hack since original timings are helpless with discrete frame times of modern 60Hz solutions.

[Retro-Nerd]

Ah, ok. Will tinker will some of the values then.

[Dr.Venom]

Originally Posted by guest.r

I also introduced a new parameter called "Increased bright scanline beam" which can control the "growth" of bright lines/pixels. Before isolated bright lines/pixels swelled a lot and it's lowerd a bit by defaults. Comparing with other crt shaders some endorse "swelling", some keep it in bounds. So i rather made this optional. Can also influence beam fall-off.

Thanks for this addition, very helpful to "normalize" the growth of the individual pixels. It makes it possible to get even closer to real triniton. Please keep this in the shader .

I added a parameter to control the fall-off grade. On 0.0 it will work stronger, on 1.0 as before. But in general, it's hard to influence this since the whole image get's altered and most scanlines become thinner.

It can be controlled by the "scanline dark" parameter also, since dark lines get thinner and the fall-off is steeper.

I've been experimenting with this one, but am coming to the same conclusion. I doesn't seem to help in getting closer to real trinitron. So in answer to your question about this parameter, probably best to remove it?

What i wanted to say, yeah some changes with "alternate scanlines". A very nice new version is now under 1.0, the replaced one is now 3.0. It's hard to find an equation which doesn't produce uneven scanlines / banding with 1080p and non-integer scaling and therefore i'm very pleased with the new no. 1.0. Old 1.0 (now 3.0) failed here a bit, so it's a good question to keep it or not, because it slows the shader.

Brilliant, the new 1.0 scanlines is very very nice. I think this will become my new default . Because of that I would certainly be OK if you remove the old 1.0 (now 3.0) and only keep alternative scanlines 1.0 (new) and 2.0.

I really think everything it hitting the sweetspots now, great scanlines, great mask (5!), smooth and crisp at the same time, super realistic glow, nice afterglow.

Thanks again for all the effort in perfecting it and keeping exploring ways to make it even better

Seeing that you're doing some very nice ports to dosbox and winuae, is there a possibility to also do a port for regular MAME?

Originally Posted by Retro-Nerd

Ah, ok. Will tinker will some of the values then.

@Retro-Nerd: With regards to the afterglow, I'm getting the most realistic results by having the values somewhere around the following:

Afterglow Red: 0.03
Persistence Red: 0.07
Afterglow Green: 0.07
Persistence Green: 0.07
Afterglow Blue: 0.00
Persistence Blue: 0.00

All depends a bit on the brightness of your monitor and other settings I guess, but for me this comes very close to the real thing (it's a very subtle effect!)

[Retro-Nerd]

I don't think that the Afterglow smearing in motion is fixable. Would a 100/120Hz monitor help here a bit? Well, i disable it for now. No big deal.

Yeah, Alternate Scanlines 1 works now pretty perfect with custom size output in non-integer scaling. I had problems before with the C64 core using a PNG overlay (TV frame). Some C64 games uses the border for graphics too and it never fitted the frame properly with integer scaling for these games. With non-integer scaling the scanlines looked disorted. Now its all fine.

[guest.r]

Thanks for liking the shader...i think it's almost finished now (rev.2), not much more to tinker.

@Dr. Venom

Seeing that you're doing some very nice ports to dosbox and winuae, is there a possibility to also do a port for regular MAME?

I don't use MAME, so i'm not much of an use here. Nevertheless i managed to scramble up a GLSL version of it. Horizontal version looks OK, TATE one could use a 4k display i guess...

Edit: minor tweak.

[Retro-Nerd]

Ah, great. Looks really nice in Arcade64. Any chance we can get the mask style 6 too?

[guest.r]

Yeah, np. I've updated the shaders above.

[Retro-Nerd]

Thanks. Arcade64 already had a full Lottes CRT GLSL shader, but yours is better.

[Dr.Venom]

Originally Posted by guest.r

I don't use MAME, so i'm not much of an use here. Nevertheless i managed to scramble up a GLSL version of it. Horizontal version looks OK, TATE one could use a 4k display i guess...

Edit: minor tweak.

Bloody brilliant man, looks beautiful (out of the box!). Thanks a lot, this really is the first shader for MAME that does everything right .

I noticed that there's a possibility for stacking glsl shaders (the glsl_shader_mame0, 1, 2, .. , 9), does that possibly include an opportunity for porting the full version also? I noticed a forum comment that said it was comparable to retroarch capability, but I'm not sure if that holds up.

Also, I noticed all kinds of "fx" files in the hlsl folder, could this possibly mean that a "hack" could be done to have the Trinitron version as HLSL / D3D version?

The big advantage compared to glsl would be that it would work with GroovyMAME, which has various options to lower input latency compared to regular mame (most notably the framedelay feature). But this input latency reduction in GroovyMAME is only enabled when the video driver is set to D3D. By no means necessary, very very happy with the glsl version, just thought I'd ask in case there a possibility

With regards to the extended shader, I was thinking whether it could make sense to give the masks some more regular names.

I.e. they are all shadow masks, but these can be distuingished as dotmask, slotmask, and aperture grill (trinitron). So instead of only having the numbers for the masks, we could for example name them
"0 - Generic"
"5 - Aperture Grill (Fine), and
"6 - Aperture Grill (coarse)"

I don't know what the other ones are meant to mimic (dotmask or slotmask), but maybe it would be nice to have this bit of extra information in there.

Anyway thanks again for all the effort spent. Super happy with the MAME stuff also, years of trying stuff and not finding anything satisfactory are over

[guest.r]

Thanks for the nice words...

I noticed that there's a possibility for stacking glsl shaders (the glsl_shader_mame0, 1, 2, .. , 9), does that possibly include an opportunity for porting the full version also? I noticed a forum comment that said it was comparable to retroarch capability, but I'm not sure if that holds up.

If i'm honest that doesn't help much without a meta shader environment (i.e. retroarch presets). The full version also uses some Retroarch only features which are essential (frame history, float framebuffer, fbo chains which allow to access any previous pass, scaling options:source, outscale...). the MAME glsl setup outscales the first shader to fullscreen and stacks at this resolution. Maybe cool for some color effects like tonemapping...

Also, I noticed all kinds of "fx" files in the hlsl folder, could this possibly mean that a "hack" could be done to have the Trinitron version as HLSL / D3D version?

That's a tricky one. Tried to hack the scanline shader and it can only calculate scanlines, but there are missing parameters for mask calculation. What a irony...
I wouldn't bother too much with it, since it's really a hack of the integrated system.

With regards to the extended shader, I was thinking whether it could make sense to give the masks some more regular names.

I changed the parameter description to:

"CRT Mask: 0:CGWG, 1-4:Lottes, 5-6:'Trinitron'"

It's not plausible to use 7 parameters with full descriptions since it would confuse the users i guess.

Last but not least, some minor improvements on the mame glsl shaders. The masks should look bit better.

[Retro-Nerd]

Could you please add the "warmer colors" profile to your Retroarch CRT shader too, maybe Mame too?

[guest.r]

Originally Posted by Retro-Nerd

Could you please add the "warmer colors" profile to your Retroarch CRT shader too, maybe Mame too?

Yeah, why not. I had to change the crt shaders as well to support multiple passes. Luckily, they work as single pass shaders too. I included some instructions, to avoid confusion.

With the Retroarch version there is already a shader pass dedicated to color temperature / white point. You must edit the "D65 to D50" parameter and use negative values to get warmer colors. -40 should do...

[Dr.Venom]

Originally Posted by guest.r

That's a tricky one. Tried to hack the scanline shader and it can only calculate scanlines, but there are missing parameters for mask calculation. What a irony...
I wouldn't bother too much with it, since it's really a hack of the integrated system.

Thanks for looking into it, was worth a try...

I changed the parameter description to:

"CRT Mask: 0:CGWG, 1-4:Lottes, 5-6:'Trinitron'"

It's not plausible to use 7 parameters with full descriptions since it would confuse the users i guess.

Cool. Will you be attaching the final version here (including the files that now are only found on Retroarch site)? Would be helpful for people coming new into this thread. And myself I would also like to "archive" the final version without the redundant code, to know that I have the most optimized version..

Last but not least, some minor improvements on the mame glsl shaders. The masks should look bit better.

Looks even better now, thanks


Last but not least I learned some interesting things about Raster Bloom, so back to an old topic shortly. We earlier talked about the high voltage regulation for the electron beam. This plays a role, but the core cause of visible raster bloom is the result of heating up and expansion of the shadow mask.

Interestingly aperture grill is different from dotmask and slotmask in the sense that aperture grill (trinitron) has little to no blooming because the design only leads to expansion in the vertical direction, which apparently is close to negligible.

The alloy that was used in earlier TV sets and monitors for slotmask and dotmask shadow masks are sensitive to expansion when heating up, so the industry sought the best weldable material with the littlest expansion coefficient, for which they settled upon Invar. So more modern TVs had their shadow masks made from Invar, which has a very low coefficient of expansion in a certain heating range.

Here are two links:
https://www.nickel-alloys.net/invar_...ron_alloy.html
https://en.wikipedia.org/wiki/Invar

Current Uses of Nickel Iron Alloy Invar

Cathode Ray Tubes

Between the range -100 to +200°C Invar's CTE is very low. This feature is very useful for many specific applications in high tech industry. Cathode ray tubes for television and display screens are increasingly required to provide greater user comfort, with higher contrast, improved brightness and sharper definition. This progress has been made possible by the use of shadow masks made from Invar strip, with its low coefficient of thermal expansion allowing precise dimensioning of components even with changing temperature.

So maybe for some future "tinkering" the raster bloom could possibly be more correctly modelled as a function of:
1. Amount of electrons hitting the shadow mask - which in itself is a function of the R, G, B dots being hit. An approximation could be made.
2. The coefficient of expansion (CTE) of the Nickel Iron Alloy Invar. We should be able to calculate / look up the thermal expansion as a function of both time and size (of the mask)?

Because of above characteristics Raster Bloom can apparently also occur locally, i.e. when you have a very bright circle or area occuring on a part of the screen, locally that part heats up slightly more, giving rise to local Raster Bloom effects.

Yes totally over the top, but maybe it finds an inroad somehow when 4K HDR lands, and we get simulation of dotmask and slotmask to the comparable (higher) level as the current trinitron

[Retro-Nerd]

Originally Posted by guest.r

Yeah, why not. I had to change the crt shaders as well to support multiple passes. Luckily, they work as single pass shaders too. I included some instructions, to avoid confusion.

With the Retroarch version there is already a shader pass dedicated to color temperature / white point. You must edit the "D65 to D50" parameter and use negative values to get warmer colors. -40 should do...

Works great. Thanks again. Also in Retrorarch.

[nobody]

Crt-trinitron is derivative of Crt-guest? Just curious.

[guest.r]

Originally Posted by nobody

Crt-trinitron is derivative of Crt-guest? Just curious.

Crt shaders in general consist of three major features: horizontal filter, scanlines and crt masks.

Crt-trinitron has the same horizontal filter as crt-guest (WinUAE version) because it's lightweight, adjustable and efficient, but different scanlines and a special crt mask. Ofc. there are some other candies like brightboost and saturation which are included in most of the crt shaders around.

If we turn the tables it's a much lighter variant of a crt-guest-dr-venom setup, mostly because of being single pass and some special requirements to run fullspeed with beamracing in WinUAE.

I could add a heavier/slower horizontal filter to it, but it would probably not matter is a significant way.

[Dr.Venom]

Originally Posted by guest.r

I could add a heavier/slower horizontal filter to it, but it would probably not matter is a significant way.

Could you maybe explain a little bit what the horizontal filter mostly does?

From your comment I assume there's more to it than it "only" blending pixels horizontally?

[guest.r]

Originally Posted by Dr.Venom

Could you maybe explain a little bit what the horizontal filter mostly does?

From your comment I assume there's more to it than it "only" blending pixels horizontally?

It's a small science, but they only blend pixels horizontally.

OK some fast crt shaders don't use filtering, but use either point/linear sampling (some with coordinate modifications), but these are missing linear gamma interpolation, which is essential for a good crt look.

[guest.r]

@Dr. Venom:

Cool. Will you be attaching the final version here (including the files that now are only found on Retroarch site)? Would be helpful for people coming new into this thread. And myself I would also like to "archive" the final version without the redundant code, to know that I have the most optimized version..

Np., i tinkered some values, tried some stuff (like smart filtering), but it runs at decent speed now, so i'll give this a prio.

The raster bloom main shader which calculates the average value had also a minor change, it's going one more level with mip-maps now. But it shouldn't affect the blooming level. Before as many as 50 texture lookups were made on lowest original resolutions, going to 200+ with a basic hires setup. General performance increase is about 15% or like 50% with a 640x480 game. With a 4k display a crt shader is perfectly usable with these game resolutions. So i think mip level 6 is a sweetspot.

So maybe for some future "tinkering" the raster bloom could possibly be more correctly modelled as a function of:
1. Amount of electrons hitting the shadow mask - which in itself is a function of the R, G, B dots being hit. An approximation could be made.
2. The coefficient of expansion (CTE) of the Nickel Iron Alloy Invar. We should be able to calculate / look up the thermal expansion as a function of both time and size (of the mask)?

In fact, now 1. is in use.
2. is not doable unfortunatelly, since we have a "goldfish memory" problem. We can't store the info from point 1. since shader processing is preety straight, linear and limited. There is no way currently (GLSL) that some data we generate from the current frame is passed over to the next one.

The only usable info on this is "framecount", but i guess it would be an annoying ferature for most users to see their image grow a bit every couple of minutes and nothing more.

Personally i think that raster bloom has a cool function now, bringing some dynamic on display.

Because of above characteristics Raster Bloom can apparently also occur locally, i.e. when you have a very bright circle or area occuring on a part of the screen, locally that part heats up slightly more, giving rise to local Raster Bloom effects.

This is a bit doable, since the info we get is segmented by mip mapping. But it would look very funny.
Any detailed processing would slow the shader beyond usage unfortunatelly.
An there is the "goldfish memory" problem again with GLSL and rectangle segmented processing in general.

Anyway, thanks for thinking a bit more about it- Here is the latest version.

[Retro-Nerd]

Something i noticed about "Raster Bloom %" is that is just zooms the image size and with "R Boom Overscan Mode" = 0 it zooms out (smaller image). Is this the intended behavior?