2010/1/20 Stefan Dösinger <[email protected]>:
> 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.
