[Feature Request] (BFIv2) BFI is more CRT-like at higher Hz. Need 60Hz BFI for 180Hz, 240Hz, 300Hz, 360Hz

[mdrejhon]

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 in RetroArch
BFIv2 = Improvements to BFI for higher Hz, FOCUS OF THIS GITHUB ITEM
BFIv3 = Rolling-bar BFI, emulating CRT electron gun temporally, See GitHub #10757

Retroarch already supports 60Hz BFI for 120Hz

60Hz Black Frame Insertion (BFI) improves massively at higher refresh rates for multiple reasons. Strobed and non-strobed. RetroArch 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 RetroArch. 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 RetroArch 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

We neeed RetroArch to 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 RetroArchfor 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 [Feature Request] (BFIv3) Emulate a CRT Electron Beam Via Rolling-Scan BFI #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 RetroArch 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]

@twinaphex / @hunterk, who was the one who originally programmed the original BFI feature in RetroArch?

[hizzlekizzle]

I think it was Themaister. He doesn't really work on RetroArch anymore, but I'm sure someone else could expand on it.

[mdrejhon]

I think it was Themaister. He doesn't really work on RetroArch anymore, but I'm sure someone else could expand on it.

Are there anyone else other than @Themaister who has ever worked on RetroArch's BFI feature?

[hizzlekizzle]

I think anyone who implemented a video driver that supports it would have had some contact with it. It shouldn't be terribly complicated to work on it, but it will need to be done for each video driver.

[mdrejhon]

UPDATE!

1. I just updated the feature description.

2. GroovyMAME just implemented a very basic version of 180Hz, 240Hz, 300Hz and 360Hz BFI, at least covering the "Best Case Display Motion Blur Reduction by BFI" section.

See http://forum.arcadecontrols.com/index.php/topic,162926.msg1716439.html#msg1716439

[mdrejhon]

For an explanation why image retention occurs with softare BFI, this is an explanation:
http://forum.arcadecontrols.com/index.php/topic,162926.msg1715845.html?PHPSESSID=6c20t410rjdbcu2jh4a5lhisdj#msg1715845

There is also an algorithm to prevent "burn-in" on old LightBoost monitors, too!

[mdrejhon]

Someone has posted an experimental patch but is asking for help to polish the patch befire commit:
https://forums.blurbusters.com/viewtopic.php?f=22&t=7496

This is in a github fork:
https://github.com/Ophidon/RetroArch/pull/2

And a test executable for 240Hz monitor owners:

Here is a link to the modded retroarch exe which you just drop in replace for your current exe:
https://drive.google.com/file/d/19RLnbd ... sp=sharing

It works fantastically but should be adjusted to be more flexible, to support the comma sequences ideally.

There needs to be some more polishing work before it can be merged in and BFIv2 closed.

[hizzlekizzle]

They paid a visit to our discord server recently and we discussed some of it. They intend to clean up the PR a bit and then submit it and we can work with them to get everything covered and implemented.

[mdrejhon]

Great to hear!

Long-term, frame presenting will need to be in a separate dedicated thread, separate of the frame rendering (emulator execution), though probably not critical for 240Hz-360Hz:

https://forums.blurbusters.com/viewtopic.php?f=22&t=7496&p=57221#p57119

https://forums.blurbusters.com/viewtopic.php?f=22&t=7496&p=57221#p57130

It's might not be a mandatory feature yet, but increasing refresh rates (240Hz->360Hz->480Hz->720Hz->1000Hz) over this decade, will demand more precision to avoid flicker, and such precision will likely be mandatory for BFIv3 (#10757) at the higher Hz's.

[mdrejhon]

Crossposting from commit comments:

Congratulations on the initial BFIv2 source code commit!

This makes RetroArch 180Hz BFI and 240Hz BFI capable now!

This really looks great, superior to 120Hz BFI as expected. And also burnin-proof.

Very good for fast-scrolling arcade games, including platformers and other things that often motionblurred on LCDs.

Still Needs Custom Configurability

However, the comma-separated feature is still currently missing; so this item can't yet be closed until the BFIv2 is considered feature-complete. Internally, the string would be a float array, which indicates the alpha value between the visible image and a black frame (0.5 representing a half dimmed frame).

1. At first, the comma-separated BFI string could be a configuration-file-only feature initially. Basically of only interest for experimentation. Wouldn't this be a quick change? Doesn't RetroArch support undocumented options? (If I am wrong, then yeah, it would be harder).

2. Use padding (zeros) for BFI-sequence float array / comma strings that are too short. "1,0" for 120Hz would means "1,0,0,0" for 240Hz.

3. Use trunctation for BFI-sequence float array / comma strings that are too long. "1, 0.5, 0.25, 0" for 240Hz becomes "1, 0.5" for 120Hz.

4. Standard settings can be in menus, while custom string would be loaded

Settings configurability considerations

Since comma-separated strings can't be done in settings, you can simply load a string from configuration file and parse it into a float array. Internally RetroArch can synthetically generate its own internal BFI-sequence float array (stand-in for comma-separated string).

You could a list of named profiles (predefined comma strings for common BFI modes like "1,0,0,0,0" and "1,1,0,0,0,0" and "1,0.5,0,25,0") with one of the settings being "Custom" (load string from configuration file)

If you want to give users more menu configurability, you can use things like "BFI Full Brightnes Frame Count: Number", "BFI Decay Frame Count: Number" (phosphor decay simulation, fade frames to black in consecutive refresh cycles). And use a "Custom" setting to optionally load a string from configuration file.

