protonscr

Strobing effect possible?

dxvkclosed
doitsujin/dxvk#1847 · opened 2020-12-08 by artivision · updated 2023-12-18 · 12 comments · github
Aartivision 2020-12-08 github

Good day. Some drivers on Windowz and some monitors have strobing effect where black frames of paused pixels for a few ms, are inserted between normal frame for less ghosting. Is this possible with DXVK?

Mmisyltoad 2020-12-08 github

what

WWaterVes82 2020-12-08 github

hey can you make custom vulkan for star citizen ? using both dxgi and d3d11 ?

Ddoitsujin maintainer 2020-12-08 github

No. Also, I'd like to see an example of such a windows driver because I'm fairly certain that this is bullshit.

Aartivision 2020-12-09 github

No. Also, I'd like to see an example of such a windows driver because I'm fairly certain that this is bullshit.

What? VR and some applications have it. I have one that is no my code to upload, that we lock at 72fps/144hz and instead of an interval of repeating the same frame twice, we send one original and one black frame.

Ddoitsujin maintainer 2020-12-09 github

Well, I'm sorry, but the way you phrased the initial request didn't specify the scenario. "Windows drivers" is very different from "VR app running at half the native frame rate".

Anyway, still not going to happen because DXVK isn't responsible for doing presentation in VR apps. Unless that's still not what you mean.

KK0bin maintainer 2020-12-10 github

And gaming monitors usually do this for regular games by strobing the backlight, not by halving your refresh rate and showing a black image every other frame.

Aartivision 2020-12-10 github

Sorry i did phrase it wrong - twice. Our code is not VR and i don't ask to support our code. I just thought that many people have 144hz monitors and from those only a small percentage of games are played to 100fps+, mostly Shooters. The rest of the games use high quality settings and 50-70fps. So instead of the Adaptive Sync slow the monitor at 50-70hz we can play at 100-140hz range with one normal frame and one black, without loosing millisecond. This may reduce ghosting when backlight strobing is not available, the actual majority. If doesn't work, sorry for taking your time.

Ddoitsujin maintainer 2020-12-10 github

If it's your code then why not support this at the app level? Why do you need the D3D11 implementation to support this and how do you achieve this exact effect on Windows?

DDeus-nsf 2021-08-01 github

Sorry i did phrase it wrong - twice. Our code is not VR and i don't ask to support our code. I just thought that many people have 144hz monitors and from those only a small percentage of games are played to 100fps+, mostly Shooters. The rest of the games use high quality settings and 50-70fps. So instead of the Adaptive Sync slow the monitor at 50-70hz we can play at 100-140hz range with one normal frame and one black, without loosing millisecond. This may reduce ghosting when backlight strobing is not available, the actual majority. If doesn't work, sorry for taking your time.

I got redirected here, this particular comment is very true, though in that case it's not really strobbing but black frame insertion, high end LG OLED TVs do this at a hardware level, but it's a fixed refresh only feature and OLED is really expensive, it can indeed be implemented in the game code but no-one does that... having black frame insertion at a software level with a behaviour like d3d9.presentInterval =2 but drawing a black empty frame 1/2 would not only make games look twice better on modern displays, but also work with adaptive sync (which is not the case of OLED TVs and even high end gaming monitors). I wish I had the programming skills to contribute, I'd love to add that kind of feature, but I don't even know how to draw a triangle with Vulkan lol... (I did a bit of OpenGL and Direct3D though, but that was a while ago)

Ddoitsujin maintainer 2021-08-01 github

Yeah, hardware-level black frame insertion or backlight strobing is a thing, I've learned that by now. OP assumed this was somehow a software thing though.

but no-one does that

Well, there's a reason why no one does it in software. It's trash, just a terrible idea that cannot work.

On LCDs you have response times to worry about, meaning that most displays cannot even display the desired image correctly before transitioning to another black frame, especially VA panels. Then you also need literally perfect present timing since every minor deviation will lead to changes in perceived brightness (i.e. flicker), which you simply cannot guarantee from any userspace app and which also means that it will not, in fact, work with VRR or really anything other than the display's native refresh rate. It just doesn't work, and if it did, someone else would have had the idea and implemented it years ago in a Windows driver already.

It's trivial to add to DXVK, I just played around with it, but the results are unusable garbage, just as expected. We will not accept any PR that attempt to add the feature.

DDeus-nsf 2021-08-02 github

Damn... well I mean if you tried it then. I dont know, MAME and RetroArch users seemed to be super pleased about the feature, and hardware users say that they can't go back to not using it. Maybe I'll try to experiment with this on my side one day to see the benefits and disadvantages for myself. As for a DXVK implementation, well, I guess if its really not that great I suppose there's no point in pushing it.

DDeus-nsf 2023-12-18 github

Heh, I guess the situation changed with the deck OLED models out, though it would probably be preferrable to wait for an official OS level implementation, I'm pretty sure it will be done eventually, it's a total no brainer for OLED.

Nothing extracted yet.