d3dx9: Fix D3DXPlaneNormalize on 64 bits.

[Marcus Meissner]

On Mon, Oct 11, 2010 at 03:53:21PM +0200, Matteo Bruni wrote:
> 2010/10/11 Henri Verbeet <hverbeet at gmail.com>:
> > On 8 October 2010 16:32, Matteo Bruni <matteo.mystral at gmail.com> wrote:
> >> This patch changes D3DXPlaneNormalize to behave as native on 64 bits,
> >> returning infinity in the fourth plane component when the norm is 0.
> >> If this is not appropriate, I can resend without the implementation
> >> changes, just fixing the tests.
> >>
> > I can't say this is necessarily wrong, but I do think it looks suspicious.
> >
> 
> It looked strange to me too. But that is what I get here with native
> dlls and what 64 bit testbot machines return, so I assumed it to be
> some sort of "bug" of native 64 bit d3dx9_36.dll.
> Then I checked today's winetest results and it seems like native
> actually doesn't always have this broken behavior:
> http://test.winehq.org/data/0cc9c52f8c5ad5e1f821177f165fbb72be90d2d9/index_XP.html#d3dx9_36:math
> shows that Wylda's 64 bits machines don't fail the math test (while
> still failing the shader test fixed by my other patch). A peek into
> the version informations of these tests shows that d3dx9_36.dll
> version matches the one used in testbot virtual machines (as expected)
> but there is no d3dcompiler_43.dll, so probably Wylda has an older
> version of the DX SDK installed.
> That said, I don't know why this could happen. Given that the current
> output of our D3DXPlaneNormalize is arguably the best one, I'd just
> send a patch to accept both results in the tests without changing the
> implementation. Unless you have some idea, of course...

If you are passing floats or doubles as functions arguments, this might happen
if the compiler is not yet fixed (there were some issues I vaguely remember).

Ciao, Marcus