[PATCH 4/5] wined3d: Don't use the depth range clipping hack when we have ARB_depth_clamp.

[Henri Verbeet]

2010/1/20 Stefan Dösinger <stefandoesinger at gmx.at>:
> I am ok with the patch being committed, as in the worst case this is just a hack replaced by another hack, and it seems right to me.
>
> That said, I was trying to write some tests about the d3d9 D3DRS_CLIPPING behavior, and it seems the near and far clip planes are still used when it is disabled. I can think of 3 other cases:
>
> * There's a different behavior in ddraw. The two games I remember that are affected by the clipping are Half Life 1 and Prince of Persia 3D. I can't think of any d3d8 and d3d9 apps.
>
> * There's some other state involved I missed in my quick and dirty testing. My only systematic testing so far was about the glDepthRange-like behavior of minZ and maxZ. Both games use RHW vertices. Currently the glOrtho minZ / maxZ hack is used for RHW vertices only.
>
> * The near and far clipping planes are supposed to be enabled even in these two games, but something else is going wrong and the games are sending wrong depth values to ddraw. HL1 uses ProcessVertices, but pop3D uses its own software vertex processing, and I don't think we can screw this up in a subtle way that breaks the depth but not X or Y.
>
>
I'm somewhat tempted to just kill the hack and see what breaks. It
would have been nice if there were tests for this, of course.