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!
deama
Posts: 70
Joined: 07 Aug 2019, 12:00

Re: Using a reshade black frame insertion shader fx?

Post by deama » 24 Aug 2019, 10:06

Kheri wrote:Well, I haven't much luck with the program yet -- it just flickers like mad.

I did something like this to get it working on the primary display:
https://docs.microsoft.com/en-us/window ... terfromhdc

Code: Select all

	DISPLAY_DEVICE dd;
	memset(&dd, 0, sizeof(dd));
	dd.cb = sizeof dd;
	int i;
	for (i = 0; EnumDisplayDevicesA(NULL, i, &dd, 0); ++i) {
		if (dd.StateFlags & DISPLAY_DEVICE_PRIMARY_DEVICE) {
			break;
		}
	}

	oa.hDc = CreateDC(NULL, dd.DeviceName, NULL, NULL);
What are you supposed to do with that code?

Kheri
Posts: 59
Joined: 29 Sep 2018, 13:39

Re: Using a reshade black frame insertion shader fx?

Post by Kheri » 24 Aug 2019, 16:59

deama wrote: What are you supposed to do with that code?
That's just a code snippet I put into my own copy of the source code to get the program detecting my primary monitor; I have a multi-monitor setup. I didn't feel like putting it up on GitHub. I'm also not sure how good/appropriate of a solution it is.. I believe there are other ways to get the Device Context or Monitor ID. All of that code snippet replaces the single "oa.hDc = ..." line in the source code. (Then you would have to "Build" it into an executable, of course.) Hope that makes sense.

Edit: to be clear, the snippet is just for detecting the main monitor. I couldn't successfully run the previous executable because it was failing to do so. It doesn't prevent the monitor from flickering.

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

Re: Using a reshade black frame insertion shader fx?

Post by deama » 24 Aug 2019, 23:16

Kheri wrote:
deama wrote: What are you supposed to do with that code?
That's just a code snippet I put into my own copy of the source code to get the program detecting my primary monitor; I have a multi-monitor setup. I didn't feel like putting it up on GitHub. I'm also not sure how good/appropriate of a solution it is.. I believe there are other ways to get the Device Context or Monitor ID. All of that code snippet replaces the single "oa.hDc = ..." line in the source code. (Then you would have to "Build" it into an executable, of course.) Hope that makes sense.

Edit: to be clear, the snippet is just for detecting the main monitor. I couldn't successfully run the previous executable because it was failing to do so. It doesn't prevent the monitor from flickering.
Oh ok, I only got 1 monitor.

fuzun
Posts: 17
Joined: 20 Jan 2018, 21:18

Re: Using a reshade black frame insertion shader fx?

Post by fuzun » 30 Aug 2019, 19:55

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!
I think that this project is really interesting. This was something that I wanted to do in my free time.
I have tested it and in my computer it works quite good.

If you are interested, I have integrated my small and not very well coded "strobe" library into this project.
With it, this is now much more flexible. If you have 144hz monitor, now you can try [RENDER - BLACK - BLACK] sequence instead of classic [RENDER - BLACK] as R-B causes some color problems.

I suggest Render Mode: 2 or -2 for 144hz monitor. Note that even modes have advantages because they don't require algorithms to prevent image retention.

Source Code:
https://github.com/fuzun/desktopbfi

Binary:
https://github.com/fuzun/desktopbfi/releases/tag/v1.1

Usage:
desktopBFI.exe [Strobe Mode] [Phase Switch Interval in Seconds] [Debug Mode]

if you set debug mode = 1, this will show up:
Image

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

Re: Using a reshade black frame insertion shader fx?

Post by deama » 01 Sep 2019, 03:11

fuzun wrote:
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!
I think that this project is really interesting. This was something that I wanted to do in my free time.
I have tested it and in my computer it works quite good.

