[Feature Request] (BFIv3) Emulate a CRT Electron Beam Via Rolling-Scan BFI

New Methods of Emulating CRT Via Sheer Hz

Also reduces motion blur without needing a strobe backlight like LightBoost or ULMB

I'm the founder of Blur Busters and creator of TestUFO. Today, we now have 240Hz 1ms IPS panels, and DELL is releasing a 360Hz IPS monitor this summer. This is an amazing opportunity for emulation.

Glossary
BFI = Black Frame Insertion, used to reduce motion blur on LCDs to mimic a CRT
BFIv1 = Classic 60fps at 120Hz BFI, already implemented in RetroArch
BFIv2 = Improvements to BFI for higher Hz, See GitHub #10754
BFIv3 = Rolling-bar BFI, emulating CRT electron beam temporally, FOCUS OF THIS GITHUB ITEM

Optional but recommended related items: Add retro_set_raster_poll #10758 if you need to do beamracing simultaneously with a CRT electron beam emulator. And add precision frame-presenter thread #11390 if you need to improve precision of framebuffer presenting-to-screen.

BFIv2 versus BFIv3, and Potential $500-$700 Source Code Bounty (reuse of existing bounty from 2018)

While BFIv2 is easier to implement. BFIv3 is a long-term Holy Grail feature for the refresh rate race to retina refresh rates -- using sheer brute Hz to emulate a CRT electron beamtemporally via a rolling-bar emulation.

If you beam-race this feature, then this potentially qualifies for the already-posted BountySource bounty (read for more info).

Why Emulate a CRT Electron Beam On a High-Hz Displays?

We need to better mimic CRTs in software. Thankfully, brute refresh rates makes this possible. The arrival of 240Hz IPS (ASUS) and 360Hz IPS (DELL AW2521H) this summer, now it is time to start talking about emulating a CRT beam at the sub-refresh-cycle level.

The long-term futurist vision is that a 1000Hz display will be able to emulate a CRT electron gun, by displaying a "rolling bar" with a phosphor fade trail. Instead, we aim to do that in software. 240Hz and 360Hz is now high enough refresh rates to begin implementing this.

ASUS has confirmed a long-term road map to 1000Hz displays (those unaware, can also read more; Blur Busters Law: The Amazing Journey To Future 1000Hz Displays, with scientific citations included), and with the push of 120Hz becoming more mainstream (iPhone/Galaxy), high-Hz is expected to be inexpensive inclusions in future panels in ever-increasing numbers with refresh rates doubling approximately 5-10 years. While crazy numbers, the impetus of ultra-Hz is currently esports and VR, with the need for screens to emulate real life (real life doesn't flicker, and eliminating motion blur without hardware strobe, requires insanely high refresh rates).

This item may, depending on parameters, be able to qualify for the $500-$700 BountySource bounty posted for #6984, because the techniques in this github item may be easier to implement on a cross-platform basis, while allowing simpler modifications to make this github item functionally identical to #6984! (This doesn't necessarily have to happen, but one can hit two birds with one stone).

Inspired by a forum thread on ArcadeControls as well as MAME Temporal HLSL, I'm crossposting the request, with some modifications.

Rolling-Bar Black Frame Insertion Concept

It can even achieve sub-refresh latencies using ordinary VSYNC ON. One wouldn't have to care about how a display refreshes. For example, at 240Hz, you'd display 1/4th of an emulator refresh cycle (rasterplotted in real time), in 4 separate output frames.

For a 60Hz emulator module onto a 240Hz monitor

• Emulate 1/240sec, output 1/4-height frame at top
• Emulate 1/240sec, output 1/4-height frame just above center
• Emulate 1/240sec, output 1/4-height frame just below center
• Emulate 1/240sec, output 1/4-height frame at bottom

The rest of the frame would be black (except for any required alphablend overlaps to eliminate seams/artifacts)

Make top/bottom edges of bars fuzzy to reduce/eliminate tearing artifacts (avoid emulating the look of VSYNC OFF tearing). I have confirmed that you have to overlap the bars between output refresh cycles. Use alpha-blend-to-black slightly beyond the 1/4-height frames for the 240Hz situation example. This will prevent tearing artifacts. Make sure to gamma-correct the alphablend overlaps. Remember that RGB(128,128,128) is not exactly half the photons of RGB(255,255,255). Use a configurable gamma correction number in HLSL config file.

It can also acomplish beam raced latency without black frames too

The rolling scan BFI could in theory be configurable to full persistence. It would achieve beam raced latencies to the output refresh cycle granularity.

For a 60Hz emulator module onto a 240Hz monitor

• Emulate 1/240sec, output frame with top 1/4 new refresh, bottom 3/4 old refresh
• Emulate 1/240sec, output frame with top 1/2 new refresh, bottom 1/2 old refresh
• Emulate 1/240sec, output frame with top 3/4 new refresh, bottom 1/4 old refresh
• Emulate 1/240sec, output frame with whole screen new refresh

Make sure to alphablend the seams (blur the refresh overlap line) to prevent tearing artifacts, otherwise it looks like "a VSYNC OFF emulation in VSYNC ON". The alphablend fixes the tearing.

This allows beam-raced latencies via sheer brute Hz. So, this module could be configurable to have full persistence or rolling low persistence (rolling black period).

This will scale very well to the future, in the refresh rate race to retina refresh rates too. A future 1000Hz display would emulate original machine latency to an error margin of 1ms, duplicating sub-refresh original-machine latencies, regardless of display technology (scan direction, display refresh pattern, etc). Most high-Hz gaming displays have a sub-refresh processing delay, so the higher Hz you go, the more it converges into original-machine latency.

Very little crossplatform dependencies, the only thing needed is VSYNC ON and the ability to do framerate=Hz.

Emulator Hz and destination Hz doesn't need to be divisible.

Situation Example of 60Hz CRT emulation onto a 200Hz LCD ... This formula is very Hz-agnostic.

Emulator Refresh Cycle 1:
....Real Refresh 1: full 60/200th height bar (30% screen height), at 0%-30% vertical position
....Real Refresh 2: full 60/200th height bar (30% screen height), at 30%-60% vertical position
....Real Refresh 3: fuill 60/200th height bar (30% screen height), at 60%-90% vertical position
....Real Refresh 4: 1/3 of 60/200th height bar (10% screen height), at 90%-100% vertical position

Emulator Refresh Cycle 2:
....Real Refresh 5: 2/3 of 60/200th height bar (20% screen height), at 0%-20% vertical position
....Real Refresh 6: full 60/200th height bar (30% screen height), at 20%-50% vertical position
....Real Refresh 7: full 60/200th height bar (30% screen height), at 50%-80% vertical position
....Real Refresh 8: 2/3 of of 60/200th height bar (20% screen height), at 80%-100% vertical position

Emulator Refresh Cycle 3:
....Real Refresh 9: 1/3 of 60/200th height bar (10% screen height), at 0%-10% vertical position
....Real Refresh 10: full 60/200th height bar (30% screen height), at 10%-40% vertical position
....Real Refresh 11: full 60/200th height bar (30% screen height), at 40%-70% vertical position
....Real Refresh 12: full 60/200th height bar (30% screen height), at 70%-100% vertical position

This is just a conceptual example of temporal compensation. Algorithmically, this can be used for black frame insertion (rolling bar, some bars with image data, other bars black, with alphablended bleed overlap) or for "beam racing via brute Hz" (all bars with image data, new emu Hz overwriting old emu Hz, alphablend/blur the seams) or both simultaneously (rolling BFI + beam racing simultaneously). You could adjust the alphablend factor up/down.

Theoretically can also acomplish stutterless standards conversion (50Hz onto 60Hz)

Using a SIMILAR formula above, combined with a huge overlap alphablend adjustment (i.e. 50% or 75% screen height of overlap, perhaps). Basically a scanout-enhanced version of a common alphablend standards-conversion algorithm. It would thus, eliminate stutters. The taller the alphablend overlap, the less stutter of standards-conversion. The bar-overlap should be a configurable parameter in the configuration file.

This would conceptually be a more advanced version of the software-based variable refresh animation: www.testufo.com/vrr ....where I'm able to play any framerate stutterlessly onto any refreshrate, with a very simple alphablend algorithm not too dissimilar from the common 50/60 standards conversion alphablend algorithm.

So we're just "abusing" the alphablend overlap feature of this theoretical "Temporal HLSL" as the method of destutter in much the same stutter-eliminating way.

Apparently, @TomHarte already tested something similar (some kind of scanout-alphablend algorithm) in his experiments with CLK.

Temporal HLSL concept is a universal CRT emulator with amazing crossplatform flexibility

It scale up and down universally

• Can temporally emulate a CRT electron beam at the granularity of destnation Hz
• Map any Hz to any Hz without stutter
• Benefits for stutterles Hz-conversion (50Hz onto 60Hz)
• Benefits for high Hz (i.e. 60Hz onto 360Hz)
• Potentially beam raceable (Temporal HLSL = a virtualized software display)
• Flickerless option (full persistence option)
• Flicker option (simulate CRT phosphor, including decay, subject to output-Hz granularity)

OPTIONAL: Theoretically compatible with hardware beamraced VSYNC

See #6984 for Beam Raced VSYNC

• Temporal HLSL could emulate a higher-Hz display internally independently of output Hz
• A flywheel sync algorithm can optionally kick in whenever emuHz = outputHz, allowing a separate module to frameslice-beamrace this virtualized internal display to a low-Hz output display.

Thus, it would produce latencies identical to the Lagless VSYNC / Beamraced VSYNC approaches, like the one already implemented in WinUAE https://github.com/tonioni/WinUAE/issues/133

Certainly, actual-hardware beam racing would be 100% optional (since it requires minor platform-dependant and display-scanout-direction knowledge)

I only simply add this section to say that Temporal HLSL is 100% compatible with hardware-based beam racing simply by internally virtualizing a higher-Hz display internally, e.g. doing 600 frames per second of Temporal HLSL into RAM, and then doing 600-frameslice beamracing onto a real 60Hz display, subject to jitter margin to hide problems caused by CRT-curvature algorithms as well as computer performance jitter.

Software-based beam racing: Output Hz massively above Emulator Hz. The art of emulating a CRT electron beam via brute Hz.
Hardware-based beam racing: Output Hz same as Emulator Hz. Beam raced synchronization of rasterplotting emulator's raster ahead of real display's raster. Using beam raced VSYNC OFF frameslices, that would work off a Temporal HLSL framebuffer too. (An approach successfully already implemented in a few emulators)

Basically the Temporal HLSL concept is compatible with both software-based beam racing and hardware-based beam racing. Then it would produce identical latencies to #6984

The issue describes a broad rolling-scan BFI and beam-racing concept but names no source files, tests, or entry points. Start by locating RetroArch's video presentation and shader paths, then narrow the proposal to an agreed first implementation. Done requires a defined scope, implementation plan, and validation approach for the target refresh-rate behavior.