d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.
misha680 at gmail.com
Sat Feb 12 13:41:41 CST 2011
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:
What do you think?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9130 bytes
Desc: not available
More information about the wine-devel