mdrejhon commented 4 years ago

Black frame insertion looks massively better on 240Hz and 360Hz monitors (especially IPS) than 120Hz monitors. No burn in, better color, brighter, no chessboard-patterns, no color depth loss, etc.

RetroArch has already partially implemented it: https://github.com/libretro/RetroArch/issues/10754

This is an easy change, IMHO. Crosspost:

New Methods of Emulating CRT Via Sheer Hz

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 BFIv2 = Improvements to BFI for higher Hz BFIv3 = Rolling-bar BFI, emulating CRT electron gun temporally

WinUAE already supports 60Hz BFI for 120Hz

60Hz Black Frame Insertion (BFI) improves massively at higher refresh rates for multiple reasons. Strobed and non-strobed. WinUAE already supports 60 Hz software BFI for 120Hz displays.

To understand black frame insertion, see animation demo: www.testufo.com/blackframes

This works great, and is already discussed in this libretro thread

Newer monitors already actually improved BFI in existing WinUAE. For example, 120Hz strobed on 240Hz panels look better than 120Hz strobed on 144Hz panels. And 240Hz IPS just came out too (better colors). 240Hz 1ms IPS strobed monitors look far better than old LightBoost panels, such as the Blur Busters Approved ViewSonic XG270 gaming monitor 240Hz 1ms IPS panel, which looks great with existing 120Hz PureXP+ on existing WinUAE BFI

Discovery That Higher Hz Improves Software BFI (240Hz, 360Hz)

We discovered that higher refresh rates improve software BFI even further for many reasons such as:

Even less motion blur
Adjustable-brightness BFI
Adjustable-blur BFI
Eliminate image retention (burn in)
Eliminate chessboard pattern artifacts
Eliminate banding/contouring (color depth loss)
For Manufactures, Higher Hz also improves lower-Hz strobe (reduced crosstalk)
For Developers, Higher Hz also produces more opportunities to emulate CRT zero-blur
For User, Higher Hz also reduces emulator lag, and mimic a CRT better

Animation Demonstration:

If you have a 60Hz monitor, animations will be very limited in explaining BFI, but you can view this Simple 60Hz Demo of Three Different BFI Motion Blurs. This will run at only 20 frames per second, but will adequately demonstrate the variable-blur BFI concept via custom blackframe sequences.
If you have a 240Hz monitor in sample-and-hold mode, view this upgraded TestUFO Variable-Blur Variable-Brightness BlackFrames Comparison. You'll immediately see the pros/cons. You can still view this on a 120Hz monitor to see this in a kind of a slow-motion, at least to gain a better understanding.
If you have a 120Hz monitor in LightBoost mode with a chessboard-pattern problem, view this upgraded TestUFO Inversion-Artifact-Proof BlackFrames Animation, you'll see the last UFO no longer have a chessboard pattern artifact. But it only runs at 40 frames per second. Chessboard patterning is often an issue on TN panels due to voltage inversion. Fixing this requires a 240Hz monitor configured to 180Hz with strobe enabled (e.g. BenQ XL2546 monitor, ViewSonic XG270 monitor). This, incidentially is also burnin-proof too.
Fun Education: There is now a TestUFO emulation of CRT 30fps at 60Hz side effect. This is just an educational exercise on how software BFI can still emulate the side effects of a CRT (half frame rate behavior). Mind you, this animation looks more correct on a 120Hz monitor, because it requires a 4-refresh sequence, but it's still passable education at any refresh rate.

Eliminates Image Retention

Odd-divisible refresh rates (180Hz and 300Hz) are completely image-retention-proof, since it doesn't interfere with LCD voltage inversion electronics. BFI is completely safe on all 180Hz-capable and 300Hz-capable monitors. Most 240Hz gaming monitors are capable of doing a 180Hz refresh rate.

FEATURE REQUEST:

Support Adjustable Software BFI for Higher Hz

WinUAE should support the following Black Frame Insertion (BFI) sequences:

BFI sequence on 120Hz for 60Hz emulation: ON, OFF BFI sequence on 180Hz for 60Hz emulation: ON, OFF, OFF BFI sequence on 240Hz for 60Hz emulation: ON, OFF, OFF, OFF BFI sequence on 300Hz for 60Hz emulation: ON, OFF, OFF, OFF, OFF BFI sequence on 360Hz for 60Hz emulation: ON, OFF, OFF, OFF, OFF, OFF

Best Case Display Motion Blur Reduction by BFI

The easiest way to do so is provide a comma-separated black-frame insertion sequence in a configuration file, to allow customizability. Default strings can be done for common scenarios, but would let advanced users customize BFI. Relative to the original blur of a 60Hz LCD, higher Hz produces more software-BFI-blur-reduction (non-strobed LCD use-case, though software BFI also helps hardware strobing too for these specific numbers, in lower strobe lag + better quality strobing).

120Hz BFI sequence (50% less motion blur): 1 , 0 180Hz BFI sequence (66% less motion blur): 1 , 0 , 0 240Hz BFI sequence (75% less motion blur): 1 , 0 , 0 , 0 300Hz BFI sequence (80% less motion blur): 1 , 0 , 0 , 0, 0 360Hz BFI sequence (83% less motion blur): 1 , 0 , 0 , 0 , 0 , 0

