2010/10/11 Henri Verbeet hverbeet@gmail.com:
On 8 October 2010 16:32, Matteo Bruni matteo.mystral@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_X... 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...