http://bugs.winehq.org/show_bug.cgi?id=18916
--- Comment #12 from Henri Verbeet hverbeet@gmail.com 2009-06-16 06:02:38 --- (In reply to comment #11)
(In reply to comment #10)
I think http://www.winehq.org/pipermail/wine-patches/2009-June/074312.html should fix this.
I'm a bit troubled by this computation:
WORD d15 = source[x] & 0xfffe; DWORD d24 = d15 * 0x100 + (d15 * 0xff80 + 0x3fff80) / 0x7fff00;If I multiply the arithmetic out as if this was floating point, this comes to
d24 = 256.0078 * d15 + 0.5
Don't get it. You're not relying on d15*0xff80 overflowing and doing something evil ... are you? Certainly if the top bit of d15 is set then this overflows as an unsigned value ... and then the division, in this inner loop, is not going to speed things up.
Why not just
DWORD d24 = (source[x] & 0xfffe) << 8;? What is the conversion rule that's really being applied here?
"DWORD d24 = (source[x] & 0xfffe) << 8;" would map 0x7fff to 0xfffe00 rather than 0xffffff. We essentially need to multiply by (0xffffff/0x7fff) and round correctly, which would result in something like "d24 = (d15 >> 1) * 512.0156 + 0.5", which in turn corresponds to the "d24 = 256.0078 * d15 + 0.5" you got above.