Adjustable Motion Blur (Tradeoff Between Flicker + Brightness + Clarity)

Custom sequences can allow you to adjust motion blur, brightness, and flicker tradeoff. Just like TestUFO Variable-Blur BFI Demo. Try this link on a high-Hz LCD with hardware strobing distabled! If you have 240Hz, try configuring 4 or 5 UFOs instead, to see more variable-blur flexibility. Adjustability is a continuum between hardware Hz to emulator Hz. Minimum persistence-based display motion blur is persistence of max Hz (1/360sec visibility = 2.8ms blur). Maximum display motion blur is emulator Hz (1/60sec visibility = 16.7ms blur). Thus higher Hz, the more BFI motion blur adjustability.

180Hz bright BFI sequence (33% less motion blur): 1 , 1 , 0 240Hz bright BFI sequence (25% less motion blur): 1 , 1 , 1 , 0 360Hz bright BFI sequence (66% less motion blur): 1 , 1 , 0 , 0 , 0 , 0 360Hz bright BFI sequence (33% less motion blur): 1 , 1 , 1 , 1, 0 , 0

Basic CRT Phosphor Decay Emulation

In fact, alpha-blended BFI is also desirable, so this could be a percentage setting or floating point setting, to approximate phosphor fade. This makes flickerfeel more approximate a CRT tube (as far as refresh granularity permits). And feels much less harsh than 60Hz squarewave for many.

240Hz alpha-blended BFI slow-rise slow-decay sequence: 0.5 , 1 , 0.5 , 0 360Hz alpha-blended BFI slow-rise slow-decay sequence: 0.5 , 1 , 0.5 , 0 , 0 , 0 360Hz alpha-blended BFI fast-rise, slow-decay sequence: 1 , 0.5 , 0.25 , 0 , 0 , 0 360Hz alpha-blended BFI fast-rise, superslow-decay sequence: 1 , 0.75 , 0.5 , 0.25 , 0.1 , 0

Alternative methods of configuration could be discussed instead.

Hopefully this is a very easy change for a WinUAE for the refresh rate race to retina refresh rates. For now, this can be just a simple configuration file string, to help users incubate this. It should be easy to write instruction guides, to help get more users playing with BFI.

