As per my commit notes:
- Adds BFI to dx10/11/12 in general.
- Updates existing BFI menu option descriptions to be somewhat more clear in how to use correctly.
- Adds Variable Strobe length via new 'Dark Frames' bfi sub-choice. Only valid at 180hz and above, as it must work with whole frames.
- Algorithm to auto select 'decent' Dark Frames choice, for any given selected BFI refresh rate. Will also avoid defaults that can cause Image Retention at any Hz higher than 120. (Impossible to avoid at 120 if you have an affected screen... get an OLED
) .- Some sanity checking on selecting BFI or the other synchronizations options like Swap Interval > 1, that don't play well with BFI.
--
BFI addition to the dx render engines, and variable length strobe to adjust brightness vs clarity being the biggest additions.
So, one I just thought this would be the crowd most interested in this update, and two it would be the crowd that can most help me find any sticking points in how reasonably informed people fail to set it up correctly, or any actual bugs (I can only test myself from an nvidia gpu on Windows, with 240hz screens). I'd like feedback because I also plan to write a decent length BFI usage guide for the libretro doc site, to go along with the Obtaining Optimal V-Sync Performance guide I updated here: https://docs.libretro.com/guides/optimal-vsync/
That guide is important for this, because if you want software bfi that doesn't do annoying flickering (and I can assure you, with capable hardware, you can get it to where you get no flickers in hours of use), you need everything else set up correctly for smooth perfect frame pacing.
If you are unsure, and want to know why you might be interested in software implemented BFI like this over hardware implementation (on the little hardware that supports a 60hz strobe), especially on an LCD, by far the most critical advantage in my opinion is that eye strain from the flicker is FAR less than an equivalent hardware 60hz full backlight flicker, which makes it.. you know, actually usable, and not just cool 'in theory'. As has been discussed elsewhere, software BFI piggybacks off the rolling scanout of pixels that is happening anyway, which is much closer to how CRTs did things, than how hardware lcd BFI turns the entire backlight on and off instantly. There is also never any crosstalk, but even that I consider a much smaller advantage than the eye strain issue.
This is less of an issue on oled, where most all screens do even hardware BFI in this scan out fashion. But even LG is seemingly in the process of phasing out bfi in their newest panels, and as it is now, only offers a 50% duty cycle strobe, leading to nearly double the MPRT (aka nearly double the blur) of my recommended settings below.
Some quick usage notes to start you:
If you have an affected lcd (oled should apparently be safe) and try to use it at 120hz and see temporary image retention on your screen, disable it and use a different screen or just give up if you have to. Not all non-oleds are affected, but you shouldn't use this on one that is. It wont cause permanent damage, but the longer you run it that way, the longer it takes to self-correct, and there is no setting change that will counteract it and let you continue usage. This is a phase aligned voltage retention issue that has been known quite a while.
Next, while I've gone ahead and implemented support up to VERY high hz, my overall recommendation is the same as with the previous implementation. 180Hz with 2 out of 3 frames dark, leading to a ~5.55 MPRT at a brightness loss that within the range that can typically be compensated by raising your panel brightness, unless you sear your eyeballs with very high brightness settings for standard usage anyway. On almost all capable panels, to run at 180hz you will have to create a custom resolution, I believe there are guides on this exact site for doing so. Why they add refresh rates like 165hz and 200hz by default, but skip over the 60hz multiple, is beyond me.
Another factor with this recommendation is, as silly as it sounds, your pc performance even for lowly NES emulation on modern high-end CPUs, becomes a factor more and more as you increase the hz you're trying to use BFI at. At 180hz, to avoid problems you need to be able to output a frame in 1/3d the time it would have at 60hz. Using a super accurate NES emulator like Mesen, with a high quality CRT shader on, and run-ahead on at 1 frame.. even my 7700x with a 4090 drops a few frames (which leads to noticeable flicker) at 240hz, but not at 180hz.
This performance problem will go away in the future, -hopefully-, when the graphics api's increase the number of frames that can be buffered. They hopefully will think about that as screen refresh rates continue to skyrocket to 480hz and beyond. 4 is the typical limit for now, and for normal usage... allowing 4 frames to be buffered leads to truly awful input lag, but not for this BFI implementation. 4 actual frames are used to display one 'real' 60hz frame at 240hz! So work on the next real frame cant start while the previous is still rendering.
Also, 180hz, and all other odd multiples of 60hz are completely safe from the voltage retention issue mentioned above. Even intervals, other than 120Hz of course and regrettably for lcds, all default to a Dark Frames setting that -should- be immune as well. Consider that the voltage phases of frames are going to alternate between + and -, so what you want for an even multiple of 60hz, is to display an even number of 'on' pulses, 2 'on' out of four for 240hz, 2 or 4 'on' out of six for 360hz, etc.
Lastly, this is of course, only really useful for 60 fps games through RA, if you try to use it on 'newer' systems (aka lots of games from the ps1 era and beyond) that run at 20 or 30 fps, you will just be replacing awful motion blur with awful, sharp, double/triple images.