BFI Shader: adaptive_strobe-koko

RetroArch Additions Shaders
#1

Hi there,
I’d like to share my take on the sample-and-hold induced blur.

Simple strategies usually insert black subframes to make motion crisp, but this has the obvious limit that the image will be darker (@GemaH).
while more complex ones even tries to emulate the beam, but they always trade brightness for clarity.

The idea here is to alternately brighten/darken every screen pixel without clipping bright tones/crushing dark ones so that the perceived average image will be the source one.

The pro is that the image retains its brightness; the con is that the effect will be less evident on higher and dark colors (due to less “room” to change brightness without going into high/low “saturation”);

On top of that, the LCD or OLED “pixel” refresh (B2W,GTG,BWB) has to be low and the screen refresh at least 120Hz to allow subframes (even though surprisingly my poor mva monitor benefits from this shader even at 60hz but with evident flickering ofc.)

However, even if the theory is exact and implementation correct (which I don’t claim) If the pixel refresh time is high or uneven when going from dark to white vs white to dark, the resulting image color/gamma may differ from the source one.

My LG OLED C2 at 120hz performs very well, my DELL IPS is completely trash and my Benq mva has serious issues with dark tones.

Btw, I’ve added some tunables in the shader for you to try to compensate display shortcomings:

  • Adaptive Strobe (~BFI) Strength:
    This is the strength of the effect, the more the less motion blur, the more the flickering.
  • Gain adjustment:
    The shader will never clip the image, but If it appear unbalanced compared to bright tones you can lower this parameter.
  • Post Gamma adjustment:
    Even if i never found this useful in my test, maybe some display will need some gamma adjustment.
  • LCD Retention workaround cadence (frames):
    Some (IPS?) panels may suffer from temporary image retention when BFI/like is used. This parameter will invert the flipping every number of frames configured, hopefully workarounding that issue.
  • Debug: Flip effect ON/OFF every (frames):
    This value will temporarily disable the shader every specified number of frames, allowing you to easily observe any difference.

I’d like to hear about how this performs on your hardware, possibly when using subframes, maybe I’ll submit for integration to the official slang shader repo.

The shader can be appended without problems (albeit it seems there may be with HDR enabled).

edit

adaptive_strobe-koko has been added to the official Retroarch slang shaders (subframes-bfi/ folder)

10 Likes
Let's talk about the beam simulator, displays, etc
CyberLab Death To Pixels Shader Preset Packs
#2

I added a pre-gamma setting too. Also, there was a bug (fixed) that caused the shader to be always disabled on some gpus when the debug option was set to 0.0.

Since this shader theory is very very… VERY simple, much of the problems that can be observed really depend just on the end user display.

I added the knobs that can be useful on the hardware i tested it on, but I’d really like to have some feedback to make it work on a wider range of devices, thanks!

http://wpage.unina.it/aorefice/sharevari/adaptive_strobe-koko-2.zip

2 Likes
#3

You know, I actually had an idea for this type of BFI/Strobing/Sample and Hold Reduction but my idea was to simply divide the screen into a checkerboard pattern and blank off alternating pixels from each line.

1 Like
#4

Tried :slight_smile: It is buried somewhere in koko-aio as a dead function called strobe_checkerboard() if I remember well, not really effective unfortunately…

1 Like
#5

Thanks to @hunterk, the shader should be available under subframe-bfi/ shaders through retroarch online update.

I renew the request for testing results.

1 Like
#6

I’ve done a lot of testing with checkerboard and interlacing-style (either horizontal or vertical lines) and none of them help with motion clarity for some reason (with checks/lines sized either as physical pixels or game texels). I had read some stuff on the blurbusters forum about this being the case, but I had to see for myself :stuck_out_tongue:

1 Like
#7

I made a PR just now, there’s now a new parameter to hard limit the maximum effect.

Since it works by oscillating around a center color, mid tones, as said, are more affected, but the main strength parameter acts as a global scale; which means you could have an image that flickers alot in some areas and almost none in other; now it is possible to limit the flickering (thus shifting the shader behaviour towards a generic/dumb bfi).

1 Like
#8

Yet another parameter (upstream PR pending):

Schermata_20260425_153835
Schermata_20260425_153835811×81 9.19 KB

By switching it on, the whole effect will be applied only to screen parts that are moving; this not only eliminates flickering when not needed, but greatly mitigates all of the other screen related issues discussed in the OP, including the screen retention ones.

eg: in this frame the only moving part is the sonic sprite, jumping and spinning; you can notice the strobe effect being applied just there.

Schermata_20260425_154249
Schermata_20260425_154249939×736 131 KB

The change has been just integrated in koko-aio too.

2 Likes
Koko-aio shader discussions and updates
#9

Neat! I’ve played around with this concept in the past with conventional BFI and it looked simply atrocious there. I’ll have to give yours a spin :smiley:

2 Likes
#10

I tested on 60hz, maybe some special handling is needed when dealing with subframes and feedback to spot moving things, now that I think of it?

–edit– After alot of testing, since the “selective” feature works fine till 120hz, I decided to leave as is and just add a note; it would be too complex (and heavier too) for little gain; 180hz and up should be flicker free anyway.

3 Likes
#11

Here you go:

I tried Appending it to CyberLab Guest 4K HDR Game BFI Turbo Duo_DC Composite CyberTron Vivid Smooth Advanced.slangp both after appending the Phosphor Persistence Shader in Shaders_Slang\CRT\CRT-Effects and also without the Phosphor Persistence Shader.

#12

Those presets work under Windows only, since they reference “Shaders” rathern than “shader” and /shaders_slang/" rather than the real folder name: /Shaders_Slang/"

You probably wanted your installation to be merged with the retroarch tree, but I’d rather prefer not to mix them, so I mirrored my whole /shaders/ directory elsewhere.

Being me under Linux, I’ve had to manually correct the letter case and I made it work, then loaded your preset and appended adaptive-strobe, no problem here, tested Vulkan and GLCore.

Maybe is something tied to HDR stuff ? I dont use it.

#13

I see. The folders in the .zip have caps but the shader presets themselves reference the correct folders crerated by RetroArch, for example shaders\shaders_slang\crt-guest-advanced-2026-06-22-release1.

Maybe a very very long time ago but I prefer them to be a separate optional add-on project now. Maybe at some point when things are more mature and stable, I’ll reconsider.

The only folder that might have needed adjusting if you had copied the contents of the Shaders folder instead of copying the entire folder would have been the Shaders_Slang folder.

It seems to work when appended with HDR off.

Not sure why but performance seemed better with it prepended though.

#14

Generally speaking, appended shaders are more gpu demanding, because they work at screen resolution rather than core resolution.

As per effectiveness in motion blur reduction, however, postponing adaptive-strobe leads to better results, since the oscillation happens around the final color.

Quick example:

If you have a white square and apply the shader, there will be no room to oscillate.

But if you apply scanlines and then the strobe, then there will be room to oscillate around the gray shades created by the scanlines effect.

Can I test HDR somehow without an HDR screen? I would like to understand if there is some quick workaround to the black screen issue.

PS: Your presets didn’t worked for me (followed the installation readme), before I changed to lowercase.

1 Like
#15

Yes, you mentioned this. I’ll address the case of the folders in my next release. What I was saying is that if you examine the presets themselves, the paths are in the proper case and I provided an example.

I have no idea.

I understand. I realize your method still seems to take a static full screen approach, rather than a rolling scan approach which is what I think I’m seeing with CRT-Beam-Simulator. What if the screen could be divided into odd and even light and dark thirds then have those flipped wouldn’t there be a brightness benefit?

On the other hand could this approach encounter temporal artifacts?

#16

@kokoko3k Loading adaptive_strobe-koko by itself in HDR results in a black screen, at least with vulkan (didn’t test the rest, maybe later). So that has nothing to do with appending to @Cyber’s presets, it’s just inherent to how adaptive_strobe-koko interacts with RetroArch’s current HDR shader system i guess.

Appending hdr-config.slangp from the hdr folder after adaptive_strobe-koko appears to resolve the issue, and i would recommend just telling people to do that rather than trying to hack together a testing environment for hardware you don’t have.

