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
Flags
Regression Version 0.208
Affected Sets / Systems
Attached Files
 
Relationships
There are no relationship linked to this issue.
Notes
6
User avatar
No.16287
Tafoid
Administrator
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 MAMEDEV.org 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: https://messui.1emulation.com/mamexp208.7z , does not show the extreme wavering of speed% in my testing.
User avatar
No.16289
hap
Developer
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
No.16290
hap
Developer
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));
#else
std::this_thread::sleep_for(std::chrono::high_resolution_clock::duration(duration));
#endif
}
User avatar
No.16340
Robbbert
Developer
Apr 19, 2019, 10:01
Submitted hap's solution for final testing.
User avatar
No.16341
StHiryu
Tester
Apr 19, 2019, 16:37
This issue is only when sleep is set to on?
User avatar
No.16342
Tafoid
Administrator
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.