If you are interested, I have integrated my small and not very well coded "strobe" library into this project.
With it, this is now much more flexible. If you have 144hz monitor, now you can try [RENDER - BLACK - BLACK] sequence instead of classic [RENDER - BLACK] as R-B causes some color problems.

I suggest Render Mode: 2 or -2 for 144hz monitor. Note that even modes have advantages because they don't require algorithms to prevent image retention.

Source Code:
https://github.com/fuzun/desktopbfi

Binary:
https://github.com/fuzun/desktopbfi/releases/tag/v1.1

Usage:
desktopBFI.exe [Strobe Mode] [Phase Switch Interval in Seconds] [Debug Mode]

if you set debug mode = 1, this will show up:
Image
I tried it and I still get lots of flickering, what's going on? Is it something to do with my monitor or computer?
Here's a picture of the debug, it seems like it can't really reach 144fps? I tried setting the priority of the program to high but didn't really make a difference.
Image


EDIT: Hmm, ok, maybe not, I tried again with a -2 render mode this time and the fps was higher, but there was still a bunch of flickering:
Image

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

Re: Using a reshade black frame insertion shader fx?

Post by Chief Blur Buster » 04 Sep 2019, 23:19

One could also temporarily switch to the Performance plan temporarily while running this BFI module.

This can also be done programmatically (using API to switch to high performance mode) via the PowerGetActiveScheme() and PowerSetActiveScheme() to force the computer to 100% GPU. At least you'd notify the user of reduced accuracy if you're on the battery-miser power plan...

This will kill battery, but can dramatically increases BFI precision.

Also, you may have to also reconfigure the GPU separately in the GPU's control panel to disable GPU power management.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

EDIIIZ
Posts: 1
Joined: 17 Sep 2019, 16:51

Re: Using a reshade black frame insertion shader fx?

Post by EDIIIZ » 17 Sep 2019, 17:02

squeaksci wrote:Alright, I updated with Chief's polling suggestion, it fixed the flickering on my other computer, though I couldn't test any games on it. I hope it works! Same download link: https://github.com/squeaksci/desktopbfi/releases
Hey, just tried your programm with my already strobed display and the "motion blur" and "overdrive artifact" results are amazing. Ofcourse brightness and fluidity is trash.

I have the LG 24GL600F with a 144hz refresh.
The HW Blur reduction has alot of Strobe Crosstalk.
Your Software BFI has none but clarity isnt as good. Now when i combine Software BFI with Hardware BFI Clarity is perfect, Overdrive Artifacts are gone and Strobe Crosstalk is also gone. Can someone explain this? :D

Double Strobed (Software + Hardware + Highest Overdrive)
Image

Single Strobed (Hardware + Highest Overdrive)
Image

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

Re: Using a reshade black frame insertion shader fx?

Post by Chief Blur Buster » 19 Sep 2019, 15:34

EDIIIZ wrote:Your Software BFI has none but clarity isnt as good. Now when i combine Software BFI with Hardware BFI Clarity is perfect, Overdrive Artifacts are gone and Strobe Crosstalk is also gone. Can someone explain this? :D
Combining hardware and software strobing can be useful:

(1) The hardware strobing ensures that you've got sub-refresh persistence. (Software-only can only adjust persistence in refresh cycle increments).

(2) The software strobing can add a humongous emulated VBI between hardware-strobed refresh cycles. The black frames helps erase the previous frame quicker, allowing much cleaner GtG pixel response to a new refresh cycle.
Essentially, your software BFI is simply a 120Hz-to-60Hz hardware strobe converter. Your software BFI blocks every other hardware strobe

(3) It makes possible single-strobed 60Hz out of 120Hz hardware strobe backlights that have an arbitrary manufacturer firmware limitation against 60Hz single strobing (this is a design decision made by most manufacturers, due to not wanting to give 60Hz flicker for users).

Hardware BFI to generate 120Hz strobed, and software BFI to block every other strobe, to create 60Hz hardware strobed on a monitor that doesn't have hardware 60Hz strobing support.

