Description

RetroArch only supports 1-visible black frame insertion (and variable number of black frames via #11342) for motion blur reduction at this time, without adjustable-persistence.

Minor Feature Request

For 240Hz+ we need to support variable-percentage blur reduction:

1 visible, 3 blank (75% blur reduction, 75% dimmer)
2 visible, 2 blank (50% blur reduction, 50% dimmer)
3 visible 1 blank (25% blur reduction, 25% dimmer)

Here's a TestUFO animation doing the above variable blur-reduction successfully: (View at 240Hz): www.testufo.com/blackframes#count=4&bonusufo=1

View above link only on a 240Hz monitor, it shows four different 60fps UFOs with different amounts of display motion blur each. But what's different is that this animation works WAYYYYY better on a 240Hz OLED, than on a 240Hz LCD. It's as if OLED is a "natural fit for software BFI"!

No GPU blur effect was done to vary the motion blur at all! All blur is by the hardware sample-and-hold effect, manipulated by software-controlled ratio of visible:blank frames, made easily possible by real Hz far above emulator Hz.

You're simply controlling the amount of display-forced motion blur, by varying the ratio of visible:blackframe over a 4-refresh-cycle period (one emulator Hz).

There is a brightness-vs-motionblur tradeoff effect, but sometimes you need more aggressive settings for fast-motion such as Sonic Hedgehog style games etc.

Since I can do it in HTML JavaScript, it's proof-of-concept that you can software-control the amount of 60fps motion blur, by a variable amount, via a varying number of black frames in black-frame insertion.

My Tests show software BFI works shockingly well on 240 Hz OLED.

No inversion artifacts, no chessboard patterns, no image retention.

Sonic Hedgehog is FINALLY playable with just mere software BFI! Almost CRT-like, without needing ugly backlight strobing.

240Hz OLED produces amazing 60fps motion blur reduction in RetroArch when RetroArch's BFI is enabled. Seeing 60fps with 75% motion blur reduction, looks like a CRT tube! It already beats plasma!! Already on a display you can buy today!!

But the brightness-vs-clarity tradeoff needs to be adjustable.

Also, market for 240Hz OLED is going to boom. Almost none has BFI built into the monitor, so better BFI will need to be built into RetroArch.

List of 240Hz OLEDs arriving 2023

ASUS 27" desktop ROG Swift OLED PG27AWDM (shipping 2023)
LG 27" desktop UltraGear OLED model 27GR95QE-B (now shipping)
LG 45" ultrawide desktop UltraGear OLED model 45GR95QE (now shipping)
Corsair 45" ultrawide desktop Xeneon Flex model 45WQHD240 (shipping 2Q 2023)
Dough 27" desktop Eve Spectrum OLED (shipping 2023)
Acer 27" desktop Predator X27U (shipping 2023)
Acer 45" ultrawide desktop Predator X45 (shipping 2023)
MSI ultrawide desktop 491C QD-OLED (shipping 2023)

Some models are even debutting sub-$1K! This is an upcoming casual-gamerization of 240Hz -- you can't get a sub-$1000 desktop OLED of 27 inch non-television form factors for less than 240Hz refresh rate. No 60Hz or 120Hz non-television desktop sized OLEDs under $1000 exist -- the high Hz is included.

I have noticed with Apple 120Hz-ization and mainstream people buying up due to OLED rather than Hz, but the Hz is there, more casually than esports. So the high-Hz market is gradually getting bigger.

So we have to figure out easy ways to convert the brute Hz-room to provide users with 50fps-60fps blur-reduction, and here's my "easy setting" proposal to meet the mainstream market:

Possible Minimum-Code-Change Workflows.

Possible simplest route of config-only implementation

Perhaps modify the existing BFI switch in #11342 to accept an optional ratio (e.g. "1:3" or "2:2" or "3:1") or a refreshrate-independent percentage setting ("25%", "50%", "75%"). The detection of a colon in number would denote the BFI ratio. This simplifies programming, but requires an experienced user to tweak.

Possible simplest route of UI implementation

Perhaps as a simple "BFI slider" setting in RetroArch preferences? Percentage setting for this brightness-vs-clarity tradeoff setting. One that rounds-off to the best-effort based on current real Hz and current emulator Hz (e.g. 30% setting would click to a 1:3 visible:blackframe for 240Hz, and 2:4 for 360Hz, when doing 60Hz modules) with a possible warning indicator appearing if (real/emu) Hz is not closely divisible. Guiding notches could show up on the slider based on RealHz/EmuHz to help the end user, but it could just be stored as a percentage/floating value into a config file -- for very dirt-simple any-Hz compatibility.

The refresh-rate-independent percentage setting would be better (config or slider) and simpler for users:

The easy Hz-independent BFI percentage slider setting

For user intuitiveness -- Initially, to simplify things, the BFI slider could be greyed out if RealHz/EmuHz isn't close-enough divisible. Or a warning message would be pop up during a >5% error margin ("Emulator will run slow or fast since current refresh rate is not divisible by emulator refresh rate") while the emulator automatically compensates speed to keep an integer ratio.

RetroArch can just round-off the specified percentage to what is supported by the current (RealHz / EmuHz) for the current refresh rate and the currently configured emulator game. A 50% setting would automatically use 1:1 for 120Hz, 2:2 for 240Hz, 3:3 for 360Hz, and so on.

Non-divisble percentage settings like 30% would round-off to 1:3 visible:blackframes ratio at 240Hz, and would round-off to 2:4 visible:blackframes ratio at 360Hz. The settings file would only remember the percentage (or a float from 0.000 to 1.000). Much simpler setting, and easier for users to understand!

Actually, you can also invert the ratio (swap the numbers), and say 70% instead, for blackframes:visible, since bigger percentages imply "stronger BFI" or "stronger blur reduction". This might be even better.

Several TVs with black frame insertion sometimes also show it as a slider setting too, so the slider/percentage approach would be "in line with existing user interface norms" too, and minimize confusion.

And unchanged BFI setting keeps working fine even if you switch refresh rates (e.g. 120Hz vs 240Hz). No hassle of absolutely mandatory re-tweaking after switching refresh rates.

One percentage/strength setting = percentage of motion blur reduction you want! Simple.

Related Items

(BFI-related pull request) #11342 Commit that finally added 240Hz compatible BFI advanced-user config switch (variable Hz BFI), but didn't add the variable-ratio capability.
(complex) #10754 BFIv2 (might be too complex at current juncture)
(complex) #10757 BFIv3 (might be too complex at current juncture)

However, this github is a simpler/easier "next step" tweak for the upcoming boom of 240Hz OLEDs launched this year. Some of the other feature requests will make sense during the future 1000Hz OLED days, but this year, we've got a tsunami flood of 240Hz OLEDs needing the simpler BFI upgrade.

So I post this new github item as a break down to simplest possible next-step for BFI -- while simplifying it down to a single setting -- easily addable to settings UI -- that is understandable by less experienced users.

cc: @Ophidon @hizzlekizzle

Interesting stuff!

I'm surprised to hear that a higher proportion of black frames improves motion clarity. I would have expected just a single actual black frame per single frame of motion to have the same effect as additional black frames. I don't have a high-refresh monitor to see your PoC for myself, but I trust your assessment.

Interesting stuff!

I'm surprised to hear that a higher proportion of black frames improves motion clarity. I would have expected just a single actual black frame per single frame of motion to have the same effect as additional black frames. I don't have a high-refresh monitor to see your PoC for myself, but I trust your assessment.

@hizzlekizzle I am in more than 25 peer reviewed papers relating to display motion physics, www.blurbusters.com/area51

Scientifically, blur is based on pixel visibility time. Motion blur is frametime on sample and hold.

As you track your analog eyes across the static visible pixels of one visible frame, your eyes are in different positions at the beginning and end of pixel visibility time. That blurs the pixel visible time across your retinas.

It's like a camera exposure.

240fps 240Hz flickerless sample and hold = same blur as 1/240sec camera shutter.

(Assuming GtG=0, and all remaining blur is caused by sample and hold effect)

I already teach this in classroom training.

It's really easy to teach, since I bring 240Hz displays to presentations to software developers, engineers, project managers, management teams, etc.

Summary, motion blur is frametime on sample and hold, and pulsetime on impulsed.

240fps 240Hz unstrobed = 1/240sec motion blur
1000fps 1000Hz unstrobed = 1/1000sec motion blur
60fps 240Hz unstrobed = 1/60sec motion blur
60fps 60Hz unstrobed = 1/60sec motion blur (16.7ms)
60fps 60Hz strobed at 1ms flash = 1/1000sec motion blur (1ms)
60fps 60Hz strobed at 2ms flash = 2/1000sec motion blur (2ms)
60fps 60Hz strobed at 4ms flash = 4/1000sec motion blur (4ms)

It's all about large geometrics during framerate=Hz demos. That's why 240fps-vs-1000fps is more visible to mainstream than 144fps-vs-240fps or 240fps-vs-360fps. It's like comparing SLR camera sports photographs 1/240sec versus 1/1000sec --

Everyday users sees 4x motion blur differentials more easily than 1.5x motion blur differentials. That's why people need to upgrade refresh rates geometrically, if the display isn't briefening the pixel visibility time (aka flickerless sample and hold displays).

That's why small Hz upgrades are worthless to mainstream, and some people dismiss high Hz from an incorrect assumption of a hard-cutoff. When it's just merely simply a long geometric path of diminishing curve of returns, much like a camera shutter speed.

16/1000sec motion blur = 16 pixels of motion blur per 1000 pixels/sec
4/1000sec motion blur = 4 pixels of motion blur per 1000 pixels/sec

(I call this the simplified Blur Busters Law, as it helps understand how pixel visibility time in milliseconds, translates to perceived display motion blur during eye-tracking moving objects)

Fast scrolling games like Sonic Hedgehog scrolls at over 1000 pixels/sec. At 60Hz, you have 16.7 pixels of motion blur per 1000 pixels/sec. For double speed, double that to 33.3 pixels of motion blur per 2000 pixels/sec.

Some people will say, just flash a frame multiple times to reduce flicker, or some other "motion blur fix hack". I know all of them. If you repeat-pulse the same frame, you can get duplicate images. Remember the CRT 30fps at 60Hz double images? Ditto. Same for 120fps at 240Hz flashed 240 times, duplicate image count = (refreshrate / framerate).

It's just simply a function of your analog-moving-eyes tracking past repeat-flashes-of-unmoved-pixels -- which stamps duplicate copies of the image on your retinas.

Summary

Motion Blur is Pixel Visibility Time (Frametime or Pulsetime)

On sample-and-hold, motion blur is frametime.
On flicker displays (hardware or software BFI), motion blur is impulsetime (framerate=Hz to avoid duplicate images).

That's why we need 1000fps 1000Hz to match a CRT tube without needing strobing. You see, it's hard to reduce motion blur strobelessly via brute framerate-based motion blur reduction. Sample and hold (flickerless) requires 1ms frametimes (aka 1000fps 1000Hz, all unique temporally-correct frames) in order to have 1ms MPRT motion blur.

That's why CRTs did not need it, they briefly flickered a pixel very brightly for just approximately a millisecond (depends on phosphor persistence) before it phosphor-fades 90-99% away.

But in the Ergonomic Flicker Free Era, we have mandatory motion blur forced upon us. We can't be "blurfree+flickerfree" without quadruple digit refresh rates and frame rates.

Even VR is forced to flicker today, because we don't have enough refresh rate and frame rate to eliminate motion blur strobelessly. Someday, PSVR7 will be strobeless 1000fps 1000Hz, but right now, even an Oculus Quest 2 uses a low-persistence flicker at 0.3ms pulse per frame (refresh cycle). To avoid using any strobe/pwm/flicker in a display to get the same low-persistence, you will requires 3333fps 3333Hz to do strobelessly (0.3ms = 1/3333sec = same blur as a 1/3333sec SLR camera photo = requires 3333fps 3333Hz 0ms-GtG to match).

That's why low-persistence sample and hold requires insanely high frame rates at high refresh rates, and human-visible further-improvements requires major geometrics up the diminishing curve (e.g. 240fps-vs-1000fps, or 1000fps-vs-8000fps). The vanishing point / limiting factors was more recently researched, and it goes surprisingly high for very large-FOV high-resolution displays -- quintuple digits, apparently!

For use cases such as simulating real life (VR, AR, Star Trek Holodeck) it needs to do motion in an analog way to avoid motion blur and stroboscopic artifacts. Brute-sampling along the time axis (4-digit to 5-digit frame rates and refresh rates) is the closest we can get to making motion look like real life (no extra blur or stroboscopics forced on eyes above-and-beyond real life).

Now, if you want to read more, there's two key explainer articles, www.blurbusters.com/stroboscopics and www.blurbusters.com/1000hz-journey -- that covers the background of the diminishing curve of returns towards a "retina refresh rate".

Do you understand the refresh rate race better now? 😉

It's not just for esports.

It even benefits mainstream users, e.g. browser scrolling is 4x clearer on a 240Hz display.

That's why Apple / Samsung / Playstation / XBox is making 120Hz mainstream, and there are plans to make 240Hz mainstream eventually (2030+).

After all, I am in more than 25 peer reviewed papers now in the display-motion-blur universe, www.blurbusters.com/area51 (Easy explainers) and Google Scholar (complex) -- this has become textbook reading for scientific people needing simplified explanations about display motion blur.

Educational Variable-Blur BFI Animations

You can see for yourself, with your very own eyes

The easiest BFI demo is www.testufo.com/blackframes but it's just a simple 50% motion blur reduction (one visible frame, one black frame).

However, here's some additional animations with variable amounts of motion blur, depending on the refresh rate you own;

Variable-Blur Demo for 60 Hz to 180 Hz www.testufo.com/blackframes#count=3&bonusufo=1 3-UFO Variable-blur BFI that looks reasonably educational at 60Hz-180Hz Warning this will flicker at 20Hz, due to insufficient refresh rate. However, you can see that the first 3 UFOs have different amounts of motion blur. This animation will run at 20fps at 60hz, or 40fps at 120Hz, or 60fps at 180Hz. In all cases, it still looks educational
Variable-Blur Demo for 120 Hz to 300 Hz www.testufo.com/blackframes#count=4&bonusufo=1 4-UFO Variable-blur BFI that looks educational at 120Hz-300Hz (60fps at 240Hz)
Variable-Blur Demo for 240 Hz to 540 Hz www.testufo.com/blackframes#count=6&bonusufo=1 6-UFO Variable-blur BFI that looks educational at 240-540Hz (60fps at 360Hz)

Best to view on a bigger screen (tablet or desktop), the higher Hz the better.

More Info

Also, a bonus full-framerate UFO is displayed at the bottom, next to the low-framerate BFI. Showing the reference motion blur for non-BFI framerate=Hz.

The higher the Hz, the more educational it will be, because you have multiple options of visible:blank while keeping framerates 60fps or above. (This is why my display-science classrooms always use 240Hz+ monitor -- people "figure out" display motion science & physics so much faster when you have the ability to compare geometrics better, e.g. 60-vs-120-vs-240-vs-480, and such).

For example, a 360Hz monitor gives you (360/60) = 6 different display motion blur settings for 60fps completely via software-based black frame insertion, from 0/6ths through 5/6ths motion blur reduction.

You can even manually configure the number of UFOs, e.g. 5-UFO (300Hz) or 7-UFO (540Hz) to get an exact 60fps. I simply provided only 3 preconfigured links, to simplify choice for readers, since flicker can distract from the education (e.g. doing 8 UFOs at 60Hz will just mostly ruin the educationalness of the animation).

However, I've done my best to be educational given your specific Hz limitations -- I have provided the appropriate links, depending on the refresh rate you currently own.

Great post, it explains a lot and makes easier to make retroarch experience closer to CRT original. In fact, I will go for one of those new OLED 240Hz myself, I hope I can finally get rid of the bulky CRTs once for all. Thank you for sharing this!

How does this look on a 240hz non-oled monitor though?

How does this look on a 240hz non-oled monitor though?

@Tasosgemah - still pretty good if you use a good emulator module. Some emulators stutter too much at 240Hz, tho. Use Performance Plan, to disable as much power management as possible. And make sure it's a good fast 240Hz such as the ViewSonic XG2431, which has the industry's best 60Hz single-strobe motion blur reduction for emulators too.

So you have two ways in the same 240Hz monitor;

1ms BFI - Hardware-based 60Hz strobing (less blur but can flicker a lot); and
4ms BFI - Software BFI on 240Hz (can flicker less)

A great demo of "More Hz The Merrier" is TestUFO Variable Persistence Demo For 240Hz Monitors

120Hz BFI can reduce 60Hz blur by 50%
240Hz BFI can reduce 60Hz blur by 25%,50%,75%
360Hz BFI can reduce 60Hz blur by 16%,33%,50%,66%,83%
480Hz BFI can reduce 60Hz blur by 12%,25%,33%,50%,66%,75%,83%

You can see for yourself in TestUFO Variable Persistence Demo link, for a gaming monitor of specific Hz. Don't try the link at 60Hz, it flickers too much, but you can fiddle the settings (3 UFOs at 20fps) and still get the idea that motion blur is simply visible frame pulsewidth during software BFI! So more Hz the merrier, in see-for-yourself demo link.

And the Retrotink 4K can do it too (which is why it's awarded the Blur Busters Approved logo). I worked with Retrotink 4K to add 240Hz BFI support! (And apparently it also works at 720p for 360Hz, with a custom modeline on SD card). RetroArch didn't beat Retrotink (so hurry up), it's actually easy to program.

Reduced Source Code Bounty Requirements ($500 Bounty)

Developers, see #10758 and the https://github.com/libretro/RetroArch/issues/10758#issuecomment-1839907540 for my announcement of my reduced Source Code Bounty Requirements requirements, to keep progress going incrementally.

A great demo of "More Hz The Merrier" is TestUFO Variable Persistence Demo For 240Hz Monitors

This demo looks fine on my 240hz monitor. In that the UFOs either don't flicker or if they do flicked they do so consistently, with an even rhythm. In RetroArch though, the flickering is uneven and looks wrong. I have to reduce my native refresh rate to 120hz to fix this (content runs at 60fps). Is there a specific core you can recommend that works better for this?

Also, is there any other solution for the darken visuals? I have the AW2518HF monitor and it doesn't have HDR afaik.

Should this issue be closed? RetroArch seems to have this now? Looks really strobey on my 240 Hz OLED though regardless of how many black frames I use per set of four. Might be a sync thing, the strobing seems to alternate in intensity which is really distracting. I feel like I'd be much more okay with a constant flicker but I'm a layman, maybe it's supposed to look like this. Do you know what would cause this, @mdrejhon? You're the best, by the way.

When working correctly there should not be any noticeable variable flicker at all at 240hz or otherwise. I'm the RA dev of the feature, and currently have up to a 360hz panel to test with.

Some things to verify are that the panel is set to the correct Hz, that RA is set to that same refresh rate on the video->output settings and that the estimated screen refresh is also giving you an expected rate. Also make sure vsync is not disabled at an OS level overriding RA, and that you don't have a frame limiter set below the configured refresh rate. (A lot of gsync config guides, especially from BlurBusters, recommend a framecap 2-3 fps below refresh rate but you do not want to do that for RA bfi). Then of course verify that your RA BFI setting is set to the (use at 240hz) setting for your case.

Beyond this... 240hz is actually very demanding even on my amd 7700x with a 4090 in very high accuracy intensive cores like mesen/bsnes and I heavily recommend the lighter weight alternatives like snes9x (that are still accurate for 99%+ of stuff) as the hz rises. When you fail to meet speed requirements but by a small margin so that you're only dropping the occasional frame... it will look exactly like 'strobey' alternating bfi intensity, which is indeed awful. Whether even those lighter weight cores are good enough on a much lower end cpu, I am not sure.

Another related setting that outside of BFI use you'll usually you'll want very low is any form of max swapchain images for your driver, but will want higher when using higher hz bfi, and also disable ultra low latency mode if you're using nvidia in the control panel as what that does is force the swapchain images to a minimum. At 240hz, bfi consumes 4 swapchain images per real 60hz frame, so it isn't nearly as detrimental to lag as you might think, and instead can be very important for being able to meet the speed requirements.

A last alternative, and is what I tend to use myself most of the time, is running the panel at 180hz instead. The speed requirements are noticeably lowered, and 180hz also allows a 66% blur reduction for a 66% brightness reduction trade-off, which is about what I'd consider the max you can get away with as far as brightness reduction. At 240hz, you are limited to either 75%/75% or 50/50%, one being a bit too much, one being not enough, at least in my opinion. But to run at 180hz, you'll have to create a custom resolution most likely, as I've yet to see a 240hz panel that had 180Hz as a built in rate. There are lots of guides on the net for adding a custom resolution though.

The "verify steps" are actually a separate issue, and the optimizing is a separate issue (see #11390 !!!) but previously before today, 240Hz flickered too unusably.

Now 240Hz BFI (if run at 240Hz) no longer flickers erratically on most cores at 240Hz thanks to Ophidon's work at #16142. Also, now you do variable-persistence BFI, ala www.testufo.com/blackframes#count=4&bonusufo=1 (Test this at 240Hz).

Therefore, the minimum requirement seems to be solved.

Solved by #16142

I expressly said "minor tweak", and Ophidon did that.
However, additional work is welcome to improve warnings, reliability, etc. However, that's the scope of additional github issue reports (create a new issue with reproduction instructions).

Now A Special Request:

Another idea is to decouple RetroArch rendering and put the swapchain system into a separate thread running at a higher priority than the rendering thread. That way the swapchain thread can memorize the last cycle of frames and keep repeating the cycle if a new frame hasn't arrived from the render thread. And since swapchain is just waiting to swap, putting that framebuffer-flipper thread to HIGH or REALTIME priority is usually OK -- since it's only waiting to flip at the most precise time. So the emulator can still run underperformant without erratic BFI flickers. It'd just look like a stutter on a CRT merrily flickering at its original rate. But that's the scope of my #11390 rather than this #16142 which I now declare as solved -- you did the minimum minor tweak to make BFI on 240Hz OLED usable in the first place.

New focus is now #11390

TL;DR Version Of This Feature Request 11390

RetroArch frame-presenter (swapchain) thread made separate from emulator/renderer thread

Frame presenter thread (thread responsible for swapchain) is higher priority than renderer thread.

There is never a draw call (not even to draw a single pixel or erase framebuffer) in the frame presenter thread. (Note: For BFI, any use of black frame buffers is a pre-rendered black buffer, to prevent GPU/CPU stalls to framepacing)

This solves a hell of a lot of problems with framepacing -- and improves many algorithms. It will makes perfect BFI flicker possible during CPU-stutter situations (it'd just look like a CRT stuttering -- with no modification to flicker rate).

Even those hard cores like bsnes would still BFI perfectly at 240Hz, even if bsnes runs at 57fps and stutters a bit. It may temporarily cease to be beamraceable (Lagless VSYNC #6984 that optionally might want to run in sync with beam simulators like BFIv3 #10757) but the BFI would still flicker at a constant rate like a CRT, despite the underlying stutters.

It would allow a lot of feature additions, including zero-latency emulation (lagless VSYNC like WinUAE) to make RetroArch match the latency of an FPGA (to within one frameslice, ala #6984)

This will improve reliability even further and add some magical powers.

Although @Ophidon likely won't work on this, I welcome anybody who does -- solving #11390 will allow #10757 BFIv3 to be reliably possible even without using beam racing (and even when underlying emulator might sometimes stutter).

libretro / RetroArch

Minor tweak to RetroArch BFI to improve compatibility with 240Hz OLEDs #15299