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!
thatoneguy
Posts: 93
Joined: 06 Aug 2015, 17:16

Re: Using a reshade black frame insertion shader fx?

Post by thatoneguy » 27 Jul 2021, 08:16

mynm wrote:
07 Jul 2021, 11:57

Do you have tested to use something like an interlaced resolution?. Maybe the flickering will be lower as not all the lines where black.
I had tested some years ago an interlaced 50Hz CRT TV and a CRT monitor at 50Hz. While the TV was usable for gaming with a PS2 without flickering, for example GT4 was perfect in motion, the monitor was impossible to be use cause of the flickering and it was needing around 85Hz to be used without a noticeable flickering.
That's probably because the TV has longer persistence phosphor(which means the phosphor shines for a longer period meaning more motion blur but less flicker) whereas most CRT Monitors use short persistence phosphor which means less persistence blur but more flickering.

mynm
Posts: 12
Joined: 23 May 2015, 06:36

Re: Using a reshade black frame insertion shader fx?

Post by mynm » 28 Jul 2021, 13:08

Chief Blur Buster wrote:
26 Jul 2021, 00:19

For those unaware, read Image retention issues on certain panels from software-based BFI algorithms.

There are solutions for this; it's simply re-exercising the display with regular content (giving it a rest from software BFI).

Does not affect all panels, and doing odd-divisible cadences will make it immune (e.g. 60Hz BFI during 180Hz), unless adding a phase-swap BFI.

The source code to all BFI algorithms should have anti-burn-in algorithms added to it.
Thanks for the info.
thatoneguy wrote:
27 Jul 2021, 08:16

That's probably because the TV has longer persistence phosphor(which means the phosphor shines for a longer period meaning more motion blur but less flicker) whereas most CRT Monitors use short persistence phosphor which means less persistence blur but more flickering.
Thanks for the info, It can be that. But I don't remember to see blur at the TV and I did see phosphor trails at the monitor. I have to test an interlaced CRT TV again, cause many PS 2 games I had tested had a fixed camera, so you can't move it to see if it have blur. The ones I remember to test that have a not fixed camere were Shadow of the colossus, GTA San Andreas and FF XII, but these seems to have 25fps or 12fps, so I saw a doubled image.

But I don't understand well how interlaces resolution works, is it using 25 half fps to do 50fps at 50hz or 50 half fps at 50hz ?, so are maybe 25fps at 50hz inerlaced like 50fps at 50hz progessibe?.

User avatar
Chief Blur Buster
Site Admin
Posts: 9456
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 » 30 Jul 2021, 02:01

mynm wrote:
28 Jul 2021, 13:08
But I don't understand well how interlaces resolution works, is it using 25 half fps to do 50fps at 50hz or 50 half fps at 50hz ?, so are maybe 25fps at 50hz inerlaced like 50fps at 50hz progessibe?
It’s easier to understand interlaced if you think of the fields-vs-frames methodology.

A TV field is a half-vertical-resolution frame (either the even pixel rows or odd pixel rows)

A TV frame is two fields (two images).

You can still send 60 frames per second in fields, and the eye sees all of them temporally 1/60sec apart.

Doing 60fps 60Hz interlaced to a TV is just:

TV Field #1 = even pixel rows of GPU frame #1 (TV frame #1)
TV Field #2 = .odd pixel rows of GPU frame #2 (TV frame #1)
TV Field #3 = even pixel rows of GPU frame #3 (TV frame #2)
TV Field #4 = .odd pixel rows of GPU frame #4 (TV frame #2)
TV Field #5 = even pixel rows of GPU frame #5 (TV frame #3)
TV Field #6 = .odd pixel rows of GPU frame #6 (TV frame #3)
TV Field #7 = even pixel rows of GPU frame #7 (TV frame #4)
TV Field #8 = .odd pixel rows of GPU frame #8 (TV frame #4)
Etc.

So resist your mental terminology confusion by pretending “field” is a “frame” and ignore “TV frame” and you will understand your eyes are still seeing 60 frames per second despite the TV literature saying “60 Hz interlaced, 30 frames per second”

Re-interpret the terminology confusion (TV fields, TV frames, and GPU frames)

Then the 60 TV refresh cycles is much easier to understand as:

