CRT Simulation in a GPU Shader, Looks Better Than Black Frame Insertion

Just a mini-warning&#x2F;FYI: running the 120hz test on my 60hz LCD IPad (Air 4) has caused that part of the screen with the crt effect to flicker even after leaving the demo. I don’t know what might cause this but it’s weird and worth a warning to anyone interested in trying this out.<p>(The flickering is more obvious when the control centre is opened, I managed to take a video of it but it’s only partially clear in it. It’s been about 5 minutes so far and I <i>think</i> the effect has reduced. I’m also quite perceptive to flickers so others might not notice it.)

Looks way more flickery than a real CRT at 120 Hz on an OLED phone. Maybe 240 Hz would be better.<p>Edit: I misunderstood and was running the 240 Hz version at 120 Hz. The 120 Hz version doesn&#x27;t flicker noticeably. It does seem to reduce motion blur for 60 Hz content with a brightness penalty. It doesn&#x27;t immediately make me feel like I&#x27;m looking at a CRT. Maybe it would if I had a 480 Hz monitor. There is a slight rolling banding artifact on my phone, maybe an artifact introduced by the display controller as described in the article.

I assume some people will approach this as stupidly as I did.<p>I wanted to see something and clicked on the 120Hz version not knowing what my laptop display actually is and while I am not photosensitive this was quite uncomfortable. Thinking I don&#x27;t understand what that is supposed to be I clicked on the 480Hz to see if that is better&#x2F;different and that was even worse. As a hail mary I clicked on the 240Hz and well that really made sense and was actually comfortable to look at.<p>So if you are like me and didn&#x27;t really read through the text, this will only work for you if you select the Hz that matches your display ( which kinda is the whole point of why they are doing that ). If it looks bad you clicked the wrong link

I&#x27;m the author of this shader, here&#x27;s some tips:<p>- Throw as much native:emulated Hz ratio as you can.<p>- 120Hz = up to 50% blur reduction<p>- 240Hz = up to 75% blur reduction<p>- 480Hz = up to 87.5% blur reduction<p>- Calibrate your black levels and white levels (e.g. via TestUFO PLUGE test and White Level tests), since you need all of the levels for the simulated phosphor fades.<p>- Use SDR mode, not HDR, the math in the shader is designed to the Adobe sRGB curve. I wish I had more direct access to the complex HDR curves and ABL to auto-compensate for Talbot Plateau Theorem.<p>- Use odd number native:emulated Hz ratio on LCD to make it immune to image retention + slightly better behaviors with LCD 6-bit FRC<p>- Adjust Gain-vs-Blur and gamma, if there&#x27;s problems. Using low Gain-vs-Blur will reduce color ghosting. Use 0.5 for 120Hz, and if you&#x27;re getting too many artifacts, try testing numbers as low as 0.25 for 240Hz to see if color ghosting problems disappear. (A fix will be coming)<p>- Artifacts reduce dramatically at 480Hz versus 240Hz vs 120Hz, more Hz really helps CRT simulation. More Hz the merrier, for BYOA (Bring Your Own Algorithm approaches)<p>There will be an improved version of my shader on Github, involving:<p>- Global refresh mode (like a phosphorescent BFI)<p>- Color balancing modes<p>- Black level lifter (to fix any thin dark bands caused by violations to Talbot-Plateau Theorem due to certain displays&#x27; crappy handling of below-2% greyscales, etc)<p>Keep an eye out for it in January 2025, just star the Github repo or wait for Retroarch (etc) to implement the improved version of my shader (after I&#x27;m finished deadline work for a client at CES 2025)

I adapted this to a retroarch slang shader really quick, and I&#x27;m seeing some pretty persistent banding on 120hz to 60hz. It shows up obviously when scrolling the same direction as the fake beam scanout. If you take the shadertoy version and edit the scanout direction to left-to-right and fullscreen it, you can see it there, too. The perpendicular scanout and scrolling the demo uses by default disguises it pretty well.<p>I guess you probably need a higher ratio for this to work really well.

Awesome. I find it so ironic that the main thing tempting me to buy to a high resolution high framerate monitor is the desire to better emulate a low resolution low frame rate CRT.

