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).
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.
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.
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)
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
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!
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.
I know this setting very well and I might only interfere with it for testing purposes because, I don’t only watch games, I play them and I’m an avid shmup, platformer and action game (like Ninja Gaiden) player, thus very sensitive to latency.
Disabling “Sync To Exact Content Refresh Rate” basically eliminated the issue in Street Fighter II Hyper Fighting using FBNeo even with Max Swap Chain Images set to 2.
I’ll do some more testing later but we could be onto something here. I still like Sync To Exact Content Refresh Rate for the improved latency performance it’s supposed to provide.
With it off you can use Frame Delay to help improve input lag perception by delaying the frame so that the animation frame renders closer in time to the input.
Which means that there can be some variance between frame readiness and input latency. With Sync To Exact Content Refresh Rate On, Frame Delay is not needed because the next frame is always ready when the input is triggered.
I know I butchered that explanation from memory but I learned about it years ago. I think @Tatsuya79 might be the one who explained it. Will have to relocate the post. I’m almost certain that @hunterk might know.
By the way, the images I posted above with the mostly flat lines with the blips were from the times when I enabled RTSS frame limiter at 120fps.
Going to look for that Frame Delay post now.
There should be another post about it but I can’t locate it at the moment.
It’s supposed to avoid the full latency of traditional Vsync. But in my experience, 120hz Vysnc + Auto Frame Delay already does this. I can dodge Round 3 Tyson uppercuts every try there. I can’t stand VRR’s flicker, it’s a future preview more than a feature to me. Even the darkest VA panels have it.
That’s truly unfortunate. Much like I was limited last week by my A/V Receiver. Which, when I bought it, I had presumed I was going GPU --> TV --> Receiver. Except it turns out only Sony will decode DTS formats. DTS:X has less audio compression than Dolby Atmos so the various Windows SFX that have distortion over Atmos don’t have distortion over DTS:X
Though, most of the games I’ve been playing (Resident Evil 7) require this to be in 7.1 or 5.1 mode. There’s still often times a movie or show encoded in DTS. Plus oddly iirc, even with 7.1 passthrough enabled, Windows kept disabling two of my speakers if I didn’t force it into Dolby Atmos. This limitation happens because Windows reads the EDID of the Z95B rather than listening to what I tell Windows to do. And … even if Dolby Atmos would work for those games where I need to select 7.1, Dolby Atmos also has two chunks of a few seconds dropout when any sounds start playing.
You can eliminate the first chunk of dropout (which DTS:X also has) by installing a small piece of software called SoundKeeper, but SoundKeeper doesn’t prevent the second Atmos dropout. Which means I will only turn on Dolby Atmos in the above screenshot when required for a game.
Better sound + less sound headaches > 144hz (or even 165hz) 4:2:2. I wonder if the Sony Bravia 8 II has the same 7.1 limitation without DTS:X/Dolby Atmos?? Google search says Yes.
This is true, even my Plasma accepted this 12 bit signal to enable its 36 bit color mode, but AFAIK no Kuro ever used anything other than 10 bit panels. I believe that’s both a future proofing option, and an acceptable signal that these displays can all downsample to 10 bit. 144hz at 48gbps is limited to 10 bit full 4:2:2, so no 12 bit there.
These are excellent questions! I think I can squeeze in a short test before work here. The most optimistic take away is that there’s some kind of script hiccup in the custom HDR pass you made. So I’ll see if I can’t get that flicker from your Shader chain in SDR. As you mentioned, you didn’t get the flicker in prepend. Neither did I, so that doesn’t help us move forward.
Thinking outside the box some, I pushed my SDR to something like 500/600 nits. (eyeing it comparative to HDR) Changed peak brightness to High, dialed Luminance up from 30 to 80 and swapped my color mode from Rec 709 to DCI-P3 to avoid using Blooming/Gamma Correct to brighten the image and wow. This is really close to the way it looks in 4:4:4 HDR…like 95% of the way there. I’m really surprised at how almost the same it is! I didn’t even set things as bright as I can.
Though because 4:2:2 atm had to drop Mask to 0.85 and get rid of the Preservatives.
Anyway…I was getting really bad flickers at first. Alt tabbed twice to get a resync, and then I couldn’t get them again. Repeated this process in HDR and I can’t get the flickers here after I alt tab either.
…ok any time I change something in the F1 menus, I have to re-alt tab 2x. Let me know if this helps at all for you.
Confirmed this is the same case as when I Append the current Adaptive Strobe shader. I have to Alt tab twice after.
Also figured you might benefit from knowing that disabling Frame Delays lets me not have to deal with flashing during the F1 menus.
Better to keep it and make it clearer it may be broken.
