Open mdrejhon opened 4 years ago
@twinaphex / @hunterk, who was the one who originally programmed the original BFI feature in RetroArch?
I think it was Themaister. He doesn't really work on RetroArch anymore, but I'm sure someone else could expand on it.
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?
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.
UPDATE!
I just updated the feature description.
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
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!
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.
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.
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.
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).
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).
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.
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.
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.
UPDATE: There is an item that may make BFIv2 easier/more flexible.
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
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.
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.
See https://github.com/libretro/RetroArch/issues/10758#issuecomment-1839907540
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
- Even without beam racing the destination display, it allows slow continuous metering out to GPU for preventing power management stutters
- Frameslice beam racing (#6984)
- 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)
- Etc.
cc: @hizzlekizzle
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:
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
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.