Phosphor persistence now available to be prepended to any presets

RetroArch Additions Shaders
#1

Phosphor-persistence (called Afterglow in other shaders) is a crt effect available in just some crt shaders: crt-geom-deluxe, crt-guest-advanced, glow-trails, for example.

I’ve detached the code from crt-geom-deluxe, which I think is simple enough and made a preset called ‘phosphor-persistence’ inside crt folder (already uploaded into the oficial repo). This preset can be prepended to any other crt-shader to add the effect. It’s a bit different compared to the glow-trails implementation.

One odd thing about phosphor persistence is that you can’t take screenshots of the effect, because it’s a temporal effect. Games where you can easily spot the effect are: Rtype-3 (title screen, snes), Thunder Force 3 (genesis), vector games.

It’s true that you can only ‘see’ the effect in a few games, though I think it manifests on most of them. At first, I thought it wasn’t real until I tested R-Type 3 on my own real CRT TV and can confirm it’s real and the crt-geom-deluxe params is set to get the exact tail size of the asteroids/comets passing through this game title scene.

This subject was always discussed in side comments of other threads, so I thought it deserved its own topic.

7 Likes
#2

The first few seconds of Super Mario Bros 3 title crawl with the black background is what I tested with when making the phosphor-trails shader.

2 Likes
#3

Yes, it’s another classic example of this effect.

2 Likes
#4

I think that there is some numerical instability that causes the phosphor trails to persist too long. For example, if 0.00392156862745098 (which is 1 / 255) decays down to 0.002352941176470588, it will be rounded back up to 1 when stored in an integer buffer and come back out as 0.00392156862745098 again in the next pass. So it will never really decay.

Obviously this shader is more complex than a simple exponential decay, so it doesn’t happen all of the time, but often I see trails on a black background persisting on my screen. It might be necessary to use floating point buffers or have some extra behavior that mitigates this effect.

EDIT: Actually, I could be wrong. The default values might just decay the phosphors much more slowly than I expected. I will see if I can find a better test.

1 Like
#5

If you find it, I’ll update asap. I myself didn’t see these instabilities, though. The code is the same present in crt-geom-deluxe.

#6

Actually, it just persists for a very long time. It takes over 6 seconds to decay from 1/255 to 0. In games where the screen never really stays dark for that long it just looks like it doesn’t decay. I made a quick video for testing that displays a big white square for a second before transitioning to an all black screen.

I think what’s complicating this is that my monitor is calibrated for sRGB (with the linear section) and not pure 2.2 gamma. Most of the time this doesn’t make much difference, but in very dark areas it’s much brighter. That makes the slow decay more obvious.

It’s true that you can only ‘see’ the effect in a few games, though I think it manifests on most of them. At first, I thought it wasn’t real until I tested R-Type 3 on my own real CRT TV and can confirm it’s real and the crt-geom-deluxe params is set to get the exact tail size of the asteroids/comets passing through this game title scene.

I had a similar realization. I think I was playing Super Mario All-Stars and noticed it in the Nintendo logo scrolling down the screen at the start. Now I want to look into how people have implemented it. Admittedly, I don’t understand the crt-geom method yet. It’s something clever to try to simulate a power law decay.

1 Like
#7

I believe the 6-second thing is intentional. cgwg’s mentioned in the past that he’s read some whitepapers on individual phosphor decay rates and, while blue and green usually decay in less than one second, red phosphors take much longer; up to 6 seconds.

2 Likes