Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
07275 Core Minor Always Apr 4, 2019, 20:11 Apr 20, 2019, 13:49
Tester Keade View Status Public Platform MAME (Official Binary)
Assigned To hap Resolution Fixed OS Windows 10 (64-bit)
Status [?] Resolved Driver
Version 0.208 Fixed in Version 0.209 Build 64-bit
Fixed in Git Commit Github Pull Request #
Summary 07275: Weird pacing issue on Windows
Description Strange pacing issue, the games do not run at 100% always, but the speed fluctuates (+/- 3 or 4%).
Steps To Reproduce - download fresh 0.208 binaries (32-bit or 64-bit, I have tested both) from MAMEdev
- start any game
- check the speed (watch out for small hiccups onscreen, or press F11, as that's easier to check). Any driver will do. I noticed it first on Pong (due to the ball scrolling) and verified it on Last Blade 2 (using background scrolling). This does not seem to be driver dependent at all. Not dependent on video (d3d, gdi etc.) either.

I tried compiling my own binaries (for tag mame0208) on Debian and could not reproduce the issue there.

This behavior is specific to the 0.208 binaries (on Windows, as far as I can tell), it does not happen with 0.207 binaries.
Additional Information Reported on #mame and got told by Tafoid he could reproduce the issue (thanks for the help !), which incited me to report it officially.
Github Commit
Regression Version 0.208
Affected Sets / Systems
Attached Files
There are no relationship linked to this issue.
User avatar
Apr 4, 2019, 20:22
edited on: Apr 4, 2019, 20:25
Updated as a CORE issue.
My research seemed to indicate that this is a toolchain caused issue. 0.208 brought about both changes to 32-bit and 64-bit toolchains for building official binaries. (7.4.0 and 8.3.0, respectively). 0.208 release binaries from show which jump +/- 3-4% very frequently (testing lastbld2, watching speed% toggling F11 whereas a 0.208 32-bit created with a 5.3.0 toolchain made by Robbbert/Wizz (made for XP folks), located here: , does not show the extreme wavering of speed% in my testing.
User avatar
Apr 4, 2019, 22:24
It's caused by osd_sleep from emu/video.cpp(aka the "sleep" setting in mame.ini). I did some quick testing and notice that it sometimes oversleeps by more than 10ms. I assume this is Windows-specific, plus whatever compiler update that broke std::this_thread::sleep_for.
User avatar
Apr 5, 2019, 19:01
Simply using Sleep (in osd/osdcore.cpp) improves it a lot. Like this:

void osd_sleep(osd_ticks_t duration)
#ifdef WIN32
// sleep_for appears to oversleep a lot on Windows
Sleep(duration / (osd_ticks_per_second() / 1000));
User avatar
Apr 19, 2019, 10:01
Submitted hap's solution for final testing.
User avatar
Apr 19, 2019, 16:37
This issue is only when sleep is set to on?
User avatar
Apr 19, 2019, 19:29
It is on by default on Windows as least - AFAIK it was only reported with -sleep, -nosleep doesn't exhibit the same huge 3-4% swings in speed.