New motion blur reduction ReShade shader - CRT Dusha

[Fluffy]

Hi everyone. I was looking for a good motion blur reduction ReShade shader, but couldn't find any good ones, so I have decided to make my own. It is simple to use, should work on different hardware and in different games, including old dx9 titles. Some basic presets are included, as well as many different options to play with.

Shader is on GitHub

https://github.com/Riskdiver/CRT-Dusha

Thanks

[mango87]

Interesting. How does the shader behave when there are frame drops?

[Fluffy]

It depends. Phosphor decay is based on frames. So, for smooth effect we need to sync fps with the monitor's refresh. Without VRR display frame drops will cause erratic flickering (since we're desyncing). With VRR G-Sync/Free-Sync, if you use standard methods like capping frames 3-5 bellow monitor's refresh (don't have to cap, the cap just allows us to stay within VRR windows without hitting v-sync, thus reduces input latency) with v-sync turned on, then shader just follows VRR sync during frame drops.

4 frames per decay is a nice long tail (1 bright and 3 darker frames) and is good for 144Hz onwards. If you use VRR, but frames dropping low, I would stick with 2 frames per decay (1 bright and 1 dark frames), this is the shortest possible decay for the motion blur reduction effect to work. With high decay speed (like max 25 for example) or more decay stages, you still get your very low image persistence. However, even with 2 frames per decay, I wouldn't go lower than 80-90 fps, you will start noticing flickering. Although, you can always reduce decay speed lower than default 1 and reduce flickering that way, all depends on your thresholds and perception of flickering.

With 1 frame per decay you don't get any decay tail, so no flickering at any fps/frame drops, but no motion blur reduction, can be used to fix/improve gamma, Voodoo2 emu, purely aesthetics.

I have 165Hz IPS Free-Sync and mostly play old games like Quake1/2/3, Unreal, etc., so no problems with frame drops, use default shader settings more or less, 4 frames per decay, low decay speed 1-3, brightness and contrast depending on the game. Capping to 160 fps/Hz + Free-Sync + V-Sync On.

You can use ShaderGlass overlay with ReShade and go through Blur Busters Tests or whatever games you play to tune the shader to you liking, finding the balance between motion clarity, flickering, brightness, etc. There are lots of possible combinations that would suite different conditions, panels, Hz, etc.

[Chief Blur Buster]

Hi everyone. I was looking for a good motion blur reduction ReShade shader, but couldn't find any good ones, so I have decided to make my own. It is simple to use, should work on different hardware and in different games, including old dx9 titles. Some basic presets are included, as well as many different options to play with.

Shader is on GitHub

https://github.com/Riskdiver/CRT-Dusha

Thanks

Fantastic! That's a really interesting shader with potentially significant improvements.

I'll port it to WebGL2 for TestUFO 3.0 and give you credit (link to your github and MIT license), they can contribute funds.
I might use a HLSL->WebGL2 compiler/converter approach, but we'll see how it works. This will give you probably 100x more publicity.

TestUFO 3.0 now supports shadertoys (I added a shadertoy compatibility layer to it) and the engine is being updated to support reshade HLSL->WebGL2 cross compiles soon, so the same CRT shadertoy now runs at TestUFO as https://beta.testufo.com/crt (much better than it does in shadertoy, thanks to TestUFO's better refresh-cycle framepacing engine than the shadertoy website).

