This is a well known effect. LCD cells must be driven with alternating positive and negative values (of the same magnitude) to maintain an average neutral value, otherwise you get some kind of offset buildup that will result in flicker.

If you alternate every other image with a different color value, you upset that balance.

It will slowly rectify itself for most displays.

I wish Shadertoy had an easier way to let me change framerate. If you click 480Hz on a 120Hz display, it flickers at an awful 15Hz instead of 60Hz; so you don't want to simulate a 15Hz CRT -- not comfortable.

Retroarch now has this CRT simulator and it will automatically keep it at 60Hz by its default settings; so it's more foolproof in Retroarch than in Shadertoy.

After HD, adding pixels/framerate/depth/brightness is like a clean house: it's hard to articulate the value proposition up front in a way that does it justice and it's easy to talk yourself out of going to the trouble, but once you have it you realize just how good it is.

Even 480Hz looks great for office use; very ergonomic -- browser scrolling has 87.5% less motion blur than a 60Hz OLED and about 90-92% less motion blur than a 60Hz DELL LCD.

I'm not sure but I think this could be used instead of BFI in any game.

Silly question, but what does slang mean, as in I've been using retro arch for years and have always wondered what slang means in relation to the shaders.

Thank you! It's in Retroarch now

I appreciate the crazy high dpi very much. Because the text is super sharp, it helps with the focus. I am 48 and my eyes are not perfect. I look at screens for many hours every day and if the text is not sharp enough, I lose focus and everything becomes blurry. But super sharp and bright screens mean the eye can have a feedback loop for the correct focus distance.

You need an 120hz display to run the 120hz demo. I am surprised to see that the movement is clearer with the shader. You can follow the objects and they are more stable/more clear.

We're getting closer, but 480Hz is still too slow for a convincing simulation of phosphor decay. 1000Hz will probably be enough.

Ah, the non-developer option setting to enable 120Hz on later Pixels is under "Settings"->"Display & touch"->"Smooth display". With that enabled, Chrome will use 120Hz if power and temperature settings permit it to.

For things like a pan -- you have to apply it globally because your eye movements will smear the static pixels and motionblur them across your retinas.

However, the CRT simulator actually is variable-MPRT; it does compress the light emissions as quickly as possible as early as possible. Dim greys, for example are brightened and pushed in an earlier refresh cycle of the series that simulates a CRT refresh cycle.

So dimmer pixels get lower MPRT and brighter pixels get higher MPRT. Any unemitted brightness gets cascaded to subsequent refresh cycle until fully emitted to meet Talbot Plateau Theorem.

You need a large native:simulated Hz ratio. I recommend at least 4. Which means 240Hz to simulate a 60Hz better.

Projectors tend to have brightness issues, that would make it even dimmer

- Turn off HDR, use Adobe sRGB both at OS level, display icc level, and display menu level. The math in the CRT simulator is optimized for the gamma2linear/linear2gamma math, needed for Talbot-Plateau Theorem, and it was easier on a well-known old gamma curve.

- Adjust your black levels and white levels so there's no clipping

- I noticed 6bit TN panels tend to have problems, try IPS or OLED

- Lower GAIN_VS_BLUR to 0.5 at 120Hz, or 0.25 at 240Hz, if discoloration is bothersome.

- There are some optimizations coming in January 2025 as band-aid workaround for display limitations (especially low-Hz TN LCDs), even 240Hz is sometimes too low.

OLED at 240Hz looks better than LCD at 360Hz with the CRT simulator for example, so if you're buying a monitor to have 75%-90% motion blur reduction in your 60fps retro content, you will want to have a high-Hz OLED, see the motion blur physics at TestUFO Variable-Persistence Black Frame Insertion demo (in TestUFO 2.1) to understand how higher Hz can reduce motion blur of low frame rates more than lower Hz; it's just the laws of physics caused by ergonomic flickerless sample-and-hold displays, and BYOA (Bring Your Own Algorithm) approaches. I can emulate plasma subfields on a 600Hz OLED, and I can emulate DLP subfields on a 1440Hz OLED; but CRT is the gold standard; still it needs a large native:simulated Hz ratio to look realistic. It's very adjustable.

I don't know if the market is big enough to offset the cost of setting up production again.

it's gonna be pretty difficult to compete with used prices and make a profit with the likely volumes. The tubes aren't exactly something that scales down to low volumes either.

Yes. Retroarch now has the CRT simulator built in.

I recommend 240Hz OLED in arcade cabinets to emulate 60Hz CRT, do not skimp on Hz. More Hz is better for CRT simulators, due to a very important temporal principle, you need a large native:simulated Hz ratio.

