Depth buffer detection modifications

Far Cry has similar problems

*ALL DISABLED: game flickers (heavy Z fighting ?)
*CDBBC: luma shifting and 2D elements (HUD) get shadowed (!)

*Fix: no luma/2D issues but missing scene part!

Note: I'm using the Vogons FC Fix -> github.com/CookiePLMonster/SilentPatchFarCry/releases

lowenz wrote: *ALL DISABLED: game flickers (heavy Z fighting ?)

lowenz wrote: Note: I'm using the Vogons FC Fix -> github.com/CookiePLMonster/SilentPatchFarCry/releases

lowenz wrote: *ALL DISABLED: game flickers (heavy Z fighting ?)

When all disabled, does it flickers when selecting a specific depth buffer target ?

I will try to explain what i have done in those experimental dlls.

At first, i tried to implement the same depth buffer detection techniques as in d3d10 and d3d11, adding the Otis's draw_call_tracker class to retrieve the depth buffer that holds the max number of draw calls and vertices.
But the d3d9 implementation of depth buffer is more restrictive than the one on earlier APIs.
To retrieve the depth buffer data, it is necessary to use specific D3D9 GPU Hacks. So it is necessary to create a specific depth stencil texture and its associated depth stencil surface, with a special format.
Another restriction: in d3d9, there is only one z buffer at a time per device. So Crosire implemented a switch between the actual depth buffer of the game, and the hacked depth buffer at the setDepthStencilState stage. By using the hacked texture/surface at the present stage, it does not interfere with the depth tests of the game, and the stencil pass.
If i made things right, the addition of the draw_call_tracker should not change the actual behaviour of reshade for d3d9 games where the depth buffer is already available.

The problem that still relies is: what if the depth buffer is cleared before the presenting stage ?
I tried to implement the same strategy than in d3d11 or d3d10: make a copy of the depth buffer at the clearing stage, store those copies in the draw_call_tracker, then reuse it on the present stage.
Unfortunately, because of the restrictions of the d3d9 implementation, this copy is not possible (except, perhaps, using a dedicated pixel shader and copy the resulting render target which holds the texture sampled by this shader).

