https://bugs.winehq.org/show_bug.cgi?id=48046
--- Comment #8 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (In reply to dereklesho52 from comment #7)
As Matteo mentioned, the game repeatedly acquires and unacquires the mouse while MOUSE1 is held down. When this happens wineserver usage goes up to 100% of a core, so I'd guess messages aren't being processed by the application.
I think a good next step would be to find out whether a wine bug is causing the game to exhibit this behavior, and then if not, whether Windows handles this without locking up the game.
It might be worth checking, if the Unacquire never sets This->acquired to FALSE.
From the log attached,
Here is the first Acquire, 00f8:trace:dinput:SysMouseWImpl_Acquire (this=0xcf994c0) 00f8:trace:dinput:IDirectInputDevice2WImpl_Acquire (0xcf994c0) 0133:trace:dinput:hook_thread_proc Processing hook change notification lp:0 00f8:trace:dinput:warp_check Warping mouse to 643 - 415 00f8:trace:dinput:warp_check Clipping mouse to (3,55)-(1283,775)
Next we have this. In theory the Acquire shouldn't be lost at this point and will return S_FALSE. So, testing this scenario might help. 0112:trace:dinput:SysMouseWImpl_Acquire (this=0xcf994c0) 0112:trace:dinput:IDirectInputDevice2WImpl_Acquire (0xcf994c0) 0112:trace:dinput:SysMouseWImpl_Unacquire (this=0xcf994c0)