Depth buffer detection modifications

Strange indeed Each time i upload a new dll, the URI hash changes...

Using the latest code from your repo, in Fable 3 (d3d9 32 bit) enabling depth buffer preservation fixes the flickering the depth buffer has by default, but breaks some in game effects. Any idea if this can be fixed, or is it just an inherent issue of the preservation? Here's an example of the issue imgur.com/a/y6X69ny

Also, here are the DX12 games I've tested with your depth retrieval branch:
Hitman 2: Loads properly on official, continually reloads with latest
Star Wars Battlefront 2: Ditto
Deus Ex Mankind Divided: Works properly, depth buffer is available
Serious Sam Fusion 2017: Works properly, depth buffer is available
Civ 6: Doesn't work on official or latest
Metro Exodus: Works properly, depth buffer is available
DMC5: Works properly, depth buffer is available
RE2: Works properly, depth buffer is available (for this and DMC5 I do get a "renderdevicedx12.cpp ERROR HRESULT=0x887a0001 |D3D12Device::CreatePipelineState() failed (%x) crash sometimes, not sure if this is an issue with the depth retrieval or the regular code)
I should note MXAO (specifically latest quint_mxao) seems to be broken (normal vectors view is all blue, AO is excessive and some vectors seem to be improper, example here: i.imgur.com/p3fuzDg.png the mountains display weirdly and swirl when moving in game. I checked that reverse/logarithmic was correct)
I believe the reloading issue is because, unlike the D3D9/11 depth modifications, any time the depth buffer selection is changed reshade reloads, and those games seem to have the depth buffer constantly changing.

I should note that when compiling I get the following errors:
I also have a question about D3D9 depth retrieval: Why can't the depth buffer be selected manually like in 11/12 when not preserving?

Niko of Death wrote: Using the latest code from your repo, in Fable 3 (d3d9 32 bit) enabling depth buffer preservation fixes the flickering the depth buffer has by default, but breaks some in game effects. Any idea if this can be fixed, or is it just an inherent issue of the preservation? Here's an example of the issue imgur.com/a/y6X69ny

This is the pb of the d3d9 detection. As there is only one depthstencil at a time, it is posible that the depth buffer presevation breaks some effects, because the game engine needs the depth bufer to be cleared to apply those effects, but reshade force the depth buffer not to be cleared. For many games, it works, but with somes, it can produce artefacts.
Have you tried to enable the weapon & cockpit fix: it adds a specific viewport in front of the standard one to retrieve the db. Maybe it could help...

Unfortunately no, it does not. I also added some notes on the D3D12 depth retrieval above.

Niko of Death wrote: Unfortunately no, it does not. I also added some notes on the D3D12 depth retrieval above.

Oh, thank you very much for taking the time to tests those directX12 games

For the "renderdevicedx12.cpp ERROR HRESULT=0x887a0001 |D3D12Device::CreatePipelineState() failed (%x)" crash, it is an issue related to the depth buffer copy. It happens when selecting the depth buffer "Copy" mode, right ?

For the reloading of the effects, it is the only way i found yet to make the depth buffer change. I hope Crosire will help me making the depth buffer selection change correctly without having to reload those effects.

The errors you mentioned are not error, just warnings. There should be some code cleaning to avoid them (for instance, changing UINT64 to UINT, and so on...).

Niko of Death wrote: I also have a question about D3D9 depth retrieval: Why can't the depth buffer be selected manually like in 11/12 when not preserving?

To manually select the depth buffers in d3d9, you have to untick the "auto preserve" checkbox. In the standard mode, i did not make any changes to the previous depth buffer selection behaviour. As there is only one depthstencil surface at a time, it is normal that you only see one line in the standard detection mode.

thalixte wrote:

Niko of Death wrote: Unfortunately no, it does not. I also added some notes on the D3D12 depth retrieval above.

Oh, thank you very much for taking the time to tests those directX12 games

For the "renderdevicedx12.cpp ERROR HRESULT=0x887a0001 |D3D12Device::CreatePipelineState() failed (%x)" crash, it is an issue related to the depth buffer copy. It happens when selecting the depth buffer "Copy" mode, right ?

For the reloading of the effects, it is the only way i found yet to make the depth buffer change. I hope Crosire will help me making the depth buffer selection change correctly without having to reload those effects.

The errors you mentioned are not error, just warnings. There should be some code cleaning to avoid them (for instance, changing UINT64 to UINT, and so on...).

Strangely no. I had it happen once on startup (not even bringing up the reshade GUI), and the other time it was from switching depth buffers (without enabling copy mode). I've only had it happen with those RE engine games though, and their implementation of DX12 leaves a lot to be desired performance wise (they're the only games where my rx 580 actually gets worse performance vs DX11), so maybe there's something weird going on with the engine? As for the reloading thing, looking at the depth buffers they are going crazy changing addresses, so presumably that is the cause (enabling copy mode solves this though)
Also on the issues with MXAO (and by extension the RT shader) - indirect lighting also seems to be broken, so I'm guessing it's just a shader issue.
For the D3D9 selection thing - I'm aware in copy mode you can disable auto preserve, I was wondering if it would be possible to have a buffer selection in the default depth buffer mode (for example, to try and work around cases like the Fable 3 one where copy mode breaks in-game depth effects).
Thanks for the responses, and keep up the good work! (Especially with Vulkan support coming soon, which I'm desperate to try every time Crosire commits)

Niko of Death wrote:

thalixte wrote:

Niko of Death wrote: Unfortunately no, it does not. I also added some notes on the D3D12 depth retrieval above.

Oh, thank you very much for taking the time to tests those directX12 games

For the "renderdevicedx12.cpp ERROR HRESULT=0x887a0001 |D3D12Device::CreatePipelineState() failed (%x)" crash, it is an issue related to the depth buffer copy. It happens when selecting the depth buffer "Copy" mode, right ?

For the reloading of the effects, it is the only way i found yet to make the depth buffer change. I hope Crosire will help me making the depth buffer selection change correctly without having to reload those effects.

The errors you mentioned are not error, just warnings. There should be some code cleaning to avoid them (for instance, changing UINT64 to UINT, and so on...).

Strangely no. I had it happen once on startup (not even bringing up the reshade GUI), and the other time it was from switching depth buffers (without enabling copy mode). I've only had it happen with those RE engine games though, and their implementation of DX12 leaves a lot to be desired performance wise (they're the only games where my rx 580 actually gets worse performance vs DX11), so maybe there's something weird going on with the engine? As for the reloading thing, looking at the depth buffers they are going crazy changing addresses, so presumably that is the cause (enabling copy mode solves this though)
Also on the issues with MXAO (and by extension the RT shader) - indirect lighting also seems to be broken, so I'm guessing it's just a shader issue.
For the D3D9 selection thing - I'm aware in copy mode you can disable auto preserve, I was wondering if it would be possible to have a buffer selection in the default depth buffer mode (for example, to try and work around cases like the Fable 3 one where copy mode breaks in-game depth effects).
Thanks for the responses, and keep up the good work! (Especially with Vulkan support coming soon, which I'm desperate to try every time Crosire commits)

Yes, RE engine seems a little bit weird Thks for your support. I hope i will find time to implement on vulkan soon (i want depth buffer in the No Man's Sky last updates) ...

Just found another interesting DX9 case - In Fable Anniversary (UE3) I'm not able to get depth buffer with any of the options at 1080p (native res for me), but if I set the game to 1440p or 4K VSR (not when upscaling from 900p or 720p though) I am able to get a working depth buffer using the preservation option. It's weird because as far as I know when using reshade with VSR it acts exactly as it would if it was on a native 1440p or 4K screen.

Niko of Death wrote: Just found another interesting DX9 case - In Fable Anniversary (UE3) I'm not able to get depth buffer with any of the options at 1080p (native res for me), but if I set the game to 1440p or 4K VSR (not when upscaling from 900p or 720p though) I am able to get a working depth buffer using the preservation option. It's weird because as far as I know when using reshade with VSR it acts exactly as it would if it was on a native 1440p or 4K screen.

Yes, for me, it sounds strange too. In 1080p, if you change the vsync method, does it modify the depth buffer detection ?

thalixte wrote:

Niko of Death wrote: Just found another interesting DX9 case - In Fable Anniversary (UE3) I'm not able to get depth buffer with any of the options at 1080p (native res for me), but if I set the game to 1440p or 4K VSR (not when upscaling from 900p or 720p though) I am able to get a working depth buffer using the preservation option. It's weird because as far as I know when using reshade with VSR it acts exactly as it would if it was on a native 1440p or 4K screen.

Yes, for me, it sounds strange too. In 1080p, if you change the vsync method, does it modify the depth buffer detection ?

Nope. I had been using AMD's Enhanced Sync with in game vsync off, tried Enhanced Sync with in game vsync on, and no driver forced vsync with in game on/off, no changes.

Can you please test this dx12 version (the auto detection should work in standard mode with Devil may Cry 5) ?

d3d12_64bits.zip

[strike] mega.nz/#!ewgEzCDJ!hU_DLfTjo087VHypXYiPRN7kd7VP4m_q0EG2l8lbmEQ [/strike]

thalixte wrote: Can you please test this dx12 version (the auto detection should work in standard mode with Devil may Cry 5) ?

First, thanks for working on DX12 depth buffer detection.
Tested DMC5 with SMAA and FilmicSharpen, both using depth buffer features sucessfuly. Had few issues tho :
- Shaders recompile indefinitely in menus, sometimes randomly during gameplay
- Game crashed when I turned SMAA predication on and then switched to DX11 with long black screen pauses at start up, not sure if that's necesarily ReShade's fault, tho.

If I find something else, I'll let you know.

thalixte wrote: Can you please test this dx12 version (the auto detection should work in standard mode with Devil may Cry 5) ?
]

Tested with both DMC5 and RE2, tried switching around depth buffers a lot in standard mode and enabling/disabling copy mode, no crashes. Restored the old one just to check, got crashes immediately, so looks good!

Marty wrote:

thalixte wrote: Can you please test this dx12 version (the auto detection should work in standard mode with Devil may Cry 5) ?

First, thanks for working on DX12 depth buffer detection.
Tested DMC5 with SMAA and FilmicSharpen, both using depth buffer features sucessfuly. Had few issues tho :
- Shaders recompile indefinitely in menus, sometimes randomly during gameplay
- Game crashed when I turned SMAA predication on and then switched to DX11 with long black screen pauses at start up, not sure if that's necesarily ReShade's fault, tho.

If I find something else, I'll let you know.

The shaders recompiling is because of depth buffers switching (when theres no 3D rendering going on this tends to happen a lot). The best workaround for now is to manually select the depth buffer to prevent it from changing (but, of course, you might have to update it occasionally). Switching to DX11 on crash is standard behavior for the game, but did you get a crash message like I did earlier?

Niko of Death wrote: but did you get a crash message like I did earlier?

I did get some DX12 error window on the crash, yes.

Marty wrote:

Niko of Death wrote: but did you get a crash message like I did earlier?

I did get some DX12 error window on the crash, yes.

Weird, I'm not getting anything like that. I have an AMD card though, maybe it's an issue with nvidia cards?

Niko of Death wrote: Weird, I'm not getting anything like that. I have an AMD card though, maybe it's an issue with nvidia cards?

I do have GTX1080, yes. But It only happened once, when I turned on predication in-game. As I was saying I'm not even sure it's related... it might be

Can you please test this dx12 version (the depth buffer switching should work without reloading the effects) ?

d3d12_64bits.zip

[strike] mega.nz/#!PgIxFayZ!9uf-IjZ-7weFF2Z6YjL5OoZ1Z2J7E6_M1W0ro78D6-E [/strike]

thalixte wrote: Can you please test this dx12 version (the depth buffer switching should work without reloading the effects) ?

d3d12_64bits.zip

mega.nz/#!PgIxFayZ!9uf-IjZ-7weFF2Z6YjL5OoZ1Z2J7E6_M1W0ro78D6-E

Apologies, I saw your commits and compiled with them but forgot to actually test.
In HITMAN 2 the depth buffer switching isn't an issue, but I crash after enabling any effects now (even on restarting, so it's not just a reloading issue). Same with Battlefront 2.
I tried compiling debug version to try and get specifics on whats causing the issue, but I get a Debug Assertion Failed on vector line 1733 (vector subscript out of range).

It seems to be an issue with when the depth buffer ID changes, even when the effect doesn't use depth info (i.e. vibrance).

Thks a lot for taking the time to test. Is it possible for you to test those games with my previous dll (the one where the effects recompile when switching the depth buffer) ?

EDIT:
@Niko of Death, this dx12 version should fix your bug (stupid mistake i made ):

d3d12_64bits.zip

mega.nz/#!69JjXaRQ!aLcryIisHJhVCc8rozPbhJcLP0LULpac_Qm-GzaFUcU

Be sure to name the dll d3d11.dll, and check if there is no dxgi.dll present in the same folder.