d3dx9: Fix D3DXPlaneNormalize on 64 bits.

[Matteo Bruni]

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...