CRT Simulation in a GPU Shader, Looks Better Than BFI

Posted Dec 24, 2024 by in: Area 51: Display Research Display Motion Blur OLED Retro

Who Is this for? CRT Enthusiasts, software & hardware developers, emulator authors, all of who wish to reduce display motion blur of 60 years of legacy 60fps 60Hz content with softer flicker than BFI. 

UPDATE 2024/12/24: It just got added to Retroarch emulator on github quickly, the same day we released this! The next public release of RetroArch will include this CRT beam simulator mode as a setting.

New Open Source Algorithm of Simulating CRT Raster-Scanning

People who have seen a CRT tube in motion, know how shockingly clear motion they are. Blur Busters is born of display motion blur reduction, and so we’ve been fans of all kinds of motion blur reduction techniques.

Between myself and Timothy Lottes (ex-NVIDIA ex-AMD), we have come up with a breakthrough algorithm for simulating a CRT tube, now released on shadertoy and github, with the following features:

  • Major motion blur reduction on 240Hz+ displays.
  • Soft phosphor fade & rolling scan, less eyestrain at same Hz than BFI or strobe mode.
  • Variable per-pixel MPRT (Timothy Lotte’s brightness redistribution algorithm).
  • Great for reducing display motion blur of 60 years of legacy 60fps 60Hz content.
  • Works on LCDs and OLEDs
  • Realtime (for retro & emulator uses) and slo-mo modes (educational)
  • Brightness adjustment (less motion blur at lower gain values, by trading off brightness)
  • Seamless; no banding* (when ABL algorithm in display isn’t interfering)

Real-Time Versions

Before running these animations, they may not look good on all displays; more Hz is better. These real time versions requires a performant GPU. You may see ugly erratic flicker if your GPU is too slow. Your display motion blur reduction will be limited by by the native:simulated Hz ratio. More Hz the merrier.

Flicker sensitivity note: Do not click these below links if you are sensitive to flicker.

Slow Motion Versions

For higher Hz displays (large native:simulated Hz ratio), the raster can be configured with a quicker simulated phosphor fade for lower MPRTs:

EDIT: Shadertoy is having problems with autoplaying this despite compiling fast (<0.1s on our gamer target); and it doesn’t continue playing when you click. Try accessing it more directly here: 

For lower Hz displays (small native:simulated Hz ratio), the beam will require a very tall height, to give sufficient coverage. The real-time version flickers less than BFI, due to the rolling-scan and phosphor fade.

Pre-Requisites for Good CRT Simulation Better Than BFI

  • Most discrete GPUs work (Radeon, GeForce, Arc).
    Some fast mobile GPUs work (iPhone 120Hz with “Prefer Page Updates Near 60fps” turned off).
  • Recommended: 240 Hz OLED to look better than BFI
    Minimum: 120 Hz LCD (non-FALD, due to local dimming lag)
    Fantastic: 360-480 Hz OLED
    Note: Newer low-lag MinILED will work (the new Lenovo gaming laptop at CES 2025 worked).
  • Display ideally configured to SDR mode (LCD or OLED).
    This is because the current formulas used in the shader (gamma2linear and linear2gamma) is expecting the ability to calculate a photon budget for brightness-spreading over multiple refresh cycles for brightest pixels. This lowers persistence of average brightness pixels, and brightens the CRT simulation significantly. If you do any HDR boosting, you may need to readjust the GAIN_VS_BLUR constant and the GAMMA constant until banding disappears.

For Software Implementation

We look forward to seeing software and hardware developers implement this algorithm as optional motion blur reduction that is superior to plain black frame insertion.

  • Software such as emulators (e.g. Retroarch);
  • Video processor devices (e.g. Retrotink 4K, whom I helped with the BFI addition)
  • Game engines that adds an optional low motion blur setting (e.g. fast scrollers)
  • Display firmwares to add an optional CRT emulation mode

Remember, that all native refresh cycles must be reprocessed, regardless of if the content frame rate is lower than the simulated CRT refresh rate or the native display refresh rate. That means for a 240Hz display, you need to reprocess 240 refresh cycles per second even for 30fps content on a simulated 60Hz CRT.

Temporal Simulation can be added to Spatial Simulation

This temporal simulation (CRT electron beam) can be combined with your spatial simulation (CRT mask filters). Combine this with OLED blacks and colors, and it create a fantastically visually-accurate simulation of CRT refreshing. Blur Busters works in the (display+temporal) domain, as seen in our Display Research, Science & Engineering Portal.

Frequently Asked Questions

Q: How do I run this app?
A: This isn’t an application yet; it’s only an engine, an algorithm. Software developers need to implement this algorithm into their emulator. We hope to see Retroarch-type and Retrotink-type implementations in the future.