I may make two changes:
(A) Add a splitscreen mode for comparison similiar to https://beta.testufo.com/crt ... I think I can instead use a compositor overlay for without modifying the code.
(B) Add LCD Saver mode for liability reasons. Some brands of LCDs take 100x longer to undo retention (days/weeks). This prevents complaints "My LcD MoNiToR Is DaMaGeD" from users (even though it's fixable given time) so gonna add that feature. It might be the brute "dup 1 refresh cycle every 15 seconds" unless you're able to add a Hz slew feature.

The Hz slew feature is nice and can be made unnoticeable when native:simulated Hz ratio is large enough (e.g. 4:1 and above), avoiding the integer divisor requirement. There are pros/cons tho.

But if you can add at least (B), that would be so great.

Then I may just be able to crosscompile HLSL->WebGL2 (simple reshade format fx files)

I submitted the LCD Saver suggestion to your github;
https://github.com/Riskdiver/CRT-Dusha/issues/2

[Fluffy]

Hi! Thanks! ReShade HLSL->WebGL2 cross compile sounds cool! Shader was a side project (took a few weeks of my main projects). Spent a week testing different LCD saver strategies, couldn't find a perfect solution and got tired But you are totally right, shader should probably have something inbuilt. It has an option to make decay tail uneven frames, breaking out of phase, but odd frames integration by the visual system is mediocre to say the least. Getting back to my main projects now, so a little restricted with time, but can probably add split screen, and some LCD saver functions.

[Chief Blur Buster]

Hi! Thanks! ReShade HLSL->WebGL2 cross compile sounds cool! Shader was a side project (took a few weeks of my main projects). Spent a week testing different LCD saver strategies, couldn't find a perfect solution and got tired But you are totally right, shader should probably have something inbuilt. It has an option to make decay tail uneven frames, breaking out of phase, but odd frames integration by the visual system is mediocre to say the least. Getting back to my main projects now, so a little restricted with time, but can probably add split screen, and some LCD saver functions.

Yeah I agree:

The non-integer divisibility can be problematic at low native:simulated Hz ratios like 60 Hz simulation at 144Hz.

But once you brute the ratio, e.g. 60 Hz simulation on 280 Hz, it's very temporal oversampled.

Much like how spatial scaling from 640x480 to 3840x2160 looks much better than scaling 640x480 to 800x600, you've got brute spatials to hide the scaling artifacts. The exact same happens with temporal scaling, which is why 60Hz CRT simulation looks fine at large native:simulated Hz ratios, like 4.5 or 7.5. It's simply scaling in the temporal dimension. You can test a 30Hz CRT at 165Hz, to see what I mean, at https://beta.testufo.com/crt to realize that large ratios can pretty much brute things out.

So now that you understand how bruting it in temporal dimension behaves similarly (less or unnoticeable artifacts) to spatial scaling; you should upgrade your shader to support floating-point count of subframes. That would make my life easier.

So, that is how I did LCD Saver in the CRT simulator. I discovered since I added non-integer divisibility, it actually was a fantastic solution for LCD Saver, because it was not as jarring as "drop a frame very X seconds".

Another method of "drop frame" is simply using two gamma-corrected frames -- a framedup but dim both frames (in a gamma corrected way) to prevent a flicker. Same technique for BFI -- like a dimframe insertion instead of black frame insertion. You'd simply framedup (repeat a frame twice, but proportionally dim both frames to preserve Talbot Plateau Theorem).

Good going you figured out how to make CRT simulator work on a Steam Deck! A GameScope hook by a shaderglass port, I gotta try it out.

___

About TestUFO upgrades to support Shadertoy/Reshade files:

Since I successfully wrote my own inhouse Shadertoy-to-TestUFO system that works with 99% of unmodified Shadertoys, I have been encouraged to do the same for Reshade filters -- it's trickier but since it's a very subset of HLSL, it should work with simpler things like the CRT simulator. So, therefore, Reshade-to-WebGL2 transpile approaches should work, so in theory I can use unmodified or mostly-unmodified reshade files. The settings will show up as TestUFO settings (sliders, combo boxes, etc). There may need to be 1 or 2 "#ifdef WEBGL2" but I may just regex the special cases out. We shall see.

This will give more publicity to open source display shaders. (Might help your Patreon too, though in my experience, ReShade authors are so niche). I notice you don't have donate-by-Patreon (only free subscription) so if you're seeking a bit of reimbursement, to make it a regular hobby, you might want to maybe add Blur Busters credit "Indirectly inspired by Blur Busters work at www.testufo.com/crt and their open source display initiative at www.blurbusters.com/open-source-display" to improve the Google SEO when I link. You don't have to, but credit is always appreciated and it gives you a bit of improved searchability even if it (quote)"competes"(quote) with the BlurBusters-developed versions of open source shaders.

Once 3 or 4 shaders are available Internet-wide, I'll add all of them (including yours) to a list of shader projects when I publish article #2 of the open source display shader initiative. I'm trying to grow it to a bigger critical mass so rising tide lifts all boats.

The more open source authors pull it off, the more we can convince the operating system vendors to make "refresh cycle hooks" an industry standard things. Replace those ASIC/FPGAs in display scalers with generic GPU video processors, that allow open source plugins! A cheap smartphone GPU is usually powerful enough to run a CRT simulator, as it doesn't even push the math limits of most modern GPUs, being just merely a single fullscreen texture.

That's kind of my "ulterier motive" -- adopt a new standard of "Bring Your Own Algorithm". In ten years, instead of having to depend on hardware-based blur reduction, we bring our own open source algorithms -- like install a Reshade subframe filter into a TV/monitor's own mini-GPU, and voila! Even if it's going to be years -- there will be incremental steps. Easier GameScope hooks. Easier Windows 12 hooks. Easier driver hooks. Etc. I'm trying to push this snowball where a sub-$50 GPU can be your displays' video processor. More powerful GPUs can run more filters at more multipasses, but for a simple single pass (or few) filters, you only need a low-end GPU for an optimized CRT simulator algorithm.

The other part of the battlefront is "Show the benefits in a single click". That's where TestUFO links come in. That's why I'm slowly upgrading TestUFO to support existing open source shaders. And you've seen my CRT simulator shadertoy is running in TestUFO unmodified, copy-paste direct from shadertoy. The bonus is you get to more easily promote your CRT simulator, simply by linking to TestUFO.

I'll (eventually) have a TestUFO page where you can "Upload" your ShaderToy.glsl or ReshadeFilter.fx text file (existing code) and you try it out in TestUFO. There's a bunch of unrelated contract work to do, but I'm spending a lot of my free time slowly upgrading TestUFO to this eventuality.

I feel it will take years before it is more popular but I'm definitely paving the internal groundwork by slowly upgrading TestUFO engine internally to support shadertoy compositing + reshade compositing. Under the hood, TestUFO 3.0 is over 100x times more powerful than TestUFO 1.0 (Still running at https://old.testufo.com for legacy Internet Explorer and old smartTV browsers!) so it has a lot of unannounced features that won't go live until TestUFO 4.0

As you can see, I'm counting down a space launch for the blastoff of TestUFO 3.0 spaceship in early November: viewtopic.php?t=15075

[Fluffy]

Much like how spatial scaling from 640x480 to 3840x2160 looks much better than scaling 640x480 to 800x600

Spatial is not equal temporal. Especially in terms of human visual sytem.

60Hz CRT simulation looks fine at large native:simulated Hz ratios, like 4.5 or 7.5

Uneven cycles will always look worse because of the neurological complexity of the visual system, you can't just 'brut force' it, so it looks exactly the same as even frames cycles

So now that you understand how bruting it in temporal dimension behaves similarly (less or unnoticeable artifacts) to spatial scaling; you should upgrade your shader to support floating-point count of subframes

No, I'm good thanks, I will stick to integers

I did LCD Saver in the CRT simulator

Slow Slew/Offset/Slow Phase walk will not work with the multistage exponential phosphor decay approach. Phase Jumps/Phase Flip/Frame Drop, will. Will add as an option for convenience.

Another method of "drop frame" is simply using two gamma-corrected frames -- a framedup but dim both frames (in a gamma corrected way) to prevent a flicker. Same technique for BFI -- like a dimframe insertion instead of black frame insertion. You'd simply framedup (repeat a frame twice, but proportionally dim both frames to preserve Talbot Plateau Theorem).

Same with this. My shader is not just a BFI shader, it involves complex decay curve. Repeating frames, blending, etc, will reduce quality of effect, the visual perception of smooth decay conveyor. But as LCD protection, something like frame drop, one tiny flick on phase flip once in a while is good enough.

Good going you figured out how to make CRT simulator work on a Steam Deck! A GameScope hook by a shaderglass port, I gotta try it out.

You don't need ShaderGlass, afaik no ShaderGlass port exists on Steam Deck. ShaderGlass is a windows app, that supports ReShade. For SD you need to use Reshadeck app which allows you to run fx shaders systemwide inside Gamescope.

About TestUFO upgrades to support Shadertoy/Reshade files:

Don't envy you, honestly. Market is driven by consumers. An average Joe doesn't know nothing about BFI, shaders, motion blur reduction, etc. He just needs his TV to show good image. Manufacturers tried BFI and seems to have failed. Feels less monitors/TVs are including it now then before. People got used to the blur, and younger generations don't even know what CRTs looked like or what image they have produced. Feels that the whole subject is stale today. Going more Hz way is fun, increasing refreshes each year to sell more monitors, but it is such a dumb way to solve the problem (if it is still a problem, that is). People are quite happy with 480Hz OLEDS/Mini-LEDs/etc. and G-sync/Free-Sync on top.

[Chief Blur Buster]

Phase Jumps/Phase Flip/Frame Drop, will. Will add as an option for convenience.

Yeah, just to cover our bases (users writing hate mail).
Even third parties: protect other open source authors...
Prevent people blaming Retroarch people, etc.

I also hated having to do this too, but I had to. That's the only "essential" change we need before I can help publicize.... Thank you!

I see you have a Patreon when you published this. As LCD Saver is definitely a boring reluctant "ugh, I hate doing this" type of task... Tell ya what -- I'll send you a donation of a couple dozen latte equivalents or $100 once you add any kind of simple LCD Saver mode. How's that? Sadly, it's a niche industry and most end users don't donate. People are much focussed on things with "long term dividends" (industry standardization etc).

(My ulterior motive: Encourage more people to do more work in open source display shaders. Publish sooner a "List of open source temporal display shaders" webpage as soon as enough people create enough shaders. Visible progress that helps convince industry to adopt shader-based temporal display processing hooks at OS/driver/display levels over long term.)

Albiet, preferably if it's a nice flicker-reduced one (e.g. dimmed frames during repeat), but I'd settle for a very abrupt frame-repeat to avoid making your shader too complicated. And a binary on/off ReShade flag for LCD Saver. Automatically turn an On flag anyway, if subframe count is an odd number.

Don't envy you, honestly. Market is driven by consumers. An average Joe doesn't know nothing about BFI, shaders, motion blur reduction, etc. He just needs his TV to show good image. Manufacturers tried BFI and seems to have failed. Feels less monitors/TVs are including it now then before. People got used to the blur, and younger generations don't even know what CRTs looked like or what image they have produced. Feels that the whole subject is stale today. Going more Hz way is fun, increasing refreshes each year to sell more monitors, but it is such a dumb way to solve the problem (if it is still a problem, that is). People are quite happy with 480Hz OLEDS/Mini-LEDs/etc. and G-sync/Free-Sync on top.

Totally agreed.

Even many new engineers at many display manufacturers started school long after CRTs became rare, so fewer display engineers understand blur reduction as well as they did in the past. You know, many 35 year old engineers at manufacturers, were already using LCDs in high school at age 15, and don't really understand CRT stuff as much. So the "general engineer knowledge" is falling, creating more and more substandard BFI implementations.

That's why I got frustrated at trying to do hardware solutions, and slowly migrating to the open source display approach.

I want to put display-processing algorithm control in users hands (like me & you).

Fantastic reply, except to clarify:

Much like how spatial scaling from 640x480 to 3840x2160 looks much better than scaling 640x480 to 800x600

Spatial is not equal temporal. Especially in terms of human visual sytem.

Correct, so I want to clarify what I meant since you probably accidentally misunderstood my specific point. So to avoid misunderstanding (focus on correct surgical scientific point), let me provide a better example than that.

It's important to understand the intent of the point I was making, because it's rooted in aliasing math & science:

"Small ratios = more visible artifacts"

This is true for both spatial scaling and temporal scaling. Like how scaling 640x480 to 650x490 look absolutely awful and looks much worse than scaling 640x480 to 4000x3000. You begin to notice major improvements at ~3-4:1 and above, and it diminishes to almost nothingness at ~8:1.

The artifacts of scaling is less noticeable with brute (large ratios).

Now you understand better the specific surgical point, as a specific nuance! That's why floating-point ratios don't create as noticeable artifacts when you're using large ratios (e.g. 75Hz CRT at 480Hz), than when you're using small ratios (e.g. 60Hz CRT at 144Hz).

Scientific Reproduction Instructions
Try different ratios on a 480Hz+ OLED, to see what I mean:
1. Use Sim Hz above your flicker fusion threshold
2. Use Native Hz many times higher than Sim Hz (6-8x higher)
3. You'll notice artifacts are much less noticeable (diminished) for non-integer divisors than smaller ratios (e.g. 2.4:1)
And I guarantee you'll agree with me if you do these scientific variables described in steps 1,2,3;

Please note, I'm talking about "Small ratios = more visible artifacts", not about other differences between temporal vs spatials. You are very correct but I was surgically focussing on the specific science point I was trying to make, of bigger oversampling ratios being better for both spatial and temporal (despite being for different reasons, the improvement statement is still true). Whether it's audio or visual, spatials or temporals, large oversampling ratios, helps improve quality by avoiding aliasing artifacts.

You need to be far beyond the Nyquist Sampling Theorem recommendation (2x) if doing nondivisibles, in order to avoid aliasing artifacts. Just like mathematically, in the aliasing sciences, you still see artifacts when scaling 640x480 to 1290x970 (slightly over 2:1), but if you scale 640x480 to 12900x9700 (slightly over 20:1), the artifacts of being slightly off is much less, since the off-by-scaling error is less than 5% (less than 1 parts in 20). Much less noticeable aliasing artifact and hidden in the tiny spatial aliasing (of scaling non-integer past 20:1 ratios) or temporal aliasing (of scaling non-integer past 20:1 time ratios). Yes, the human vision system reacts differently to spatials and temporals, BUT, the statement "Small ratios = more visible artifacts" is still real-money-bettably true.

In my tests on higher-Hz OLED using scientific variables listed in (1)(2)(3) above, the temporal artifacts really diminished at about ~4.x:1, dinished further at ~6.x:1, mostly disappeared at ~8.x:1, and even bigger ratios were even better.

It won't be 100% unnoticeable until ratios are large enough (e.g. simulating 60Hz CRT on 1000Hz OLED will make floating point ratios unnoticeable for 99% of 8bit era material -- I witnessed this already on prototype) -- but it can be unnoticeable in most content, if the gamma is set correctly (no visible banding).

Now that being said, I agree that integer divisible makes life much easier. Supporting non-integer is complicated. The nice thing is that shaders that support floating-point divisors, can also stay with integer ratios too -- you don't have to use non-integer ratios.

But yes, it's complicated and understandable to skip non-integer

I can't blame you for not wanting to do so. Stay with integer ratios if it makes software development much easier.

There's an advanced mathematical tweaks to do a supersampled exponential decay, but it highly complicates the math (veers into more advanced university maths such as Calculus). I can see it's much easier, when using your brilliant creative exponential decay -- to not complicate your work any further.

Calculus Solution for Non-integer Supersampled Exponential Decay

STEP #1: An easy "mental homework exercise": Metaphorically you pretend as if you are doing 100x refresh rate: You virtualize 100x+ refresh rate (render internal at 24,000 frames per second for a 240Hz display, that's twenty-four thousand offscreen subframes). Whereupon, you blend together 99 or 101 offscreen subframes (gamma-accurate averaging of frames) to create the visible presented subframes at your refresh rate. Voila! Success. You now have a successful slow slew at 1/100th refresh rate, for an exponential decay!

STEP #2: The tough part, essentially a difficult mathematical proof that a 4th year calculus teacher would assign you. Convert this math algorithm to calculus. Calculus can successfully merge the above into a nearly-single-pass math operation (so you only need to render 240 subframes for 240Hz), and give you infinite floating-point slew options.

Ouch. Complicated calculus math. Probably 3rd year university league or Masters Degree league. Boo.

I looked at your math and I don't see any easy algebraic solutions, so going non-integer complicates the math. Especially moreso at the refresh cycle overlaps (where you're doing decay of previous refresh cycle at bottom edge of screen, and decay of next refresh cycle at the top of the screen, all in the same subframe).

