Using a reshade black frame insertion shader fx?

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!
Post Reply
deama
Posts: 368
Joined: 07 Aug 2019, 12:00

Using a reshade black frame insertion shader fx?

Post by deama » 07 Aug 2019, 12:13

So I got ahold of a black frame insertion fx script from reshade, however running a game at 130-ish fps (I got a 144hz monitor) it flickers like crazy? What's the problem here? Shouldn't I not be able to see this at 130+fps/hz?

Here's a script btw:
https://github.com/BlueSkyDefender/Dept ... rnation.fx

Also, here's a video I just made to illustrate the problem more visually:
https://youtu.be/YeWrfiBbgSA

User avatar
RealNC
Site Admin
Posts: 3730
Joined: 24 Dec 2013, 18:32
Contact:

Re: Using a reshade black frame insertion shader fx?

Post by RealNC » 08 Aug 2019, 07:42

At 130FPS you need 260Hz for BFI. When you do BFI like this (as opposed to backlight strobing,) two output frames are needed for each input frame. So your FPS needs to be half of the monitor's refresh rate.

So when running the monitor at 144Hz, you need to keep the game at a perfect 72FPS. The only way this can reliably work is either through 1/2 vsync, or through RTSS 1/2 scanline sync and hoping the GPU can provide a good enough timing. Without a sync method at all, each unsynced frame will result in a flicker.

VRR (freesync/g-sync) should work too. In that case you can use 144Hz VRR mode and just use RTSS to cap to 72FPS.

In any event, the game needs to provide a perfectly solid 72FPS at all times, with no stutter or judder. Even the smallest stutter will result in a flicker.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

deama
Posts: 368
Joined: 07 Aug 2019, 12:00

Re: Using a reshade black frame insertion shader fx?

Post by deama » 08 Aug 2019, 11:46

Ah ok, I think I'm gonna have to find a different method or something, because the moment I cap the framerate to below 100 the flickering stops, though I don't think it's working because the screen doesn't look any dimmer, nor do I notice any motion blur reduction.

User avatar
RealNC
Site Admin
Posts: 3730
Joined: 24 Dec 2013, 18:32
Contact:

Re: Using a reshade black frame insertion shader fx?

Post by RealNC » 09 Aug 2019, 01:55

You should probably ask the person who wrote it how it's actually supposed to be used.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Using a reshade black frame insertion shader fx?

Post by Chief Blur Buster » 09 Aug 2019, 16:42

deama wrote:So I got ahold of a black frame insertion fx script from reshade, however running a game at 130-ish fps (I got a 144hz monitor) it flickers like crazy? What's the problem here? Shouldn't I not be able to see this at 130+fps/hz?
You need a refresh-cycle-level filter, rather than a frame-level filter, to prevent the erratic-flicker-effect of Reshade-based BFI.

BFI is great for niche purposes. It isn't intended to be anymore than a workaround/solution.
RealNC wrote:You should probably ask the person who wrote it how it's actually supposed to be used.
The BFI module is an interesting experiment but it has a fundamental flaw:

It's frame-based, not refresh-based

. Basically, proper BFI should be guaranteed at 72Hz for 144Hz, no matter what the underlying frame rate is. In this situation, any framerate drops will simply create double images (e.g. like 30fps at 60Hz) but that's less objectionable than an erratic flicker of a frame-based BFI.

Remember I was the world's first website to test 480Hz. http://www.blurbusters.com/480hz
Any BFI errors are visible even at 480Hz.
Even a single framedrop in BFI at 480Hz is visible.

TRUE, many artifacts are NOT visible at high frame rates, but this is one of those 'super sensitivity' behaviors. It's one of those "Milliseconds Matters" topics at Blur Busters (0.5ms vs 1.0ms GtG is human-visible, 0.5ms vs 1.0ms MPRT is human visible, 480Hz vs 1000Hz is human visible, etc -- For more reading, see http://www.blurbusters.com/1000hz-journey ...)

