Rolling Scanline Simulation (future improvements)

[LibretroAdmin]

Inviting all stakeholders @MajorPainTheCactus @Ophidon @mdrejhon and others.

This is to discuss further improving the initial groundwork done in this PR - https://github.com/libretro/RetroArch/pull/16282

[Ophidon]

The current problem is that we don't -know- a good way to improve it that doesn't have fairly bad artifacting or other major issues of its own. I personally think the rolling scan feature as it is now, will scare people off BFI thinking it's an entirely useless/broken feature. But I didn't want to stand in the way of merging either, as it isn't my place, and as this code should not inhibit the existing full-frame BFI/shader sub-frame code paths from working as intended.

Some of the best things we know of, for the issues this feature has, are trying to hide the joint lines behind scanlines in CRT filters, and having some overlap between rolling scan sections with brightness adjustment which replaces some of the tearing problem with horizontal strips of less motion blur reduction. Which in and of itself is a pretty apparent visual artifact.

Also, a front-end solution like this wont be aware of what shaders are in use, and the screen resolution and Hz being used will also change where those rolling scan joint lines are in the image. Making trying to build front end code, or a shader specificially meant to be used in conjunction with this feature, need to account for a LOT of different joint line possibilities.

If anyone can provide a solution to where the artifacting is minimal enough to compete with the existing full-frame BFI that has zero inherent artifacting (other than strobing itself being a little annoying, obviously), I am all for it though. There are a few side benefits to the rolling scan method over full-frame BFI when/if it works well. This is where @mdrejhon would be very handy. :)

[hizzlekizzle]

For the record, I find a double ON to be much less obtrusive than a double OFF flicker.

[Ophidon]

Did you mean this response for my last reply on the previous PR regarding the 120hz bfi workaround?

[hizzlekizzle]

Yeah, I just put it here instead of there so we could close the lid on that one and continue discussion of improvements here.

[Ophidon]

A sub-frame shader solution (to that 120hz workaround) wouldn't be able to inject an 'extra' sub-frame like a driver solution could. But I still think it might be better to 'hide' a feature that is purposefully injecting noticeable annoying artifacting in a shader rather than as a front-end option.

So you'd maybe do something more like (100-0)-(100-0)-(50-50)-(0-100)-(0-100) style phase shift on a framecount%(adjustable number of how long you want between phase shifts). And keep in mind framecount intentionally doesn't increment on sub-frames, or sub-frames would mess with anything older that looks at framecount but isn't sub-frame aware.

The 50-50 transition frame might be a less noticeable/annoying transition than just a straight flip like 100-0-0-100? Trading some of the very noticeable change in instantaneous average brightness for some transient motion blur, still annoying but maybe a -little- less distracting.

[Roc-Y]

I don't know why this causes wide black bands in the shader I developed, but I think if the Rolling Scanline Simulation feature only handles the native resolution (e.g. 256*244), then my shader will behave normally.

[MajorPainTheCactus]

Hi Roc-Y I presume this only happens when rolling scan line is turned on?

On Fri, 16 Aug 2024, 17:42 Roc-Y, @.***> wrote:

I don't know why this causes wide black bands in the shader I developed, but I think if the Rolling Scanline Simulation feature only handles the native resolution (e.g. 256*244), then my shader will behave normally. 20240817_003458.jpg (view on web) https://github.com/user-attachments/assets/546e0f9c-5d53-4801-a4f1-ca496e18e89b

— Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/16373#issuecomment-2293824917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVKYGRTCSH6EVMKYMZTDUQDZRYTWLAVCNFSM6AAAAABE53OIC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJTHAZDIOJRG4 . You are receiving this because you were mentioned.Message ID: @.***>

[Roc-Y]

Hi Roc-Y I presume this only happens when rolling scan line is turned on? … On Fri, 16 Aug 2024, 17:42 Roc-Y, @.> wrote: I don't know why this causes wide black bands in the shader I developed, but I think if the Rolling Scanline Simulation feature only handles the native resolution (e.g. 256244), then my shader will behave normally. 20240817_003458.jpg (view on web) https://github.com/user-attachments/assets/546e0f9c-5d53-4801-a4f1-ca496e18e89b — Reply to this email directly, view it on GitHub <#16373 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVKYGRTCSH6EVMKYMZTDUQDZRYTWLAVCNFSM6AAAAABE53OIC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJTHAZDIOJRG4 . You are receiving this because you were mentioned.Message ID: **@.***>

There are no black lines after turning off the shader. It seems that as long as the resolution is enlarged in the shader, there will be black lines. It has nothing to do with whether it is a CRT shader.

[mdrejhon]

BTW, in fast horizontal scrolling, there can be tearing artifacts with rolling-scan. You need motion sufficiently fast (about 8 retropixels/frame or faster, which produces 2-pixel-offsets for 4-segment sharp-boundary rolling scan).

This is fixed via using alphablend overlaps. However, gamma-correcting the overlaps can be challenging so that all pixels emit the same number of photons is challenging. And to put fadebehind effects (so that a short-shutter photo of rolling scan looks more similar to a short-shutter photo of a CRT). And even LCD GtG distorts the alphablend overlaps. So alphablend overlaps works best on OLEDs of a known gamma (and doing gamma correction, and disabling ABL). For LCD, sharp-boundary rolling scan is better (and tolerating the tearing artifacts during fast platformers).

Then again using HDR ABL is wonderful, because you can convert SDR into HDR, and use the 25% window size to make rolling-scan strobe much brighter. This improves a lot if you use 8-segment rolling scan (60fps at 480Hz OLED) to reduce HDR window size per refresh cycle, allowing HDR OLED to have a much brighter picture during rolling BFI!

Also, I have a TestUFO version of rolling scan BFI under development that actually simulates the behavior of a CRT beam more accurately (including phosphor fadebehind effect). Related: https://github.com/libretro/RetroArch/issues/10757