Optional stretch goal: The donation is raised to 250 dollars for non-integer support. I know, it doesn't come close to covering the software development hours. But I'm throwing this bone anyway, if you just merely happen to already be a Ph.D University Degree in Calculus. Sadly, I stay in the simpler algebra sandbox.

Sticking to Easy Algebra

I can't blame you for wanting to stick to integers -- no problem! It keeps the math to easier algebra!

I simply just want make clarifications to the specific surgical point I was trying to make about the oversampling and larger ratios creating a large noticeable visual improvement (the bigger the ratio, the better) -- and I've provided scientific variables where you can test-to-agree-with-me;

[BFI]

Chief, on the topic of LCD Saver, might it cause desync issues on the RT4K in framelock mode? Mine kept resyncing on my XG270, so I swapped to genlock and it's been fine. LCD Saver on 1 min, PureXP Ultra.

Shader looks great, Fluffy! I might never use it myself but appreciate your effort.

[Chief Blur Buster]

Chief, on the topic of LCD Saver, might it cause desync issues on the RT4K in framelock mode? Mine kept resyncing on my XG270, so I swapped to genlock and it's been fine. LCD Saver on 1 min, PureXP Ultra.

Shader looks great, Fluffy! I might never use it myself but appreciate your effort.

LCD Saver and Genlock doesn't affect each other.

