 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. |
|---|---|
 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. |
|
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 } |
 No.16340
Robbbert Moderator
Apr 19, 2019, 10:01
|
Submitted hap's solution for final testing. |
 No.16341
StHiryu Tester
Apr 19, 2019, 16:37
|
This issue is only when sleep is set to on? |
|
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. |