Q: How is it better than BFI or a strobe backlight?
A: 60Hz BFI and strobing flickers a lot. CRT simulation is much gentler for 60fps content, because of phosphor fade & rolling scan. Some light is emitted somewhere else on the screen all the time. Right tool for Right Job.

Q: Can I add it to ReShade / SpecialK / LSS / Etc?
A: Possibly in the future (developers are trying now!), with a major restriction: All refresh cycles must be reprocessed independent of game frame rate. You need to guarantee processing of all refresh cycles (perfect permanent framerate=Hz shader processing) independently of game frame rate fluctuations. This may require a Windows IDD (e.g. iddSampleDriver or virtual-desktop-rs) or a specially modified version of wehem’s DesktopBFI fork. You may also desire to learn about Windows Compositing Swapchain, for easier Hz-granularity shaders.

Q: It looks like crap! Why?
A: You need a bright display, try a 240Hz+ OLED. Also some local dimming LCDs have a backlight lag that sometimes interferes with quality.

Q: It looks amazing! How?
A: Algorithmic magic. It took two smart brains to combine. Mark Rejhon’s CRT beam simulator was combined with Timothy Lotte’s variable-MPRT BFI algorithm that compresses MPRT for average brightness pixels, and lengthens MPRT for brightest pixels.

Q: I see very noticeable banding in the CRT simulator.
A: Make sure you’re running in SDR using an Adobe sRGB mode, with a common gamma curve (2.2 or 2.4). In addition, there may be a little black clipping and white clipping. Try calibrating your display with the TestUFO Black Levels (PLUGE) and TestUFO White Levels (Clipping) tests. Also, if you have a 6-bit TN panel, try running an odd-numbered native:simulated Hz ratio to avoid strange interactions with panel FRC or inversion algorithms. In winter 2025, there will be an improved version of the CRT shader that will have an optional black level lifter / white level dropper.

Q: I have banding I cannot fix! I have erratic random flicker!
Please see Known Solutions List, and follow the instructions. There are several tweaks that makes the banding and flicker disappear. Some surprising culprits include multimonitor mode (Multi-Hz interference), background RGB animator software (CPU spikes that cause CRT simulator to flicker), bad picture adjustments (e.g. Control Panel contrast/brightness adjustments can make banding appear/disappear), amongst other issues.

Q: Can I program CRT mask filters into this?
A: Yes, software developers can add spatial CRT filters as a processing pass after this temporal CRT beam simulation. Try to sequence your processing in the same sequence a CRT would do (electron beam simulator before phosphor mask step). I recommend doing the CRT beam simulation at the original resolution before scaling, in this workfow:

[Original frame] -> [Picture adjustments] -> [CRT beam simulation] -> [Scaling & CRT filter masks]

Q: Where is the source code?
A: It’s at github.com/blurbusters/crt-beam-simulator

Q: I need help implementing this!
A: If you need advisory services implementing this into your product, contact me at services.blurbusters.com.

 

About Mark Rejhon

Also known as Chief Blur Buster. Founder of Blur Busters. Inventor of TestUFO. Read more about him on the About Mark page.

32 Comments For “CRT Simulation in a GPU Shader, Looks Better Than BFI”

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Sort by:   newest | oldest | most liked
1mongus
Member
1mongus

This is exciting, where’s the best place to keep updated on this coming in reshade or a program like desktopbfi?

Like0Vote Down 
1 month 12 days ago
jimmy8x
Member
jimmy8x

this is so cool and so exciting! I can see it working even on my 120hz oled tv.

knowing this will be around in the future for excellent retro game experiences on modern hardware is thrilling. I’d much rather buy myself a nice OLED gaming display instead of giving some CRT hoarder hundreds of dollars for a burned out 30 year old trinitron.

Like1Vote Down 
1 month 13 days ago
vanti
Member
vanti

The thing I like about this is that you can retain maximum brightness by letting the virtual phosphor glow for longer. Trading motion clarity for brightness. Our eyes have similar retention of very bright lights anyway so for glints of reflected sunlight or very bright lights it doesn’t matter if there is a bit of motion blur. In fact I would like to see an example of some HDR content with very bright highlights using this🙂

Like0Vote Down 
1 month 15 days ago
Mark Rejhon
Author
Mark Rejhon

Yes, this tradeoff is fully adjustable using the GAIN_VS_BLUR setting, which is exposed via “Brightness vs Blur” setting in RetroArch.

That said, for best results, use as much native:simulated Hz ratio that you can afford to throw at it! It works at a ratio of 2:1 (aka 120Hz for 60fps) but more Hz the merrier to blur-bust 60fps 60Hz or 72fps 72Hz (any simulated Hz is supported)!

