https://bugs.winehq.org/show_bug.cgi?id=49564
Arek Hiler ahiler@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ahiler@codeweavers.com
--- Comment #3 from Arek Hiler ahiler@codeweavers.com --- I've been debugging the same issue that happens with Doom II from Steam (also ships with dosbox.exe).
The problem got introduced with cd215bb49b ("kernel32: Use the user shared data to implement GetTickCount().") - instead of 1ms resolution we started slipping into 16-17ms. Windows apparently provides resolution of 10-16ms (according to doc), which turns out to actually be 15-16ms with occasional hiccups https://testbot.winehq.org/JobDetails.pl?Key=76665
This was easy to fix but decreasing the update time to 15 ms: -static const timeout_t kusd_timeout = 16 * -TICKS_PER_SEC / 1000; +static const timeout_t kusd_timeout = 15 * -TICKS_PER_SEC / 1000;
Doom II worked reliably.
Since then another change got introduced - 1ae1088964 ("server: Update shared user data timestamps on every request.") - apparently to address https://bugs.winehq.org/show_bug.cgi?id=49228
So I have tried: -static const int user_shared_data_timeout = 16; +static const int user_shared_data_timeout = 15;
Sadly, the game sill crashes. My current guess is that dosbox.exe doesn't like very unstable deltas between ticks, which we have now because we update timestamps at "random" intervals - on each server request. I am yet to verify that