Am 20.01.2010 um 01:08 schrieb Chris Robinson:
The comment says that it's using MinZ/MaxZ to suppress depth clipping, which could otherwise occur with 0..-1. GL_DEPTH_CLAMP needs to be enabled if 'untransformed' is false, to suppress depth clipping as intended.
Since the transformed-vertex path is there to bypass transformation and frustum clipping, it would make sense to clamp and disable user clip planes, too (but as you said, that's not current behavior, so may need to be tested; same for viewport clipping).
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.