This can be poor quality on some panels and higher quality on other panels (OLED and IPS LCD is very friendly to the hardware+software BFI combination).
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

Terryneitor
Posts: 6
Joined: 15 May 2020, 12:41

Re: Using a reshade black frame insertion shader fx?

Post by Terryneitor » 15 May 2020, 12:47

Chief Blur Buster wrote:
19 Sep 2019, 15:34
EDIIIZ wrote:Your Software BFI has none but clarity isnt as good. Now when i combine Software BFI with Hardware BFI Clarity is perfect, Overdrive Artifacts are gone and Strobe Crosstalk is also gone. Can someone explain this? :D
Combining hardware and software strobing can be useful:

(1) The hardware strobing ensures that you've got sub-refresh persistence. (Software-only can only adjust persistence in refresh cycle increments).

(2) The software strobing can add a humongous emulated VBI between hardware-strobed refresh cycles. The black frames helps erase the previous frame quicker, allowing much cleaner GtG pixel response to a new refresh cycle.
Essentially, your software BFI is simply a 120Hz-to-60Hz hardware strobe converter. Your software BFI blocks every other hardware strobe

(3) It makes possible single-strobed 60Hz out of 120Hz hardware strobe backlights that have an arbitrary manufacturer firmware limitation against 60Hz single strobing (this is a design decision made by most manufacturers, due to not wanting to give 60Hz flicker for users).

Hardware BFI to generate 120Hz strobed, and software BFI to block every other strobe, to create 60Hz hardware strobed on a monitor that doesn't have hardware 60Hz strobing support.

This can be poor quality on some panels and higher quality on other panels (OLED and IPS LCD is very friendly to the hardware+software BFI combination).
Do you think its posible to use RTSS to implement a software BFI? I Think the last version has some scriting functions now, doing it directly from RTSS would work on exclusive fullscreen with even v-sync off using scanline sync.

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

Re: Using a reshade black frame insertion shader fx?

Post by Chief Blur Buster » 15 May 2020, 12:51

Terryneitor wrote:
15 May 2020, 12:47
Do you think its posible to use RTSS to implement a software BFI? I Think the last version has some scriting functions now, doing it directly from RTSS would work on exclusive fullscreen with even v-sync off using scanline sync.
RTSS is a frame-level system, not a refresh-cycle-level system.

Comfortable BFI needs to be achieved at the refresh cycle level, not at the frame level.

Technically it may work okay if framerate=Hz guaranteed, but that's hard to do.

The other showstopper is that RTSS historically doesn't have a capability to generate multiple frames from a single frame (yet), because you would need two frames per frame (one visible frame, and one black frame).

Once there is GPU-shader-scripted refresh-cycle-level opreation into RTSS, capable of spawning multiple frames per frame, that will have fantastic applications for a lot of projects. There was a project that Blur Busters financed but it is currently in legal limbo. Nontheless, multiple vendors (RTSS and others) have already added features to frameworks that are indepedently gradually getting closer and closer to required goals -- scripting languages, GPU shader processing, etc.

For example, when refresh-cycle-level processing happens (independent of frame rate), then I can implement software-based overdrive lookup tables and other overdrive tricks to create software overdrive vastly superior to 90% of hardware-based overdrive. None of that wimpy 9x9, 17x17 or 33x33 LUTs found in cheap scalers/TCONs, but full 256x256 OD LUTs, done via a GPU shader. I have equipment capable of generating good ovedrive lookup tables for LCD panels.

This will force manufacturers to upgrade their overdrive firmwares which has stagnated for way too long, and I've seen crappy and suboptimal OD LUTs in current gaming monitors, as if they were simply recycling an OD LUT from a different panel.

LCDs are well on their way to 1000Hz in the next ten years, some of you have heard ASUS has roadmapped 1000Hz thanks to Blur Busters, and that sort of stuff requires kick-ass OD LUTs.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

Post Reply