D3D9 regression with Clip Planes (affects Far Cry)

Not sure if you ever had a chance to see a conversation under an issue in dxwrapper:

github.com/elishacloud/dxwrapper/issues/...suecomment-377729724

But there seems to be a regression regarding SetClipPlane in D3D9 between Windows XP and Vista/anything newer. Namely, there seems to be something (sadly I haven't been able to identify what exactly) corrupting clip plane settings between D3D calls. In the case of Far Cry, it results in water reflections not working properly.
The fix is really easy, involves caching clip plane settings and re-applying them before each draw call when clip plane renderstate is enabled.

This isn't a ReShade issue per se, but do you think it makes sense to ship a fix in it (and maybe d3d8to9 too)? It's very cheap and improves an unknown number of games (FC1 is the first game I am aware of to use clip planes).


Or maybe you are able to identify what D3D call corrupts clip plane state? During my attempts I tried to "dirty" them from different calls, like SetVertexShader, SetVertexShaderConstantF (D3D9 with programmable pipelines expects the plane to be defined in clipping space, so it's only logical said space gets invalidated when switching shaders) and it does help... partially. So far the only way to fix it without extra artifacts is to be a bit overreactive and re-apply states before each clipped draw call.

I don't think ReShade is the right scope to fix something like this. d3d8to9 may be, but it only affects D3D8 applications.

There has been a significant change in the Windows display driver model between Windows XP (XPDM) and Vista (WDDM), with another big change between Win7 (WDDM) and Win10 (WDDM2). So a lot of things work differently and there is a good chance something broke along the line. I'd suggest trying the WinXP compatibility mode in Win10 (although I think this only emulates various settings from older Windows versions, so it will probably not change anything).
msdn.microsoft.com/en-us/library/windows...471598(v=vs.85).aspx (XPDM vs. WDDM)
msdn.microsoft.com/en-us/library/windows...417756(v=vs.85).aspx (Graphics APIs in Windows)

On top of this, modern hardware has no concept of user clip planes, so they are emulated in software and from what I read this is inconsistent across drivers and vendors and should be avoided at all cost (note how there is next to no documentation on these from Microsoft as well). AFAIK they also don't work in the reference rasterizer (D3DDEVTYPE_REF), so there's that.

I know compatibility modes don't help for sure.

And yeah, clip planes looks like an obscure and legacy feature - seeing how the docs mention an implicit behaviour change basing on whether a fixed function or programmable pipeline is used... it's very fishy.

I do think it's worth pushing this fix for d3d8to9, for two reasons:
1: If clip planes are working fine with real d3d8 (very unlikely), then d3d8to9 most likely introduces a regression by introducing this d3d9 bug/incosistency.
2: If clip planes are also broken with d3d8, then it's a compatibility improvement/fix.

So IMO accounting for that is a win-win - especially since the solution is very cheap (one extra D3D call for each draw call which is clipped - so not too many, if any).

I have submitted a pull request to d3d8to9 regarding this - whether or not you also want it to be a part of ReShade is up to you.