Custom BFI string feature is needed to enable advanced-user configuration (people like me) to discover improved BFI sequences as well as burnin-proof BFI sequences for specific monitors, as well as more eye-friendly BFI sequences or those that are brighter without sacrificing too much motion blur, etc. Discovered good strings can later be added as extra named profiles for easy user selection.

Any of the above methods would qualify for closing this BFIv2 github feature request item.

[mdrejhon]

UPDATE: There is an item that may make BFIv2 easier/more flexible.

[Feature Request] Futureproof RetroArch with precision frame pacing presenter thread

[mdrejhon]

BFI looks absoutely fantastic on the new 240Hz OLEDs.

75% reduction in motion blur + no LCD-style side effects!

Any movement on improving the BFI feature?

EDIT: Added #15299 as an incremental "break down to simple steps" pre-requisite for this #10754

[Tasosgemah]

Is this implemented in RetroArch? I can't see a difference in version 1.16.0, BFI is the same for me as it always has been, it flickers unevenly at 240hz and it needs 120hz to be even. It also naturally darkens the colors too much so it's unusable really.

[mdrejhon]

There should be the addition of a SDR->HDR converter with an HDR nits booster (I worked with Retrotink 4K which can do that), to brighten BFI via the HDR mechanism. Which can work with many HDR displays.

---

While there's a command line option (use 3 instead of 1 black frame) to get 240Hz BFI working better. However, it doesn't work very well with all emulator modules -- the frame timing of RetroArch could use some further improvement, to try to time the frame presentation as micro-second prcise.

The snap-to behavior of 60Hz refresh cycles (1/60sec ~= 16.7) is much easier than the snap-to behavior of 240Hz refresh cycles (1/240sec ~= 4.2ms) which presents more opportunity for the visible/black frames to accidentally display to the wrong refresh cycles.

Your computer should also have its power management disabled, because GPU power management (e.g. idling between 60Hz emulator refresh cycles) can be a problem.

Emulators with command line options to let it execute GPU operations in realtime (e.g. draw rasters to its GPU framebuffer every 1ms) usually work better than emulators that surge-execute at the beginning of its 1/60sec interval.

This means if one emulator takes only 1-2ms to finish rendering a 60Hz emulated refresh cycles, your real GPU is idling for literally ~15ms until next emulator refresh cycle. That puts the GPU Power Management to sleep, and produces new timing inaccuracies.

[mdrejhon]

Reduced Source Code Bounty Requirements ($500 Bounty)

See #10758 (comment)

Did you know Retrotink 4K is a Blur Busters Approved product? I worked with them to add fully adjustable 240Hz BFI to a composite/S-Video/component signal, for output to any 240Hz LCD or OLED. I recommend the new 240Hz OLEDs, since you can reduce 60Hz motion blur by 75% with the 240:60 ratio combined with GtG=nigh near 0. Perfect Sonic Hedgehog with BFI and CRT filters simultaneously...

Retrotink 4K can do everything TestUFO can, including TestUFO Variable Persistence Demo For 240Hz Monitors and even brighten using a HDR nits booster, brighter than LG firmware TV BFI! So I'm way ahead of RetroArch, in an already released BFI product.

So RetroArch, please catch up!

I want to see open source versions.

Also, crosspost:

I recommend #10758 -- "retro_set_raster_poll" API should be added.

By encouraging emulator modules to relay one rendered scanline at a time to RetroArch, this will improve reliability of RetroArch even without frameslice beamracing, because it will keep the GPU's from sleeping, by metering out GPU rendering in tiny time slices (e.g. every 1ms), prevening the GPU from going to sleep between emulator refresh cycles. So this refactoring by pre-requisite #10758 has some MAJOR spinoff benefits, even without frameslice beam racing.

Even emulators that don't beamrace, but execute their frame rendering in realtime (e.g. run in 1ms increments and render directly to GPU framebuffer without letting GPU power-management itself to sleep) also tends to framepace better on 240Hz monitors without needing VRR help, making other things like monolithic BFI more practical.

Obviously, RunAhead is different (not realtime), but it can still benefit; it just runs a big bunch of frames continually (fast raster scanout to many frames), so it will still be a benefit. And you can disable processing in retro_set_raster_poll (dummy hooks) for most modules, and just iterate enhancements later into it. And when 1000Hz OLEDs come, we can forget frameslice beam racing, and simply display 16 incrementally-scanned-out full screen digital refresh cycles per 1 real refresh cycle (much easier to implement low-lag beam racing this way, since full screen refresh cycles are only 1ms). I'm going to see the 480Hz OLED in the invite-only demo room at CES 2024, so ultra high Hz displays are among us, one can't buy a desktop 27" OLED with a refresh rate less than 240Hz; it merely starts there -- even for productivity.

I'd like to see retro_set_raster_poll (#10758) implemented.

Reduced Source Code Bounty Requirements ($500 Bounty)

Special offer: I'll even water-down my existing bounty (#6984) to be paid out only on the mere completion of #10758 if it helps reduce workload. It's such an important germane improvement that enables a lot of spinoff benefits:

Benefits Of Just Merely Programming Only #10758

1. Even without beam racing the destination display, it allows slow continuous metering out to GPU for preventing power management stutters
2. Frameslice beam racing (Add Beam Racing/Scanline Sync to RetroArch (aka Lagless VSYNC) #6984)
3. Ultra high Hz beam racing (480Hz OLEDs allow fully easily displaying 8 partially scanned out emulator frames per 60Hz emulator refresh cycle, and upcoming 1000Hz OLEDs allow fully easily displaying 16 partially scanned out emulator frames per 60Hz emulator refresh cycles)
4. Etc.

cc: @hizzlekizzle

[mdrejhon]

Relevant: How to avoid image retention on LCDs (even at 120Hz) with black frame insertion