https://bugs.winehq.org/show_bug.cgi?id=52393
--- Comment #35 from Piotr Caban piotr.caban@gmail.com --- (In reply to labre from comment #34)
– Returning 0.0 instead of sign * 0.0 does not fix it.
The game still works for me when 0.0 is returned (even so it's incorrect).
– Had the assumption, that the code flow might be changed by a floating exception, e.g. not returning 0.0, but unpatched always emits traces before and after the calculation. So I’m not sure, what the _control87 function does, even after looking up the Microsoft docs. Is there a way to catch occurring floating exceptions with gdb? I have no experience with it, but I could find some tutorials.
There are no floating point exceptions. First of all, 0.0 * (any integer) should not cause any exceptions. Also the game is already masking all floating point exceptions. The control87 call affects 2 things: - it may affect how compiler optimizes code - it changes precision mode
You can try checking following things: - maybe adding _control87(0, 0) call is enough to make the bug gone - instead of changing whole control word you can try setting only the precision (_control87(_PC_64, _MCW_PC)), it's the only setting changed by the game - please upload msvcr80.dll (or msvcr80.dll.so in case of non-mingw build) from wine f99d307a3e1f9beb7fd9dc8892b5cfabbabf816b - change "return sign * 0.0" to "return sign==-1 ? -0.0 : 0.0"
Are you using any non-standard compilation options or CPU specific optimizations?