So, i tried another strategy, which seemed to me only for analysis purpose: in the draw calls interceptions, i add a new draw call, only dedicated to reconstruct the depth buffer in the hacked depth buffer texture.
The cullcript here is that it simply doubles the number of drawcalls (i wonder what will be Crosire's reaction when he will see the code) ! However, when i tested it, it seemed not to taxing. In fact, with modern GPUs, those d3d9 games use far less drawcalls than modern ones, and we can afford this duplication of draw calls (but i have not tested it on Skyrim).

The first game i tested was mass Effect 2. In this game, using the hacked depth buffer texture at an early stage in the rendering pipeline produces bugs, because of the loss of some stencil data. When implementing the duplication of draw calls, those bugs disappear because i preserve the data in the actual z buffer of the game. But this duplication seems to introduce some little bugs you focused on your tests.
In Mass Effect 2 , i found a workaround (which i called "compatibility fix").

The algo in the draw call stage is this one (simplified):
- make the usual draw call in the actual render target(s) and the actual z buffer
- if "depth buffer before clear" is ticked, switch the z buffer to the hacked one, saving a pointer to the actual one
- replay the draw call to populate the depth buffer
- switch back to the actual z buffer of the game

When the compatibility fix is enabled, the algo becomes:
- make the usual draw call in the actual render target(s) and the actual z buffer
- if "depth buffer before clear" is ticked, switch the z buffer to the hacked one, saving a pointer to the actual one
- switch the render target to an hacked render target (using FOUCC_NULL to preserve memory), saving a pointer to the actual one(s)
- replay the draw call to populate the depth buffer
- switch back to the actual z buffer of the game
- switch back to the actual render target(s) of the game

I guess the problem you pointed out are blending conflicts. Maybe using a specific stateblock can fix it. Have to check it when i got time
Also, will try to invert the draw calls and send to you another version to see if it can resolves some of the problems you mentioned.

If Crosire read this post, i would appreciate his comments .

Bonus stage: using Reshade and the displayDepth shader, i can retrieve a very good wireframe representation of the game (similar to the one provided in Morrowind, see ACO below). This mode is enabled only in offline mode, of course . In my dlls, you can bind a key combo for this purpose...

thalixte wrote: When all disabled, does it flickers when selecting a specific depth buffer target ?

YES, but issues remain!

2D missing elements in menu:

alias/phantom of the weapon (look @the muzzle @right of the savescreenshot):

Do you have those issues with the last Reshade release ?

Errata corrige:

When all disabled, does it flickers when selecting a specific depth buffer target ?
YES, but issues remain!

I mean: YES, it DOESN'T FLICKER but issues remain!
3D scene is somehow stable selecting a specific DB but 2D issues remains.

thalixte wrote: Do you have those issues with the last Reshade release ?

No issue with Crosire version (must check the luma).

In Far Cry the best choice with your lastest version is CDBBC only, but there's the luma shifting (a darkening actually in far cry and halo CE)

lowenz wrote:

thalixte wrote: Do you have those issues with the last Reshade release ?

No issue with Crosire version (must check the luma).

In Far Cry the best choice with your lastest version is CDBBC only, but there's the luma shifting (a darkening actually in far cry and halo CE)

Yes, i know that this luma issue is specfic to my experimental dlls. What i meant is: do you have a working depth buffer with no issues in far Cry, using the last Reshade release ?

thalixte wrote:

lowenz wrote:

thalixte wrote: Do you have those issues with the last Reshade release ?

No issue with Crosire version (must check the luma).

In Far Cry the best choice with your lastest version is CDBBC only, but there's the luma shifting (a darkening actually in far cry and halo CE)

Yes, i know that this luma issue is specfic to my experimental dlls. What i meant is: do you have a working depth buffer with no issues in far Cry, using the last Reshade release ?

Yes.
Crosire DLL -> perfect DB access, no issue
lastest thalixte DLL -> DB access with CDBBC, luma issues

lowenz wrote:

thalixte wrote:

lowenz wrote:

thalixte wrote: Do you have those issues with the last Reshade release ?

No issue with Crosire version (must check the luma).

In Far Cry the best choice with your lastest version is CDBBC only, but there's the luma shifting (a darkening actually in far cry and halo CE)

Yes, i know that this luma issue is specfic to my experimental dlls. What i meant is: do you have a working depth buffer with no issues in far Cry, using the last Reshade release ?

Yes.
Crosire DLL -> perfect DB access, no issue
lastest thalixte DLL -> DB access with CDBBC, luma issues

OK, thks. So it seems i made something wrong when connecting draw_call_tracker to the normal debth buffer detection mode. I have to reinstall Far Cry to check it (hope my old cd will still work)

Similar behaviour in Pariah (wrapped through Crosire d3d9 wrapper)

ALL DISABLED: erratic access to DB

CDBBC: access to the DB but luma shifting

Fix: no more luma shifting but depth issues (see the hand)

I tested RE4 UHD and had major performance problems with the new dll. "Copy depth buffer" needed to be checked to get MXAO to work and I left the other settings unchecked. The framerate was sluggish and GPU usage was at 100% (without ReShade it's 30%, with previous dlls and MXAO running it was around 70%), and this did not change when disabling all effects.

I tried removing all of my ReShade config files out of the folder and doing a new install, then replacing the dll with your new one. The game performed normally until I once again enabled "copy depth buffer," at which point the performance dropped again.

I also had the same issue I posted about earlier where this dll caused the screen to be very light and washed out. The first few builds of your mod didn't cause this. I found that I could restore the image to normal by changing the resolution in game to something else then changing it back, but any notification from Steam (like when taking a screenshot) would cause the screen to white out again. I can avoid this entirely by disabling the Steam overlay for the game, but it would be better if the problem could be found.

Thanks for updating this and let me know if there is anything I can do to test further.

Nerrel wrote: I tested RE4 UHD and had major performance problems with the new dll. "Copy depth buffer" needed to be checked to get MXAO to work and I left the other settings unchecked. The framerate was sluggish and GPU usage was at 100% (without ReShade it's 30%, with previous dlls and MXAO running it was around 70%), and this did not change when disabling all effects.

Thanks for updating this and let me know if there is anything I can do to test further.

You're welcome !
Unfortunately, that's what I feared: duplicating the drawcalls should hae an impact on perfs. What is your config ?

Here are two new dlls. I rewrote the code (cleaner now), and started from the last release versin of Reshade. So, in Far Cry, the DB should work when ALL disabled.

• d3d9_32bits.zip
• d3d9_64bits.zip

thalixte wrote: So, in Far Cry, the DB should work when ALL disabled.

And it does!

It seems we're on a good track!
UT3 (and now the fix actually fixes CDBBC issues)

CDBBC fake shadow issue

Fixed with the compatibility fix (luma too!)

thalixte wrote: You're welcome !
Unfortunately, that's what I feared: duplicating the drawcalls should hae an impact on perfs. What is your config ?

Here are two new dlls. I rewrote the code (cleaner now), and started from the last release versin of Reshade. So, in Far Cry, the DB should work when ALL disabled.

• d3d9_32bits.zip
• d3d9_64bits.zip

I'm using an i5 6600k with 16GB of RAM and a GTX 970. Running the game at 1440p with MXAO, it usually holds 60fps without a problem. It still runs slowly with the newest dll. If I disable copy depth buffer while the game is running then it speeds back up but the effects won't work until the game is restarted. I also noticed that it seems to need the compatibility fix toggled on or the screen will be very dim (first shot has everything disabled, compatiblity fix on looks the same as this):

Move around a bit after toggling options

Halo 2 (Project Cartographer) report:

CDBBC: luma issues as expected

Fix: luma issues solved BUT HUD disappears