This looks REALLY good on a 240hz monitor. Much better than BFI (which I don&#x27;t use because it&#x27;s pretty bad on my monitor)

Ignoring the heavy flicker, it seems to reduce motion blur even with the 120 Hz demo running on a standard 60 Hz display. Especially visible on the windows. It doesn&#x27;t seem like it should work, but it does?<p>But I find it hard to say that what it&#x27;s <i>supposed</i> to look like. Motion blur is considered fine and correct in the &quot;film look&quot;. Our eyes do crazy processing and can&#x27;t really be emulated by a display technology without going to crazy lengths with high DPI, high dynamic range, high refresh rate (to emulate certain effects, not because we can properly see 90+ or so Hz) and probably eye tracking.<p>I think I like the slight (static) pixel blur of CRTs more than the motion-related behavior. The crazy DPI numbers of state of the art screens are seemingly not so much about showing detail than about hiding pixels. Calculating all of these pixels is, in a way, a waste of work. I&#x27;m talking about ~100 DPI, i.e. making a decent resolution look nicer, not about making low res crap look blurred instead of pixelated.

I’m a complete layperson on graphics and such, so please someone help me here: does this mean we’re now able to simulate old video game visuals on crt? That would be the best Christmas gift ever

The 120Hz shadertoy works on the Pixel 8 (and hopefully other 120Hz Android devices) if you go to Developer Options and enable &quot;Force peak refresh rate&quot;<p>I wonder if there&#x27;s a way to ask Android Chrome to ask for 120Hz.

I&#x27;m still interested in a &quot;selective MPRT&quot; GPU or monitor setting, that only does black frame insertion on changed parts of an image and a &quot;safety margin&quot; around them. This should reduce flicker on non-moving portions of an image&#x2F;still screen while keeping moving portions sharper. But this probably isn&#x27;t useful for office tasks, perhaps video, and high-framerate gaming (but only games running at a lower FPS than the screen can (partially?) redraw).

I&#x27;ve thought for a while that we need to simulate how phosphorus face in and out, at the very least.

This is better than BFI, although 120Hz demo on my screen looks like it&#x27;s just alternating two or three parts of the image. Maybe there is a way to use fake interlacing to make it look convincing.<p>240Hz demo in 144Hz mode looks flickery but much more realistic.

I have an AOC Q27G3XMN and while I do get reduced motion blur from this, I also experience very bad color banding&#x2F;shifting. Messing with some of the values in the script config makes it slightly better, and changing the overdrive setting on the monitor seems to affect it as well, but there is still pretty strong banding no matter what strength it&#x27;s on. I tested on my phone (Pixel 8) and it works very well there without any banding or color weirdness, so I guess it&#x27;s just something about this particular monitor that doesn&#x27;t work well with this method.

Tried on my simple 60Hz PC screen and also on my phone with OLED screen and sadly, it&#x27;s just a flickering image. Will try later this week on my friends&#x27; retrogaming setup. Looks promising

I&#x27;m wondering if it would rather make more sense to emulate a CRT with a video projector and some shutter device (maybe a fan?) in front. Has anyone tried that yet?

Nice! Does-this&#x2F;can-this handle interlacing?<p><a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Interlaced_video" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Interlaced_video</a><p>(Half vertical resolution, offset a bit every other frame)

Can anyone explain why this requires a relatively high-end GPU? Looking at the slo-mo GIFs, it looks like `brightness *= SomeLUT[(y + t) % sizeOfTheLUT]` for each colour channel would do the trick.<p>What makes it so complicated?

Just start making CRTs again. There&#x27;s clearly consumer demand

It&#x27;s cute but on my AOC (at 120hz) the discoloration is substantial. Also any inconsistency in frame time will break the illusion

This probably goes without saying but...<p>If you have photosensitive migraine or epilepsy, stay the hell away from those demos.

I tried the 120Hz demo but can&#x27;t really tell there&#x27;s any effect. Does it look cooler with 240Hz?

Can I use this to play Duck Hunt?

Could this be used to simulate CRT displays in video game cabinets?

I just see a flickering image. What am I missing on iPhone?

&gt; Q: It looks like crap! Why?<p>&gt; A: You need a bright display, try a 240Hz+ OLED. Also some local dimming LCDs have a backlight lag that sometimes interferes with quality.<p>Come on now. If you can simulate a CRT then surely you can make it look nice on a conventional monitor?

Could someone explain the point to me? I read the post and still don’t quite understand. I remember CRTs looked smoother when pixels were still noticeable in (o)led displays. Is it to effectively lower the frame rate?

To me this highlights that none of my hardware (pc, phone laptop) can actually render anything at native screen resolution and not occasionally drop frames.<p>Can we please design software to be frame-drop-free? Ie. if it drops a frame, even once, send a bug report to the developer to fix it, and if he cannot, refund me for the hardware?<p>My analogue TV from 1956 does not drop frames, I can assure you.

Now add different phosphor decays on the black parts for each subpixel!

Please flag. A couple of commenters damaged their displays, and a photosensitive person may have damaged themselves. The risks outweigh the benefits of having it up for discussion.