Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|07275||Core||Minor||Always||18 days ago||3 days ago|
|Tester||Keade||View Status||Public||Platform||MAME (Official Binary)|
|Assigned To||hap||Resolution||Fixed||OS||Windows 10 (64-bit)|
|Version||0.208||Fixed in Version||0.209GIT||Build||64-bit|
|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.|
|Affected Sets / Systems|
|There are no relationship linked to this issue.|
18 days ago
edited on: 18 days ago
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.
18 days ago
|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.|
17 days ago
Simply using Sleep (in osd/osdcore.cpp) improves it a lot. Like this:
void osd_sleep(osd_ticks_t duration)
// sleep_for appears to oversleep a lot on Windows
Sleep(duration / (osd_ticks_per_second() / 1000));
4 days ago
|Submitted hap's solution for final testing.|
3 days ago
|This issue is only when sleep is set to on?|
3 days ago
|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.|