d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

[Misha Koshelev]

On Fri, Feb 11, 2011 at 5:16 PM, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> Am Freitag 11 Februar 2011, 22:39:05 schrieb David Laight:
>> The 'usual' non-IEEE fp systems are vax (you probably can't put enough
>> memory in a vax to run wine!) and some arm systems where the two 32bit
>> words of a double aren't stored in the expected order!
> I don't expect to find any non-IEEE system where wine runs in the near future,
> or maybe in our lifetime. Its just that this function goes to great lengths to
> make sure it doesn't rely on the actual encoding that it is annoying that we
> have to give it up for detecting the sign of zeroes.
>
> If anything I'd say lets just make the actual sign depend on the bits:
>
> if(in == 0.0)
> {
>        if( ((unsigned int) in) == 0x00000000) return 0x0000;
>        else return 0x8000;
> }
> That way if a crazy system crosses our way that happens to encode 42.0 as
> 0x80000000 we'll get it right and just get the sign of zeroes wrong. However,
> I'd be glad if we had a really foolproof function.
>
> -----------
>
> For IEEE systems we could optimize the entire routine, protected by ifdefs:
> 1) Pick apart the 32 bit float like we do in the 16->32 case
> 2) Shift mantissa and exponent a bit to the right, taking care of rounding
> 3) Put them together as 16 bit
> 4) profit!
>
> No exp() and other stuff needed.
>

Ok guys, I get it.

We are trying to have the function work on non-IEEE systems.

How about the attached. It's basically

if (in == 0.0f) return (sign ? 0x8000 : 0x0000);

Seems to work:

https://testbot.winehq.org/JobDetails.pl?Key=9224

What do you think?

Misha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-d3dx9-Implement-D3DXFloat32To16Array-and-D3DXFloat16.patch
Type: text/x-patch
Size: 9130 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110212/8292aaa6/attachment.bin>