Flicker is a high-sensitivty threshold that even goes all the way to microseconds in some situations. Even a 10 microsecond erratic variance in a strobe backlight sometimes become human visible. So a 1.0ms strobe flash versus 1.01ms strobe flash is a 1% brightness difference. That's like RGB(252,252,252) versus RGB(255,255,255) -- that 1% brightness difference caused by 1% extra photons hitting your eyeballs because your strobe-length (MPRT) erratically varied by just a mere 10 microseconds (0.01ms). That was visible in a prototype monitor I had on my desk, and the firmware engineer had to clean up the interrupt scheduling and PWM logic so that such flicker stopped. Basically it randomly varied between 1.0ms strobe flash length and 1.01ms strobe flash length, approximately once a second. That looked like a faint candlelight flicker when displaying a full-screen Windows Notepad window.

While the human eye can't see the timing difference -- the average amount of photons is varying -- which your eye DOES see. If your eye captured more photons, things ARE going to look brighter, no matter how compressed the photons are (e.g. squeezed into a flash of a strobe backlight) -- this is one of those situations where flicker timing errors is easily seen. It's also why VRR strobing is an extremely hard to make comfortable (e.g. why the unofficial GSYNC+ULMB hack was never very popular). So any framerate errors heading into erratic BFI, creates a 1/144sec (6.9ms) flicker.

No shit sherlock, I can see flicker errors as small as 0.01ms -- your error BFI error is 690 times bigger whenever there's a framedrop during frame-based BFI. http://www.testufo.com/blackframes -- do something like drag a browser window, or interrupt the BFI to make it run 143fps (71fps) temporarily instead of 144fps (72fps) -- that flicker will become visible.

Anyway, this is getting off a tangent, but the point is flicker falls very deeply into the "Millisecond Matters" sphere -- practically all the way to "Microseconds Made Human Visible".

TL;DR: BFI should ideally be done at the refresh cycle level, not at the frame level.
TL;DR2: It requires developing a window virtual display driver
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

deama
Posts: 368
Joined: 07 Aug 2019, 12:00

Re: Using a reshade black frame insertion shader fx?

Post by deama » 10 Aug 2019, 10:08

Chief Blur Buster wrote:
deama wrote:So I got ahold of a black frame insertion fx script from reshade, however running a game at 130-ish fps (I got a 144hz monitor) it flickers like crazy? What's the problem here? Shouldn't I not be able to see this at 130+fps/hz?
You need a refresh-cycle-level filter, rather than a frame-level filter, to prevent the erratic-flicker-effect of Reshade-based BFI.

BFI is great for niche purposes. It isn't intended to be anymore than a workaround/solution.
RealNC wrote:You should probably ask the person who wrote it how it's actually supposed to be used.
The BFI module is an interesting experiment but it has a fundamental flaw:

It's frame-based, not refresh-based

. Basically, proper BFI should be guaranteed at 72Hz for 144Hz, no matter what the underlying frame rate is. In this situation, any framerate drops will simply create double images (e.g. like 30fps at 60Hz) but that's less objectionable than an erratic flicker of a frame-based BFI.

Remember I was the world's first website to test 480Hz. http://www.blurbusters.com/480hz
Any BFI errors are visible even at 480Hz.
Even a single framedrop in BFI at 480Hz is visible.

TRUE, many artifacts are NOT visible at high frame rates, but this is one of those 'super sensitivity' behaviors. It's one of those "Milliseconds Matters" topics at Blur Busters (0.5ms vs 1.0ms GtG is human-visible, 0.5ms vs 1.0ms MPRT is human visible, 480Hz vs 1000Hz is human visible, etc -- For more reading, see http://www.blurbusters.com/1000hz-journey ...)

Flicker is a high-sensitivty threshold that even goes all the way to microseconds in some situations. Even a 10 microsecond erratic variance in a strobe backlight sometimes become human visible. So a 1.0ms strobe flash versus 1.01ms strobe flash is a 1% brightness difference. That's like RGB(252,252,252) versus RGB(255,255,255) -- that 1% brightness difference caused by 1% extra photons hitting your eyeballs because your strobe-length (MPRT) erratically varied by just a mere 10 microseconds (0.01ms). That was visible in a prototype monitor I had on my desk, and the firmware engineer had to clean up the interrupt scheduling and PWM logic so that such flicker stopped. Basically it randomly varied between 1.0ms strobe flash length and 1.01ms strobe flash length, approximately once a second. That looked like a faint candlelight flicker when displaying a full-screen Windows Notepad window.