The same LCD Saver is done in the browser-based version of CRT simulator. LCD Saver is digitally algorithmic with the slow Hz slew by using temporal scaling, with no effect on the video signal at all. So you won't have any genlock-related situations with that. I've got LCD Saver running in TestUFO at https://beta.testufo.com/crt -- Check it out.

but can probably add split screen, and some LCD saver functions.

Actually, I have a solution to that. I simply render 2 separate offscreen TestUFO motion tests concurrently and stitch/composite them together to create the splitscreen.

This makes it unnecessary to add splitscreen support to the shader itself, although it still means I have to try and duplicate the gamma.

It's cool demo to users to have a "comparision" tests is that the unprocessed motion scrolls onto the improved motion part, to allow users to witness the improvement. But I can simply do that as separate graphics and composite the result together. So, I think you can omit splitscreen for efficiency.

Phase Jumps/Phase Flip/Frame Drop, will. Will add as an option for convenience.

I noticed you just added this feature on github. Thank you!

I now owe you the $100 open source code bounty, that I promised you for LCD Saver.

(Note: The $250 Stretch Goal for non-divisibles, remains open, doable if you just happen to have a masters degree in math, or at least the more advanced math involved. I'll keep that bounty open for over 365 days from today thru Dec 31, 2026. I have no expectations you will take the stretch goal, but I leave the Stretch Goal open to you, as a courtesy)

How do you prefer to be paid?