# d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

Stefan Dösinger stefandoesinger at gmx.at
Mon Feb 7 13:14:33 CST 2011

```Am Montag 07 Februar 2011, 19:37:09 schrieb Misha Koshelev:
> Stefan: I believe this is actually a _difference_ between Windows versions.
>
> As you will note on the full results from winetestbot as well as my
> own testing on XP (what I _thought_ was SP3) is that only 3/9
> platforms have this error. The rest pass fine. Thus, it seems a
> variance in the tests.
The results still don't make sense.

Basically it seems to me that native d3dx9 lacks support for NaN and INF.
Those magic numbers are created by making the highest possible exponent a
special marker(thus reduce exp_max by 1 and make exp_max + 1 special). This is
why halfs end up with 65536.0 as just not reachable number. The highest
exponent is 15, the highest mantissa value is 1023. This gives value = 2^15 *
(1 + 1023/1024) = 65504.

However, it looks like Windows(all versions) treat e = 16 like regular
numbers, allowing max numbers from -131008.0 to +131008.0. This is shown by
the conversion of 0x7fff to 131008.0 and 0xffff to -131008.0, and the conversion
of -INF to 0xffff (sign bit, exp=max+1=16, mantissa=max=1023). I suspect someone
tested INF and saw that it was converted into something that looked like NaN
and added a line like this:

if(isinf(input)) return 0x7c00;
or
if(input > 65504) return 0x7c00;

but didn't properly implement NaN and INF. Then someone realized such a check
is just stupid given the lack of infrastructure and removed it. And since the
code is maybe written in assembler the check got only removed from the 32 bit
version, not the 64 bit one. (Notice how old windows versions and 64 bit ones
return 0x7c00 and new 32 bit ones return 0x7fff).

I'd suggest a few more tests: See what a number like 80000.0 is converted to.
Look what happens to 65503, 65504, 65505, 65534, 65535, 65536. And see what
values like 0x7c01,7c02, 7ffe, 7ffd are converted to.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110207/5eef2e16/attachment.pgp>
```