FWIW I have the ASUS ROG Swift PG32UCDM 31.5" 4K UHD (3840 x 2160) 240Hz Gaming Monitor - a $1.3k monitor and also don't see anything different in the demo. Maybe I'm looking at the wrong thing. https://www.shadertoy.com/view/XfKfWd

240Hz is more recommended, 120Hz does not give much benefit, especially on small screens. If your screen is bigger you may notice, but it starts to become noticeable if done on OLED instead of LCD, or if you increase refresh rate by 4-8x above CRT simulation target.

No. Light gun games rely on the fact that a CRT display will draw the picture on the screen pretty much at the same time it's generated by the console's video chip. Modern digital displays introduce all kinds of delays due to processing and buffering they do. Usually several frames worth. This shader can't do anything to fix that.

You wouldn't be able to get horizontal position.

ios limits browser framerate by default, you can try going to settings > apps > safari > advanced > feature flags > disable "prefer page rendering near 60hz" and see if that has any effect. you can test by going to testufo and seeing if it gets the right framerate.

You need a large native:simulated Hz ratio in order to accurate a CRT accurately. It's laws of physics, sadly. I need to update a pixel multiple times per videogame frame, just to accurately simulate a CRT.

120Hz = up to 50% motion blur reduction for 60fps

240Hz = up to 75% motion blur reduction for 60fps

480Hz = up to 87.5% motion blur reduction for 60fps

CRT simulation is bottlenecked by limited genuine native non-faked Hz, which is why accurate CRT simulation is so difficult.

You need more Hz to reduce display motion blur.

- 120Hz = can reduce motion blur by up to 50%

- 240Hz = can reduce motion blur by up to 75%

- 480Hz = can reduce motion blur by up to 87.5%

There's a new article on Blur Busters that's showing 120Hz-vs-480Hz OLED is more human visible than 60Hz-vs-120Hz, and easier to see than 720p-vs-1080p, and also why pixel response (GtG) needs to be 0 instead of 1ms, since that's like a camera shutter slowly opening & closing, but MPRT is equivalent to the shutter fullopen time. The science & physics is fascinating, including links to TestUFO animations that teaches about display motion blur and framerate physics.

Motion blur of flicker = pulsewidth

Motion blur of flickerless = frametime

So you need tons of framerate or short pulsewidth BFI/CRT/etc.

It's to reduce sample-and-hold blur. Modern displays typically produce a static image that stays visible for the whole frame time, which means the image formed on your retina is blurred when you move your eyes. CRTs instead produce a brief impulse of light that exponentially decays, so you get a sharp image on your retina. Blurbusters has a good explanation:

https://blurbusters.com/faq/oled-motion-blur/

Author here.

You need to keep the GPU free to work on the game; doing CRT simulation at 60fps at 480Hz requires brand 8 new frames per videogame frame, and it's doing a bunch of math operations per subpixel per refresh cycle. If you run it at full resolution 2560x1440x480x3, that's a lot of processing.

Especially since it also uses a variable-MPRT algorithm that cascades brightest pixels to subsequent refresh cycles;

That's why it's coming to RetroArch and best to process the low-resolution framebuffers first, before scaling and sending through CRT filters/simulated curvatures/etc.

Most retro games are just 320x240.

Alas, software, and operating systems full of stuff sometimes does it...

This CRT simulator almost requires a dedicated GPU (AMD, NVIDIA, Radeon) and nothing running in the background, since it's a software-based simulation of a CRT tube. It is probable that an Intel integrated GPU from 2017 won't work, and neither will a cheap $200 Android phone do it smoothly.

It is doing almost 100 math computations per subpixel per refresh cycle, in a multi-gigaflop supercomputer called a GPU, so if you're running at 2560x1440x120x3, that's still blows past a lot of dedicated GPU abilities, as it's needing to do it on every native Hz, regardless of the low simulated Hz.

Make sure you don't have any software running in background (not even browser tabs, no system tray apps, exit your RGB animation apps), and run in Performance Mode (not Balanced Mode or Low Battery Mode).

It's frame drop-free on my Razer laptop in a clean Windows install, but it starts stuttering with an old Windows install. Not much I can do about operating system preventing realtime stuff.

Set your graphics card to a hard limit at 24fps, and only use pre-rendered video. I think you'll find it stops dropping frames. Just like your analog TV, you won't even have to reduce the resolution!

If you don't understand why comparing a modern graphics pipeline, sitting ontop a general purpose CPU running a time sharing kernel, might be different enough to break the comparison to an old TV, I don't know how to help you...

It already sort of does that, through a clever variable-MPRT algorithm.

> A couple of commenters damaged their displays

No they didn't.

> a photosensitive person may have damaged themselves

What person that might be seriously affected is going to look at the image at the top of the article and decide they want to try the full speed demo without extreme care? Plus there's a warning on the links.