While the human eye can't see the timing difference -- the average amount of photons is varying -- which your eye DOES see. If your eye captured more photons, things ARE going to look brighter, no matter how compressed the photons are (e.g. squeezed into a flash of a strobe backlight) -- this is one of those situations where flicker timing errors is easily seen. It's also why VRR strobing is an extremely hard to make comfortable (e.g. why the unofficial GSYNC+ULMB hack was never very popular). So any framerate errors heading into erratic BFI, creates a 1/144sec (6.9ms) flicker.

No shit sherlock, I can see flicker errors as small as 0.01ms -- your error BFI error is 690 times bigger whenever there's a framedrop during frame-based BFI. http://www.testufo.com/blackframes -- do something like drag a browser window, or interrupt the BFI to make it run 143fps (71fps) temporarily instead of 144fps (72fps) -- that flicker will become visible.

Anyway, this is getting off a tangent, but the point is flicker falls very deeply into the "Millisecond Matters" sphere -- practically all the way to "Microseconds Made Human Visible".

TL;DR: BFI should ideally be done at the refresh cycle level, not at the frame level.
TL;DR2: It requires developing a window virtual display driver
Oh, that's interesting. Do you happen to know of any software or something along those lines that implements hz based BFI instead of frame based?

squeaksci
Posts: 6
Joined: 19 Aug 2019, 12:04

Re: Using a reshade black frame insertion shader fx?

Post by squeaksci » 19 Aug 2019, 12:27

deama wrote:Oh, that's interesting. Do you happen to know of any software or something along those lines that implements hz based BFI instead of frame based?
A few days ago, I learned about BFI in Retroarch and fell in love, but also can't find any software to get BFI elsewhere. I have an idea though - I figure it should be possible to write a simple program that just draws a black frame to the Windows desktop at half refresh. It wouldn't work for fullscreen-only applications, but windowed-fullscreen would, and that's good enough for me. Any game or video with FPS between half refresh and full refresh should work well, though limiting FPS to half refresh would look best.
I'm not a very experienced coder, but I'm confident I can figure that out. If I can, I'll post source + download on github and let you know. If I fail and give up, I'll let you know too.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Using a reshade black frame insertion shader fx?

Post by Chief Blur Buster » 19 Aug 2019, 13:35

deama wrote:Oh, that's interesting. Do you happen to know of any software or something along those lines that implements hz based BFI instead of frame based?
Software exists but is not currently publicly available.
squeaksci wrote:I have an idea though - I figure it should be possible to write a simple program that just draws a black frame to the Windows desktop at half refresh.
That is one workable technique.

Another more-universal technique is a virtualized display driver (which adds a simulated 60Hz or 72Hz monitor to the Windows Displays) -- that will work with full screen exclusive games. I've publicly written about this before elsewhere about virtual display drivers for BFI.

I support any open-source project initiatives on this, as such a virtual display driver can do a lot of wonderful things (e.g. software-based overdrive, software-based BFI, software-based Hz-critical operations), and a software driver can do simulated VRR like http://www.testufo.com/vrr .... Imagine doing VRR emulation on a fixed-Hz monitor using my TestUFO VRR algorithm as an example.

Overdrive and BFI have been done on a frame-based manner but that's the wrong way to go about things. Many things (software overdrive, software VRR, software BFI, etc) require refresh-granularity operations, and will NOT work with reshade-style frame-granularity operations.

For example, software overdrive only works on the first refresh cycle of a frame. Software overdrive shaders should only be applied to the first refresh cycle of a new frame. Otherwise it artifacts badly during framedrops. I'd love to get 480Hz overdrive running on my 480Hz Zisworks display, and I have already done offline software-overdrive tests and it actually improved 480Hz even further.

