I think you should read up rather than rely on my 3rd party accounts. It’s not that many posts so not a long read and I think the enlightenment might help eliminate at least some speculation as to what might be going on and why.
1 Like
There were a bunch of shader black screen bugs that got fixed across the various renderers (mostly vulkan), so this is likely.
1.22.2 stable doesn’t have the HDR “v2” updates, or a bunch of vulkan fixes, so i imagine it’s a conflict with of those updates or fixes.
2 Likes
I’ve noticed the dips more frequently now since trying the appended version. It’s actually pretty bad because every few seconds there’s a flash/flicker of a brighter frame that you can see and it shows up as a dip in the framerate in RTSS.
The severity and frequency varies depending on the game and the Core though.
On another note, as a new user of Sub-Frames, can I also enable Sync to Content Refresh Rate? If not, can I safely enable Automatic Frame Delay?
For the former, I don’t know, but the latter should not pose any problem.
…indeed, at 4k is overkill, expecially since it seems the way hdr will be implemented requires another full viewport pass (hdr-xxx.slangp)
1 Like
Okay, let me rephrase my statement. Instead of “It’s actually pretty bad.”, it’s more like sometimes it can get pretty bad or even occasionally. Depending on the load it can be regular but not necessarily frequent. The real issue is its noticeable and so breaks immersion. I don’t think I had seen this happening with the Adaptive-Strobe-Koko shader prepended.
Yes, I use the defaults on an LCD so image anti-image-retention is active.
I understood, it’ìs clear, the gpu can’t keep up, and misses a frame here and there; expecially considering that subframes are rendered as normal frames if the shader doesn’t optimize that somehow by showing the previous frame instead of calculating it from scratch.
Since adaptive-strobe is very simple, if you’re interested, maybe @guest.r could incorporate it into the last .slang used so that at least you don’t have to waste viewport passes.
koko-aio optionally supports that via plugins (yet to be released as stable, but it’s on dev version, and can additionally optimize subframes by skipping redundant calculations on subframes).
2 Likes
Hmmm…currently I’m appending Phosphor Persistence after CRT-Guest-Advanced-NTSC, then Adaptive-Strobe-Koko, then hdr.slangp.
Is there another way that this could you done seeing that there’s a shader between Adaptive-Strobe-Koko and CRT-Guest-Advanced-NTSC?
At some point, I would like to learn how to incorporate/integrate shaders into less passes as well as remove already integrated shaders which might have redundant features.
Appending (or prepending most of the times to a lesser extent) will be always heavier than inserting the code inside the same pass; and unfortunately there is not a third option.
1 Like
To be honest, I think the shader stacks used in my last 2 Shader Preset Packs (Epic and Legendary) are some great candidates for full optimization and integration.
They could be very useful for the Retro Gaming community.
By the way @kokoko3k, I’ve made some changes to the case of some of the letters in the folder names from Shaders to shaders and Shaders_Slang to shaders_slang. Feel free to take the latest version of my CyberLab Guest Legendary 4K HDR Preset Pack for a spin to see if it now works on Linux out of the box.
I think things will get easier once the new HDR changes get into stable. When I wrote the HDR guide it was with the new functionality in mind, not what’s in stable:
https://docs.libretro.com/development/shader/slang-shaders/#hdr-programming
2 Likes
Okay, let’s take this outside.
If you’re averse to keeping the experimental “Only Apply To Moving Areas” feature, instead of removing it completely from Adaptive-Strobe-koko, why not split it and spin off the “Only Apply To Moving Areas” and the “simpler approach” into their own shaders?
For me, any improvement to motion clarity should be welcomed and explored, especially using novel techniques.
I’m reserved to not using the full screen simpler approach because so far I’ve been getting the odd bright screen flickering, which is distracting for me. I’m also not willing to sacrifice Sync To Content Refresh Rate, even if that might be contributing to the flickering, even though I don’t think that’s what’s at fault or at least completely at fault.
In addition to that, I rather prefer the seamless of pausing the emulation and not having to deal with the visible flicker of the simpler full screen approach.
So you can let me know what you think.
If you do leave the functions integrated as they are now, it would continue to make for a much more elegant solution on the preset side in terms of being able to use the same preset and just switch the option on or off depending on user preference, system capabilities or for game compatibility reasons.
The thing that causes non stop flicker, not willing to test without it?? o.O Or, the hopeful reality, you tested a bunch with VRR disabled just to make sure that wasn’t the cause?
Did you do The Lion King test with the green leafs at the bottom of the level? Just want to make sure it wasn’t just me. When in 120hz, set that joint to 1 and run back and forth. Feels like the motion blur is just as bad without the shader. Disable that joint so it’s full screen adaptive strobe, and then run back and forth again. That’s when it’s really clean for me.
Shouldn’t the background moving as we run right/left count as Moving Areas or am I confused? This area is a great place to test motion clarity in general because it’s really obvious when it’s blurry vs. clear.
Don’t misunderstand me. I’ve already tested and have been testing many different scenarios up to this point from when I started using adaptve-strobe-koko some weeks ago. So a lot of what I’m saying comes from what I’ve already observed and have moved on from. Not everything has been documented which is why I would leave a bit of doubt concerning anything I have said pending further retesting, verification and confirmation. So it’s not necessarily Sync To Exact Content that is causing the random flicker, how do I know? Because I tested it both with and without Sync To Content Refresh Rate and I’m certain that both options exhibited the same anomaly from time ti time. One may or may not have been worse but that would need further testing to verify, however just once is too much so that is unnecessary.
When I’m testing I might initially rough test many different variables and scenarios at lightning speed, observe then retest anything suspicious more thourougly.
There is no non-stop flicker with any option on my side though, only ocassionally. I’m not sure if you were talking about your case.
Me not being willing to sacrifice or give up Sync To Content Refresh Rate doesn’t mean I’m not willing to disable it temporarily in order to test something or get something to work.
Memory can be unreliable though, sometimes short term or long term so at some point I will be revisiting and retesting adaptive-strobe-koko even with “Only Apply To Moving Areas” on or off on the various games and systems I play. It’s very possible that with some settings combinations, or some games or some cores there wasn’t any occasional bright screen flicker.
At that round of testing, I was merely trying to get some sort of subframe BFI solution to work. Now that that’s over and I’ve settled on my RetroArch settings and on adaptive-strobe-koko, another round of testing begins.
The only constant flicker I noticed would be when in the RetroArch menu when the “Only Apply To Moving Areas is Off” and emulation is paused.
As far as when I noticed the occasional flicker, I think it was after I started trying to append the shader rather than prepending it, which is what I ws doing initially. It may be possible that some flicker was noticed with the prepended version subsequently but I can’t say for sure so that might have to be retested, however since I’m not returning to the prepended version, so that might only be for academic purposes.
What is true so far for me is that the “Only Apply To Moving Areas” option has been pretty stable for me, so I’ve implemented it as the baseline behaviour on all of my new presets which use adaptive-strobe-koko. Over time I will revisit testing with the option off to see if there might be any scenarios, where I don’t get the occasional bright screen flicker on my hardware setup. That doesn’t necessarily mean I’ll be leaving it disbled in my presets though since I don’t like the flickering when in the Menu. Time will tell though.
Other observations so far are a corresponding dip in framerate (confirmed by my RTSS framerate graph) when the flicker occurs. I’ve already mentioned and discussed this with @kokoko3k.
Not yet, which version/platform/region?
During my initial experimenting to get things setup correctly, I would have observed some animation anomolies with the option set to 1 but that was probably before things were setup correctly and I don’t notice any anomolies or artificats currently. So it’s now my “daily driver” settings, however, it’s still early days still. I have been spending some time optimizing my shader chain as well as trying to get support added for additional mask layouts e.t.c.
I have some other ideas in mind but I’m now ready to test my current shader stack some more, including the performance of adaprive-strobe-koko, (of course when time permits me).
1 Like
I feel you there. Just wanted to make sure the post-Append adjustment was indeed tested with VRR settings disabled both in RA/display since it causes that kind of thing. I believe you communicated a clear Yes you tried that.
the Genesis version, I don’t really touch the Super NES version anymore. The wild thing for me is that like, with Moving Objects set to 1 Pride Rock will flicker at 60hz while giving no added motion clarity on the green leafs as I run from side to side along the bottom of the stage, but Pride Rock will NOT flicker with it set to 0 while the shader adds a clear boost in Motion Clarity everywhere.
I think it’s quite amazing it adds such motion clarity at 60hz too.
1 Like
Oh great, well I just tested the SNES version using 3 different cores because the result was poor frame pacing all around in general. What was even weirder was that when I paused the emulation and I attempted to advance the frames one by one using the K key, the framerate dropped down to 0 and the frametimes climed to thousands of milliseconds. This happened on BSNES, SNES9x and Messen-S. The only thing that improved this was disabling Sync To Content Refresh. I guess it makes sense that it would drop to zero since the content refresh rate is effectively 0 when it’s paused but that was weird.
A picture or video paints a thousand words, if I had some visual cues, I might not have wasted time testing the SNES version.
1 Like
OK, my apologies @Cyber I had Shader Sub-frames enabled in my Sync settings and that was forcing 120hz even though I had selected 59hz. So my tests were at 120hz Appended.
(My original post explicitly said the Sega version, but I apologize for not being clear in my second post as well x.x)
De nada, I make mistakes like that all the time.
Dais small t’ing.
Okay, I tested the Genesis version. I got the same framerate drop when I paused the emulation with the K key however, the proper adaptive-strobe-koko cadence of dark and light frames was observed then K was pressed, unlike on the SNES version with 3 different cores.
Sync To Content Framerate was untouched and enabled for my Genesis version tests. In general the game exhibits poor frame pacing on both platforms which can be seen by slightly choppy scrolling sometimes in the rocks in the first level. Genesis version plays smoother and faster.
With “Only Apply To Moving Areas” enabled, the tips of the grass tended to blur or exhibit a sort of transparency effect when scrolling. With it off it was noticeably clearer and sharper, however I could notice the occasional bright frame flicker.
Although “Only Apply To Moving Areas” was not as smooth/clear, at least in the background I didn’t notice anything that was jarring or unexpected.
This was a great test to see if the simpler full screen method was working properly though. It definitely is. If only I could get rid of that occasional bright frame flicker, I might opt for that option despite the flickering during pause because it can be seen how much it improved things.
I only tested at 120Hz by the way, although with some cores (and or settings combinations) the game fps remains at 60fps, while others display 120Hz.
So I will continue to test. Why do you use 60Hz, instead of 120Hz? Especially with BFI/Subframes available and with one of the brightest 120Hz capable OLED TV’s on the market?
What’s your output device if you don’t mind me asking?
By the way, this was the first real test of my modified version of adaptive-strobe-koko-plus-hdr plus some more crazy optimizations that I had been working on over the last few days. It proves that it works!
When testing the SNES version, when I saw the crazy behaviour, I resorted to stock adaptive-strobe-koko and hdr, but it made no difference.
By the way, phosphor-persistence was enabled for all of my testing. I tried adjusting it to lower the blur/blending taking place on the tips of the grass and the edges of the rocks when moving but it didn’t seem to change anything. I also have a tiny bit of AfterGlow enabled.
Regardless of those settings, with “Only Apply To Moving Areas” off the tips of the blades of grass were clearer.
I’m noticing it with your shader preset too. But not mine in SDR (to get around the HDR barrier). I won’t be able to test more fur a phew days so I’ll get back to this probably closer to next weekend.
Output device as in?? I saw multiple posts referencing 60hz so I wanted to test that. Actually the phosphor persistence makes the flickering in 60hz so much better. Not that you would want to use 60hz regardless. lol
1 Like
What’s your source device hooked up to your TV thst you use to run RetroArch? What GPU? I’m tryin to understand why you’re stuck using 60Hz refresh rate.
There must be a better way to do this than not being able to use HDR on one of the best and brightest OLED Displays in HDR mode ever created. You’ve probably just haven’t figured it out yet.
You’re noticing the rndom bright flickers, that’s good, so it’s not only me. Do you notice them if you run my shader presets in SDR mode? Do you notice them if you run your shader in HDR mode? What is your shader?
This improved sprite flicker performance is one of the best things I’ve experienced in the CRT emulation world in a long time. It has nothing to do with subframes or high refresh rates. That is only for subframe BFI methodsso 60Hz or whatever the content refresh should be optimal for seeing the best performance out of phoaphor-persistence. Thanks to @Jobima for highlighting this one.
According to @kokoko3k and my RTSS graph, the bright flicker is directly related to a dip in framerate and frametime performance, aka frame pacing related. I’m not sure what else to try but better performing hardware.
Also, I’m not fully entrenched in 120Hz land as I’m limited to YCbCr 4:2:2 by my GPU so that means not all mask types will look good so 60Hz is still an option for me to use which will give me the best colour output from my display at RGB 4:4:4 10 bit Full. My display even reportd that it can go up to 12 bit at that resolution but I believe the panel is native 10bit.
My display also supports up to 144Hz at 4K but 240Hz at 1080p, so I can definitely do some experiments using 240p or 180Hz with adaptive-strobe-koko and other BFI solutions including my display’s buit-in strobing hardware BFI!
1 Like
I don’t think it deserves a split either 
Better to keep it and make it clearer it may be broken.
Full screen Bfi shaders are very sensitive to frame pacing issues; one single frame spike, one full screen glitch. But avoiding full screen adaptive strobe in favour of applying it to moving area only, means hiding the real problem (which I don’t know what it is anyway); root cause needs to be found.
I’d rather prefer to prepend the full screen one , as I think it woyld be more effective anyway.
Entirely possible, depending on the scrolling speed and pattern!
I’d expect motion clarity improvements in scenes with more solid backgrund and isolated sprites, Eg. 240p test suite scroll test.
Fliclering is what makes bfi effective; less source flickering means less motion clarity. (Increasing hz does not lower flickering, it just makes it less noticeable to the eye), so if you activate persistance after the strobe, you’re basically lowering the strobe effect, motion claritiy improvements and flickering.
@cyber, there’s a vulkan driver setting that trades latency versus frame pacing called max swapchain images (video/synchronization), try to make it higher.
1 Like