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 
1 Like
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
Yet another parameter (upstream PR pending):
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.
The change has been just integrated in koko-aio too.
2 Likes
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 
2 Likes
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
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.
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.
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.
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
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?
@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
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.
There’s already no brightness loss by design. so there’s no brightness left to gain 
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?
Thanks definitely a good advice, maybe I could ship a preset with it appended.
3 Likes
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
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
Could you please verify this works with hdr?
I made a second preset named adaptive_strobe-koko-hdr_blasckscreen_workaround.slangp and inside it I appended a stock pass with the same metadata as the hdr-config.slangp
1 Like
It doesn’t solve the issue.
@kokoko3k I think this is the real fix here. No workaround is necessary. I would add that you don’t need to apppend the hdr-config.slangp. Instead you could append the hdr.slangp.
The hdr-config.slangp is used if you want to add the old style Sony Megatron HDR Peak and Paper White Brightness overrides to the Shader Parameters, while the hdr.slangp is used if you want to add HDR compatibility to any shader but use the settings in Settings–>Video–>HDR to control HDR output, including HDR Brightness, which is what @MajorPainTheCactus had in mind when he updated RetroArch and Sony Megatron Colour Video Monitor’s HDR implementation not too long ago.
Guess what? I’m able to double stack adaptive_strobe-koko with my display’s strobing BFI! so far I haven’t done any real objective testing except but the only downside I can see if the normal lower brightness I get when using the hardware based solution.
This is the issue:
These show the output after appending hdr-config.slangp or hdr.slangp. The darker shots are the dark frames being output from the adaptive-strobe-koko shader:
1 Like
I was trying to append an hdr.slangp with the intent to export it as a full preset to understand if it would work, but faced a blocking issue:
[ERROR] [Slang] Failed to open shader file: "/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/include\hdr10.h"
there are some backslashes:
grep -R include /home/koko/.config/retroarch/shaders/shaders_slang/ | grep \\\\
/home/koko/.config/retroarch/shaders/shaders_slang/bezel/Mega_Bezel/shaders/megatron/inverse_tonemap.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/bezel/Mega_Bezel/shaders/megatron/hdr10.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_inverse_tonemap_config.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_inverse_tonemap_config.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr10_v2_config.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/inverse_tonemap_v2.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/inverse_tonemap.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr10_v2.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_config.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_inverse_tonemap.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_inverse_tonemap.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr10.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/inverse_tonemap_v2_config.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/shader_deploy.py:INCLUDE_RE = re.compile(r'^\s*#include\s+"([^"]+)"')
…I think those will only compile under Windows.
1 Like
Any reason why I’m seeing these shaders in the Mega Bezel folder in the path?
The Mega Bezel version of Sony Megatron Colour Video Monitor is way behind the current version. How is it relevant?
Are you using a nightly build? Or stable?
MajorPainTheCactus made the “v2” HDR shaders such that they pull some of their settings from RetroArch’s settings, rather than making them entirely self contained, so they require a nightly build that includes those settings.
This does not work. Outputs a screen with scattered corrupted flickering artifacts.
1 Like