Like2Vote Down 
1 month 13 days ago
azhighwayz
Member
azhighwayz

Fantastic work! Will be interesting to see if this will now enable older video game consoles or arcade cabinets to utilize the old CRT light guns on LCD and OLED panels. Most light guns utilized a photo sensor and the vertical and horizontal retrace of the electron beams to sense the position of the gun when the trigger was pulled. Do you think this could be implemented if it doesn’t currently work already?

Like0Vote Down 
1 month 15 days ago
Mark Rejhon
Author
Mark Rejhon

Light guns requires zero latency, and digital displays are not zero latency. However, digital OLED replacements for CRT arcade cabinets can now be done using the Retroarch engine, since it now has the CRT rolling scan engine. You can use laminated wood to mask-off a 4:3 hole of a 16:9 OLED in some of the older machines that have large bezels around the CRT tubes.

240Hz OLED’s now make fantastic CRT-replacement screens, even if you have to crop a 4:3 wooden window for a 16:9 screen behind it. Portrait and landscape games would benefit with current 27″ 1440p 240Hz and 32″ 4K 240Hz OLEDs with both CRT beam simulation and CRT phosphor mask simulation running concurrently, as long as the best practices are followed to eliminate banding (adjustments).

However, light gun will require other mitigations, like modifications that gets around the zero-latency problem. Some projects have successfully done this with the Nintendo Zapper, but that required a direct connection between an Arduino and a composite output jack. Doing this in an emulator will be a wee bit more difficult, and require careful thought. Definitely not impossible but will require a “virtual GPIO” system + interface to a clone gun that works with digital displays (Whether by camera appraoches like Wiimote, or via hidden corner IR beacons for triangulation). The Virtual GPIO system would be a direct code hook into the emulator’s own lightgun signalling, which would flash in sync with the nits of the emulator pixel associated with the (x,y) coordinates of the clone physical gun; simulating a light gun in an emulator successfuly.

This modified approach would definitely work in a Nintendo emulator like RetroArch (contact me if you want help implementing Zapper style support into a cycle accurate NES emulator — you’re just precision emapping the nits of an emulator pixel (retrieved by the x,y coordinates of a physical modern digital-display compatible gun) to one of the controller port wires, for a simulated zero-lag photodiode trigger). This type of remap approach will work fine on a cycle-accurate emulator like a minor-modified version of bsnes, despite time dilation effects of surge/slowdown computer executions and the digital display latency. Jury is out whether this algorithm would be RunAhead compatible.

Would definitely require minor modifications to any good cycle accurate NES emulator (bsnes-Higan is a great one) to simulate the controller port wire correctly cycle-exact, to a simulated photodiode trigger that is simply the nit brightness value of a tiny region of the emulator framebuffer from the x,y coords of a modern digital display gun accessory.

Be noted it’s probably a circle of average brightness rather than a single emulator framebuffer pixel, but you can shortcut it by using the average nits of a rectangular region of the emulator framebuffer, for performance’s sake. Another alternative is simply rendering a low-resolution version of the framebuffer, as you’re going to need this almost every clock cycle (1 million average-nit computations per second), to correctly emulate a Nintendo Zapper out of a modern light gun.

The workflow is pretty convolted but if software developer needs a collab to modify bsnes to make it Nintendo Zapper compatible via emulated NES controller-phort emulated photodiode trigger wire at maybe a roughly ~500KHz – ~1MHz sample rate (you don’t need full NTSC, Duck Hunt flashed large rectangles). That’s why you can get by with only about 1/5th to 1/10th the sample rate of 3.58MHz NTSC.

Implementation of this type of Nintendo Zapper support would be 100% display lag independant and 100% modern-gun-controller lag independent, since you only need “zero lag” between the emulator framebuffer and the internal emulated photodiode wire on the internal emulated controller port of a cycle-accurate NES emulator. The modern laggy gun controllers’ responsibility is thusly reduced to relaying x,y coordinates for the emulated photodiode signal only; conveniently decoupling lag requirements and definitely making Zapper emulation possible.

Some emulators already sort of does this (e.g. NES.emu running on touchscreens, using finger taps to emulate zappers), same principle is essentially already being done “internally”.

Like1Vote Down 
1 month 13 days ago
Chubbz
Member
Chubbz

I know nothing about how this works but I have some questions. Is this primarily for rendering lower frame rates on higher frame rate monitors? Can it be used in any game?

I was curious if it would be beneficial to tactical FPS games like CS2 or if it is possible to use it with CS2 in the first place.

Side note: I wonder how CS 1.6 would work!

Like0Vote Down 
1 month 16 days ago
wpDiscuz

Recent Content

Blur Buster Forums

Blur Busters Forums

TestUFO Motion Tests

TestUFO Motion Tests