On Thu Jul 3 14:26:07 2025 +0000, Jacek Caban wrote:
I'm not sure what the best solution is. We could introduce a mechanism to specify the FP mode for selected modules, but technically there's no guarantee the result will be correct if we're called with an invalid x87 stack state. Maybe we could just use `fninit` (preserving the control word, if needed) in specific cases. Do you remember if the Re-Volt issue was tied to a particular piece of functionality? I can’t reproduce it. The game runs fine and I can enter a race with SSE math enabled (tested with both GCC and Clang builds). Maybe the issue has been fixed in the game itself?
I just checked Re-Volt from Steam (Steam iD 287310) with Proton with forcing x87 reverted and reproduced the issue: right on start it will show "Failed to set viewport" message box and refused to start (still works fine with x87 ddraw.dll).
Of course this specific issue with this specific game (which does a very rare and weird bug and works by chance only on Windows) can we worked around elsewise in some way. But I am afraid this is just a particular case. The most obvious one is that x87 fpu control word (which apps may set through msvcrt or directly) will stop affecting Wine dlls and, instead, sse2 control word (which apps may also set in a different way) will start affecting those.
ddraw specifically can have FPU setup / FPU preserve mode (controlled by a flag during d3d device creation). Note currently _FPUPreserve functions will save / setup default / restore x87 word (see d3d_fpu_setup). If that will stop using x87 at very least that FPU setup should be switched to saving / restore SSE state? And there is the mode without FPU setup, now it is affected with x87 word but will start be affected with sse.
Also, is the similar avoided in 32 bit msvcrt math anyhow?