As many of us already know, software BFI is simply a band-aid for LCD motion blur, but it is something quite useful of a band-aid as you've already noticed. Sometimes we have to goad our displays into doing things they were originally not designed for. However, this band-aid works best at refresh-granularity and NOT frame-granularity.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

squeaksci
Posts: 6
Joined: 19 Aug 2019, 12:04

Re: Using a reshade black frame insertion shader fx?

Post by squeaksci » 21 Aug 2019, 12:06

I got it to work! It's a tiny C++ program, if you want to compile it, it uses the Windows Driver Kit for a v-sync function.
Github page: https://github.com/squeaksci/desktopbfi
Download, if you're comfortable running a program from a stranger: https://github.com/squeaksci/desktopbfi/releases
Problems are likely, I'm not a great programmer. Let me know how it goes!

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Using a reshade black frame insertion shader fx?

Post by Chief Blur Buster » 21 Aug 2019, 15:57

squeaksci wrote:I got it to work! It's a tiny C++ program, if you want to compile it, it uses the Windows Driver Kit for a v-sync function.
Github page: https://github.com/squeaksci/desktopbfi
Download, if you're comfortable running a program from a stranger: https://github.com/squeaksci/desktopbfi/releases
Problems are likely, I'm not a great programmer. Let me know how it goes!
Still -- excellent work which I would award an "A" grade for:

-- You accomplished this in only 1 day work. even figured out the blanking interval event.
-- You even figured out THREAD_PRIORITY_TIME_CRITICAL, which was necessary to solve most of the random-flicker problem.
-- You even figured out the need to wait until VBlank is exited (Sleep 2) to reduce those random-flickers.
-- I see you accomplish this by displaying a foreground window that you alternate transparency on every refresh cycle. This is a simpler method and works with all windowed applications (including emulators).

Suggestion: A potential improvement would be to use D3DKMTGetScanLine() right after D3DKMTWaitForVerticalBlankEvent(), and poll once every 0.1ms until VBlank is exited (VBlank = false). That will make the Sleep(2) unnecessary since sometimes a VBlank is bigger than 2ms, and sometimes a VBlank is smaller than 2ms. People who use Large Vertical Totals, will use VBIs bigger.

Advanced stuff: Also, for some panels that has image retention behaviours with software BFI (an unexpected interaction with LCD voltage inversion), you need to insert an occasional repeat-frame every, say few seconds to a minute or so, to swap polarities to balance things out. To reduce visible flicker of that swap-phase moment, you can use a gamma-corrected transparency (50% by linear brightness), e.g. two 50% refresh (50%:50%:0%) cycles for that extra frame moment (3-cycle phase) instead of one 100% refresh cycle (100%:0%). You know if your LCD has image retention if you try http://www.testufo.com/flicker and then move window around every 15 seconds to see image retention effects. Not all panels are prone to this though, some panels are immune.

The amount of time that .INVBlank=true will be equal to (Vertical Resolution / Vertical Total)ths of (1/Hz)second. However, it is tantamount to a busyloop, and will increase CPU. Though busyloops are often required in PC-based beam racing operations (e.g. RTSS Scanline Sync, or beam raced VSYNC in emulators, etc). On the other hand, the Sleep(2) can be pre-empted by other high-prioroity software, though it may stay relatively accurate because of your use of real-time priority.

Doing it as a virtualized monitor driver (creating a driver that creates a virtual 60Hz monitor that outputs to the real 120Hz monitor) is the superior method but is more than 10x+ more complicated than this. For anyone doing such drivers, one of my very huge important programming timesaver tip is to always use Full Screen Exclusive Mode, especially when emulating a virtualized monitor at a different Hz than the real-monitor. This helps bypasses the refresh-rate interference problem between monitors which can affect multimonitor users, and also will affect this situation too (one real monitor & one virtual monitor outputting to the real monitor). Then the virtualized monitor driver works with all applications, regardless of windowed, borderless or FSE.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply