Enhance MAME HLSL To Do Sub-Refresh Processing On High-Hz Displays (CRT emulation, Reduces Blur, Lowers Lag, De-Stuttering) #6762
Description
Here's the short TL;DR summary:
TL;DR: Enhance existing MAME HLSL to include sub-refresh behaviors, including simulating CRT phosphor fade in sub-refresh increments + optional rolling-scan BFI in sub-refresh increments. All achieved via software, with the only hardware requirement being a high-Hz display, even 120Hz or 240Hz. Made possible simply by a display having a higher Hz than the original emulated Hz
Bonus optional side effect 1: Reduce input lag. Since it's a rolling scan emulation via subdividing emulator Hz over multiple destination Hz, there is a simple cross-platform beam-race opportunity to reduce MAME lag even closer to 1:1 symmetry to original machine. For example, 240Hz would use 4 hardware refresh cycles to emulate a 60Hz emulator refresh cycle in quarters at a time. No raster knowledge of the destination display is needed, you're simply using the finer granularity of the higher output Hz.
Bonus optional side effect 2: Real-time standards conversion. Smooth 50fps on 60Hz displays! The same algorithm I propose, accidentally de-stutters frame rate conversions too, so can be used for standards conversion (e.g. ANIMATION: Software algorithm that makes 50fps look smooth without stutters on a 60hz non-VRR display). So this algorithm is accidentally useful on today's 60Hz displays too. Output Hz actually can also be lower than emulator Hz as the algorithm can also blend refresh cycles together as part of the flexible Hz-agnostic phosphor fade algorithm capable of overlapping refresh cycles, similiar to what I successfully did in the link above. Allowing smooth 60fps on 50Hz displays too!
Long Version Below
MAME HLSL revolutionized the spatial look of a CRT tube.
However, it doesn't yet look temporally like a CRT tube (zero blur, etc).
The vision is that with increasingly-higher monitor refresh rates, thanks to the arrival of 240Hz IPS (ASUS) and 360Hz IPS (DELL AW2521H) this summer, now it is time to start talking about emulating a CRT gun at the sub-refresh-cycle level.
I posted at GroovyMAME about the concept of "Temporal HLSL"
http://forum.arcadecontrols.com/index.php/topic,162926.0.html
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, ala a "Temporal HLSL" algorithm of a rolling-bar software BFI.
This may be easier to imagine:
Much like playing back a 1000fps high-speed video of a CRT (with full dynamic range, not over exposed), back to a real-time 1000Hz sample-and-hold display. The rolling bar. Early tests show it ends up looking like the original CRT temporally with low persistence (1ms persistence). Now that experimential ultra-Hz displays are in the lab. 360Hz is the beginnings of the "wow" factor in software-based rolling-bar BFI algorithms. Finer-granularity Hz is even better, but 360Hz begins to start the "wow" in temporal look-n-feel.
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. The need for screens to emulate real life (real life doesn't flicker, which requires blurless sample-and-hold. And blurless sample-and-hold requires insane Hz), thanks to VR and Holodecks, but a side effect of the refresh rate race is an improved ability to emulate a CRT electron gun at subrefresh timescales (zero-blur rolling scan), which is a boon for emulator originality.
Refresh rates are now getting high enough (360Hz) to make Temporal HLSL practical. At 360Hz, one can use a 1/6th screen-height "rolling phosphor bar emulation" (with a gamma-corrected alpha-blended phosphor trail), generating only 2.7ms of motion blur (1/360sec persistence). Bar height and bar fadetrails (as the bar scrolls downwards) can be programmable with existing options or new options in the configuration file. One would have have alphablend-overlap betwen adjacent refresh cycles so you don't have artifacts, but done correctly, it looks seamless once we're in the refresh rate stratospheres.
In addition, I also posted a permanent universal solution for software-BFI burn-in artifacts. in that thread. It is brighter, more colorful, no chessboard artifact, no banding or color depth loss, no burn in.
I'd like to see long-term discussion on incubating Temporal HLSL in what I envision is an approximately 5-year time window. I don't expect this to be added to MAME In near term but I would like to see the community do longterm-planing for sub-refresh processing.
CRTs will not last forever -- the factories have stopped. We will need to emulate CRTs at sub-refresh timescales. It has to happen within 10 years, when arcade tubes become valuable antiques.
Thankfully the refresh rate race has made that feasible for originality, the dream of Year 2030s bringing 1000Hz OLEDs and MicroLEDs replicating the motion blur of a CRT rolling scan. But we can get prepared now, with this year's 240Hz IPS and 360Hz IPS panels.
P.S. I am open to moving this discussion to a different forum, or keeping this as an incubator github thread. If this is the wrong place, open discussion on how to begin a "Temporal HLSL" collaborative initiative somewhere else is welcome. Let's either (A) continue this issue as incubate this concept, or (B) figure out appropriate venue before closing this issue. As MAME HLSL is incredibly well known for its studious attention to spatial detail, ultra-detailed configuration files, so it is the Gold Standard of CRT filters. And the discussion to eventually make it capable of subrefresh processing is desirable to duplicate the original temporal behaviours of a CRT (including zero CRT motion blur). Which ones of you are responsible for HLSL?