In general, i have found that subframe BFI shaders should be placed after all other SDR shaders in the chain, but before any HDR shader, for the best results. I personally use bfi-simple, but i think the same should apply for adaptive_strobe-koko as well.

1 Like
#17

Have you noticed any difference between bfi-simple and adaptive_strobe-koko? Have you tested CRT-Beam-Shader or Shaderbeam as well? I’d just like some more opinions on the matter.

I remember when I first evaluated my TV’s hardware BFI vs no BFI, I could have noticed the difference but in testing adaptive_strobe-koko, I can’t really see a huge difference with the naked eye I know it has the potential to be brighter and I know it’s doing its thing, but does it actually improve smoothness by any real measurable amount or is it placebo? I think what I’m saying is that I’m ready for a shootout of all the various BFI techniques I really like adaptive_strobe-koko because it actually runs and is fairly transparent brghtness wise.

CRT-Beam-Simulator has never worked properly for me. Maybe it’s because I always use HDR and regular BFI and hardware BFI darkens the screen a bit too much for my liking, especially if there are viable options, even if they might be slightly less effective.

#18

There’s already no brightness loss by design. so there’s no brightness left to gain :slight_smile:

Where traditional bfi are most effective in brightest scenes (white/black/white) and gradually less towards dark ones, this shader shifts the effectiveness to midtones to NOT sacrifice brightness.

I could flip even on top and odd on bottom, sure, but then the shader would have to be tuned really well by the user to not notice any tear in the middle. I can only see downsides.

I used my phone camera with 240p test suite scroll test at 120hz by moving it at the same speed of the scrolling objects and they were definitely more on focus.

Maybe you’re not that sensitive to motion induced blur?

Have you tried to follow the trees with your naked eye too? :slight_smile:

Thanks definitely a good advice, maybe I could ship a preset with it appended.

3 Likes
#19

For reference, i would recommend testing using the first level of Dynamite Headdy, taking particular note of the clarity of the text on signs. That said:

bfi-simple gives the greatest clarity boost, at the cost of the largest brightness reduction. Given my personal priorities (i daily drove an FW900 until i got my C1, in part for the motion clarity), location (a pitch black room), and goals (a perceptual equivalent to ~100 nits), i find the resulting brightness entirely acceptable.

RetroArch’s built-in BFI option, 120hz-safe-BFI, and 120hz-smart-BFI are all essentially variants on bfi-simple that don’t cause image retention on LCD displays.

I don’t personally think that crt-beam-simulator and variants like Shaderbeam are worth using on a 120hz display compared to the other options. On a 240hz+ display, as is the intended use case by it’s creators, i have every reason to expect it would be a much more compelling option, but at 120hz, it isn’t significantly brighter, and it introduces that dead center tearing @kokoko3k mentioned.

I think adaptive_strobe-koko is a far more compelling option if you are on a 120hz display, and you are willing to sacrifice some clarity in exchange for additional brightness, especially for slower paced games. But that definitely isn’t a trade i’m personally willing for make for faster paced titles.

3 Likes
#20

Maybe there is the need of a clarification:

Across the whole scale from black to white(/red/green/blue), both traditional BFI and my shader generate the exact same total oscillation amplitude.

Simple BFI total oscillation is the area of a right triangle:

    100%   o
       /|  s
      / |  c.
     /  |  
    /   |  
   /    |  
  /     |  
 --------
0      100% <--- input color

adaptive_strobe total oscillation is the area of a isosceles triangle:

    100%        o 
     /|\        s
    / | \       c.
   /  |  \
  /   |   \
 /    |    \
/     |     \
--------------
0    50%   100% <--- input color

The peak has just been shifted to the center, but both triangles have an ipotetic area (total oscillation) of 100*100/2=5000.

There is more motion blur in the second case when brightness is > 50% because it does not reach pure black, but on darker tones not only it reaches black, but the total oscillation is greater than a simple BFI.

Eg: Total oscillation and input color= 25%:

simple bfi: 0,25,0,25… = 25%

Adaptive strobe: 0,50,0,50… = 50%

To be totally honest, but this goes far over my knowledge, retina may be more “impacted” by the high peak signal of the oscillation, which in turn may lead to a reduced effectiveness.

2 Likes