BFI Percentage Terminology (in case it wasn't clear) 1 = Fully visible frame 0 = Fully black frame 0.5 = A darkened frame that is 50% brightness

Tips

Comma sequences too long for current actual-hardware refresh rate can simply be trunctated for lower Hz. So "1,0,0,0,0,0" can become catchall for all refresh rates
Comma sequences too short for current actual-hardware refresh rate can simply pad missing values as 0
First number should be non-blank for lowest lag. For convenience, config file reader can automatically numbershift to lag-optimize user-defined setting, e.g. turn "0, 1, 0.5, 0" into "1, 0.5, 0, 0". It is visually identical but lower lag.
The numbershifting technique can also be used as the anti-retention technique (can be enabled by default for hardware Hz evenly divisible by emulator Hz, such as 120,240,360 instead of 180,300, for 60Hz emulators).
Future Rolling BFIv3 (github #10757 ...) could actually theoretically use the same BFIv2 strings, simply by using 6 different numbershifted versions of the same strings for 6 slices for the same 360Hz display (360/60 = 6). Or 4 different numbershifted versions of the same strings for 4 slices of the same 240Hz display (240/60 = 4). For some developers, this can theoretically make BFIv3 conceptually simpler to implement (for all phosphor fade speeds), albiet alphablended overlaps will still be needed to eliminate seams/tearing artifacts. You'd simply add a command line argument "rolling = on/off". Although this may not be the most ideal coding path, explaining it this way, may be more conceptually simple for a developer how to visualize how to turn global BFIv2 into a rolling BFIv3 later on in the future, as a stopgap...

Once this feature is implemented, I'd be happy to write an article about this to improve emulator BFI awareness among high-Hz monitor users

Hopefully this is a very easy change for WinUAE for the refresh rate race to retina refresh rates. For now, this can be just a simple configuration file string, to help users incubate this. It should be easy to write instruction guides, to help get more users playing with BFI.

mdrejhon commented 4 years ago

Long Term

Not part of this item, but advanced discussion to a BFI sequel for high-Hz displays:

I know @tonioni has incorporated several of my suggestions in the past...

Being Blur Busters, I see many prototype displays. And I have seen a new concept algorithm to emulate a CRT tube. Did you know that playback of a 1000fps high-speed video of a CRT tube -- in real time onto a true 1000Hz display -- allows a 1000Hz display to perceptually emulate the original CRT? It's pretty fascinating.

The world has have spatially-completed CRT filter emulation. But holy grail is the temporal emulation of CRT, like this.

The refresh rate race to retina refresh rates (combined with HDR brightness to help brighten the beam emulation spot) -- will make CRT beam emulation algorithms practical for 240Hz+, 360Hz+ and future 1000Hz HDR monitors. ASUS has already masterplanned a 1000Hz display by year 2030.

Long term, rolling-scan BFI (emulation of a CRT electron beam) is also a practical method as a Holy Grail, also mentioned in these items that are masterplanned for about year ~2025

RetroArch BFIv3 concept: https://github.com/libretro/RetroArch/issues/10757
MAME Temporal HLSL https://github.com/mamedev/mame/issues/6762

Think about this -- assuming perfect blacks (OLED, MiniLED, or FALD LCD), it can pass the CRT turning test -- real tube versus a flat panel (behind thick glass) -- passing an A/B test is theoretically possible with a "retina resolution + retina refresh rate + retina HDR" display. A rolling-scan CRT emulator on a flat panel display encompasses the human perception venn diagram of a CRT tube.

This is likely possible between 2030-2040, but can already be tested (in less quality, but still superior to old BFI) on a 360Hz PG259QN since it can do 6 refresh cycles per emulated refresh cycle, allowing basic software-based rolling-scan CRT electron beam emulation!

tonioni commented 3 years ago

Problem is that I don't have >120Hz monitor. I prefer having single large ultra-wide screen monitors, currently 5120x1440, max 120Hz. It is fast enough with RTX3090. (3090 because 3080 is practically impossible to get), good for games, really good for any productivity task.

I also don't do any shader stuff. It is someone else's problem.

mdrejhon commented 3 years ago

@tonioni -- That said, you can do simple BFI at 180Hz / 240Hz / 300Hz / 360Hz without a shader.

Basically, ignore BFIv3 (which requires shader), and only worry about BFIv2 concept.

I only mentioned too much beyond, only simply as a long-term thought exercise. I think you may have accidentally latched onto this. Since high refresh rates are slowly commoditizing (even 240Hz will become widespread in ten to twenty years, with 1000Hz in premium), you can ignore BFIv3 until year 2025-2030. 240Hz tablets/smartphones have 1/4th the browser scrolling motion blur of 60Hz, so that's the next big thing for mainstream once 240Hz no longer is an esports refresh rate in the 2030s -- as doubling Hz/fps halves motion blur -- until we reach retina refresh rates (low-persistence sample-and-hold -- CRT clarity without any black frames/strobing/flicker). .

Anyway, near term -- the simple BFI (aka BFIv2) is now important.

No shader, already implemented in JavaScript

I even programmed it in JavaScript in TestUFO to demonstrate you don't need a shader It's just like the variable-pulse-width BFI animation:

LINK: TestUFO Variable-Blur 4-Frame-Sequence Black Frame Insertion Demo

See -- JavaScript -- and no shader! View the TestUFO animation at 120Hz with strobing ON versus strobing OFF -- and you will see how you can adjust the motionblur amount as a ratio of visible frames versus black frames.

A simple implementation of 180Hz/240Hz/300Hz/360Hz BFI should probably be only 100 lines of additional code.

How To Test 240 Hz BFI at 120 Hz

Use a slowdown factor as follows:

One you can test this by slowing down your emulator to 0.5x speed (30fps) and simulating 240Hz BFI at 120Hz in a kind of slo-mo BFI debugging. Use 0.6666x slowdown (Run 60Hz emulator at 40fps-40Hz at 40/60ths speed) for debugging 180Hz BFI at 120Hz. Once both 180Hz and 240Hz BFI works, then you don't need to debug any BFI ratios beyond 240Hz, since motion blur during non-strobed is very mathematically simple according to Blur Busters Law (1ms of pixel visibility time translates to 1 pixel of motion blur per 1000 pixels/sec), as seen in the motion animation demo.

For 240Hz BFI, think about the number of visible emulator frame versus black frame in a 4-frames-per-emu-refresh sequence:

25%:75%: VISIBLE:BLACK = 75% motion blur reduction without needing strobing 50%:50%: VISIBLE:BLACK = 50% motion blur reduction without needing strobing 75%:25%: VISIBLE:BLACK = 25% motion blur reduction without needing strobing

On certain models of 8-bit-panelled 240Hz monitors, some of these software-BFI settings look better than the hardware strobe backlight too, because there's no strobe crosstalk double-images. Mathematically it is simple.

You can simply use some kind of -bfisequence 3:1 command line option or something, to dictate how many visible frames and how many black frames -- and let advanced users decide.

Less than 100 lines of source code

You already implemented 120Hz BFI in year 2013, and the feature is still there, correct? So this is just a simple sub-100-line modification to the existing BFI feature in WinUAE, correct? It was crappy on TN panels with LightBoost in year 2013, but software BFI looks vastly better now (and sometimes better than hardware strobing, on certain panels).

Additional TestUFO Links Of Proposed WinUAE Modification

Note: If you don't have the refresh rate applicable, they will flicker like crazy. However, the 180Hz and 240Hz links above are still reasonably educational when viewed on a 120Hz panel. For 60 Hz users, only the first two links may be adequately educational.

Now that you clicked on the TestUFO link above -- do you understand better of the no-shader easy BFI option?