TV refresh cycle #1 = GPU frame #1 (just only its even pixel rows)
TV refresh cycle #2 = GPU frame #2 (just only its odd pixel rows)
TV refresh cycle #3 = GPU frame #3 (just only its even pixel rows)
TV refresh cycle #4 = GPU frame #4 (just only its odd pixel rows)
TV refresh cycle #5 = GPU frame #5 (just only its even pixel rows)
TV refresh cycle #6 = GPU frame #6 (just only its odd pixel rows)
TV refresh cycle #7 = GPU frame #7 (just only its even pixel rows)
TV refresh cycle #8 = GPU frame #8 (just only its odd pixel rows)

Interlacing is metaphorically “temporal antialasing” only in the vertical dimension to turn 240p into 480i. Essentially an analog yesteryear equivalent of temporal antialiasing to increase vertical resolution without using extra bandwidth.

Many retro consoles disabled this behavior by doing 240p instead of 480i by displaying the pixel rows (scan lines) on top of each other instead of between each other next refresh cycle, via minor changes to the analog signal timing. An even number of scanlines per pair of refresh cycles (e.g. 524 scanlines) created 240p in analog CRT circuits. An odd number of scanlines per pair of refresh cycle (e.g. 525 scan lines) created 480i in analog CRT circuits. The CRT didn’t know what resolution it was, it was simply clever analog signal timing sheninigians to allow the same TV to do 240p or 480i (262p or 525i including VBI), to trick the defacto vertical temporal antialiasing of doubling vertical resolution.

Notice To CRT oldtimers from the 1970s: I humbly apologize for bastardizing my terminology in an attempt to explain to modern 2020s LCD users how interlacing works… We never invented the phrase “vertical temporal antialiasing” to refer to how CRTs turned 240 to 480, but it’s essentially what it is, in modern terminology.
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

mynm
Posts: 12
Joined: 23 May 2015, 06:36

Re: Using a reshade black frame insertion shader fx?

Post by mynm » 30 Jul 2021, 11:45

Thanks for the explanation, I was thinking that for 60fps or 50fps games it was working like this:

TV Field #1 = even pixel rows of GPU frame #1 (TV frame #1)
TV Field #2 = .odd pixel rows of GPU frame #1 (TV frame #1)
TV Field #3 = even pixel rows of GPU frame #2 (TV frame #2)
TV Field #4 = .odd pixel rows of GPU frame #2 (TV frame #2)

But for what you say that is for 30fps or 25fps games, the ones I saw with double image in motion.

I will see some frame rate test videos and I will test. For example in this video they say that PS1 Ridge Racer Type 4 and GT runs at 30fps, I suppose 25fps at PAL format, but I don't remember to se doble image in motion with those games.

User avatar
Chief Blur Buster
Site Admin
Posts: 9456
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 » 30 Jul 2021, 16:59

mynm wrote:
30 Jul 2021, 11:45
But for what you say that is for 30fps or 25fps games, the ones I saw with double image in motion.
The same double images on any impulsed display will occur regardless of interlaced or progressive.

Image

In fact, I can create the double images with software based black frame insertion too (it takes four frame sequences in order to do so on a sample-and-hold display), but here's a live demo, double-images on a non-strobed LCD.

www.testufo.com/blackframes#count=2&multistrobe=2&easteregg=1



Also, there's an software-based-interlacing TestUFO too: www.testufo.com/interlaced

Seeing double images at 25fps and 30fps much more easily -- requires very fast vertical and horizontal motion while sitting sufficiently close to the screen. Back in the old gaming-console days, you're sitting 20 feet from a tiny 27 inch CRT TV from a sofa, playing a game that didn't do fast scrolling. So your racing game and narrow-FOV is a terrible example. Use a platformer game (fast sideways scrolling) or shoot-em-up (fast vertical scrolling). Alternatively, try watching trees or road signs scroll sideways by looking to the edge of the road, rather than looking at the road center (like you do for most car games). Dark tree/road sign against bright sky, zooming past when you look to the left edge or right edge -- you will see double image.
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

mynm
Posts: 12
Joined: 23 May 2015, 06:36

Re: Using a reshade black frame insertion shader fx?

Post by mynm » 08 Aug 2021, 13:46

Thanks for the explanation. Is like you say, I have tested GT, GT2 and Ridge Racer Type 4 with a CRT TV and like you say trees, road sign and streetlights at the left edge or right edge of the screen are doubled. That are the type of things I search to see if the game framerate is at the half of the Hz. With GT4 the image is not doubled.

