CRT electron beam simulator opensourced under MIT license

[mdrejhon]

I am submitting the code base -- under MIT license of my electron beam simulator
https://github.com/blurbusters/crt-beam-simulator
There's now a newly submitted HLSL port, in addition to GLSL.

Possibly, someone in the MAME HLSL team may wish to port this as an option. RetroArch surprisingly ported it in under a day, so it might be easy enough to port if there's already a subframe shader system. A couple other emulators are now working on implementing subframe shader support and will be implementing this soon.

Super slo mo video of 60fps at 240Hz, 4 screenshots merged into animated GIF:

• Fast GtG needed & significant native:simulated Hz ratio
• No native:simulated ratio restriction, as long as at least 2.0f (yes, a float)
• Best at ~3.0f and above avoid nyquist issues of temporal scaling on non-integer divisors
• Any Hz (you can do 53Hz CRT on a 240Hz OLED). Surprisingly smooth due to temporal scaling (temporal version of bilinear interpolation)
• Automatic unbounded scaling
  • 120Hz reduces 60fps 60Hz motion blur up to 50%
  • 240Hz reduces 60fps 60Hz motion blur up to 75%
  • 480Hz reduces 60fps 60Hz motion blur up to 87.5%
• Variable MPRT. Brighter than BFI. The bright pixels take more refresh cycles than dim pixels. Defacto simulates a real CRT.

This is real source code ready for any pull requests for mamedev/mame#6762 (spiked so I'm posting this here instead). I'm not currently doing specific emulators but in general, as long as an emulator supports subrefresh shaders, it should be relatively easy to port.

Pre-requisite is the implementation of subframe HLSL processing support (at least even if integer-divisors are enforced for simplicity), needed for CRT simulator shader and future BFI/plasma/etc simulator shaders. For example, one 60Hz emulator framebuffer spawns 4 different framebuffers for a 240Hz native display -- then it's easy to port this shader.

240Hz OLEDs discovered to look fantastic in arcade cabinets

With the big boost in brightness from the variable MPRT algorithm, it now keeps up with typical CRT brightnesses. Some of us noticed that 240Hz OLEDs apparently make fantastic arcade cabinet replacement panels (use wood to mask off 16:9 to 4:3), if there's enough bezel. The tubes are getting harder and harder to find and my passion brought this into existence, to preserve CRTs long after CRT's stop working.

I now recommend 240Hz OLEDs if masked version fits inside the arcade cabinet. Some fell below 500 during boxing week, so the prices are starting to overlap getting-difficult-to-find arcade CRT tubes including freight shipping costs. It looks much better than native 4:3 LCDs, despite having physically mask a 16:9 into a 4:3

Shader Sequence Best Practices

Generally speaking, it's best to sequence shaders in the same orthographical order as a real CRT tube (picture processing) -> (electron beam simulation) -> (spatial filters). It works bad on TN/VA due to GtG or 6bit violating Talbot Plateau Law mathematics (banding...) but wonderfully on most IPS and OLED.

Note: If your specific MAME HLSL spatial filter has a phosphor fade simulator, turn it off or port your phosphor fade processing to this layer instead. It needs to stay a Talbot Plateau Law compliant approach as it's essentially tracking energy on a per pixel basis across refresh cycles, to keep average per-pixel brightness the same without banding effects. For some adjusted phosphor fadefeel, you can adjust GAIN_VS_BLUR for phosphor fade processing.

Troubleshooting banding/flicker: blurbusters/crt-beam-simulator#4

There's generally been rave reviews by OLED users (e.g. accolades such as this one and hundreds others). Some intermittent feedback by TN/VA LCD panel users due to bitdepth and/or pixel response limitations creating banding effects. Noticed newer FastIPS panels generally looks fine too (for the most part). Adust GAMMA and GAIN_VS_BLUR for optimal balance. YMMV depending on your display, but in general, displays are gradually becoming more and more compatible with CRT beam simulation as time passes.

Obviously probably a discussion needs to be done to figure out how to include this in MAME HLSL engine, even if it takes some time (e.g. the right volunteer to glue it into MAME). So let's make this the thread.