Also I have tested a CRT monitor at 50hz, with a notebook, and the screen flikering looks similar to the 50hz CRT TV. I was remembering wrong or my distance to the TV was higher and I didn't see it. Is a shame that I can't test the CRT monitor with my PC in games as I have tested an hdmi to vga adapter and is not working with that monitor. I opinios for that adapter were good. I don't know where to ask for info to get a good adapter. Is there a section in the forum where I could ask about it?.

JoseJL
Posts: 4
Joined: 16 Apr 2021, 06:32

Re: Using a reshade black frame insertion shader fx?

Post by JoseJL » 03 Sep 2021, 11:13

Hello. I have been reading this thread, and I found it quite interesting.

I bought a Viewsonic XG270 a few days ago, and I'm quite happy with how PureXP works in Retroarch coupled with BFI.
But the lack of 60 hz strobing is quite a problem for 60 fps locked games (I'm quite sad about XG2431 not being sold here in Europe), so I have been toying around with the desktop BFI apps here.
In my case, the BFI timing seems quite erratic compared to what I get in Retroarch, so I tested some things.

Instead of using the low level D3DKMTWaitForVerticalBlankEvent and D3DKMTGetScanLine, I just made a regular D3D11 swapchain with the render target being black. Otherwise, it's the same principle, still uses the window alpha attribute for making it transparent. The BFI timing seems more accurate this way in my case, as long as this window keeps the focus.
Any ideas why I'm getting better results with a higher level approach?

Also, after reading a few threads here, it seems that the best approach would be having a virtual display driver, but that seems to be quite difficult if I understood correctly.
While reading the documentation on Microsoft's site, I found out about the DXGI mirror API.

I found this small sample on Github, and I added a simple 2:1 BFI algorithm (60 hz on my secondary screen, 180hz on the XG270).

It is still isn't perfect, but the timing seems more precise than the window overlay approach.
Would there be any caveats to this approach?
Since it's rendered using D3D11, we could use any shader for emulating CRT or any other thing, so at least it's got potential in that front.

JoseJL
Posts: 4
Joined: 16 Apr 2021, 06:32

Re: Using a reshade black frame insertion shader fx?

Post by JoseJL » 05 Sep 2021, 12:20

I created a small proof of concept.
You can mirror any display and apply BFI to them, similar how it works in Retroarch (1 regular frame, X black frames)

I tried it with an indirect display device driver that creates a 60 hz 1920x1080 virtual monitor, and it works the same as it does with a real screen.

Check it on Github
https://github.com/roshkins/IddSampleDriver/releases
https://github.com/josejl1987/DirectXDe ... icationBFI (my proof of concept code)
Attachments
DirectXDesktopDuplicationBFI.zip
(153.47 KiB) Downloaded 6 times

User avatar
Chief Blur Buster
Site Admin
Posts: 9456
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 » 10 Sep 2021, 13:40

JoseJL wrote:
05 Sep 2021, 12:20
I created a small proof of concept.
You can mirror any display and apply BFI to them, similar how it works in Retroarch (1 regular frame, X black frames)

I tried it with an indirect display device driver that creates a 60 hz 1920x1080 virtual monitor, and it works the same as it does with a real screen.

Check it on Github
https://github.com/roshkins/IddSampleDriver/releases
https://github.com/josejl1987/DirectXDe ... icationBFI (my proof of concept code)
Excellent stuff. I have sent you a PM.

Would you be willing to integrate Reshade or SweetFX to this, for per-refresh-cycle shader processing on this indirect display driver? Someone else is working on that already but you just beat them to the punch.

There's some GPU shader-processing stuff that requires refresh-cycle processing granularity such as simulated software-based VRR, and software-based LCD overdrive algorithms, that needs to process every refresh cycle, independently of the underlying framerates of the application.

A generic open source refresh cycle reprocessor, capable of running shaders per refresh cycle, written from scratch is something that can open up a lot of applications.

Such a generic refresh-cycle processor framework would keep a memory o0f the last few refresh cycles *and* also contain a Present()-hook to measure frametimes, while also being able to output multiple reprocessed refresh cycles per frame (as required). This is all I need to execute a software-based emulated variable refresh rate similar to what I've already done at www.testufo.com/vrr

I believe lots of people like Kalediaen (Special K), Guru3D, and others may be very interested in integrating this sort of idea into their open source projects for enhanced refresh cycle processing for even better, superior lower-lag framerate capping algorithms and analysis.
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