(08-04-2017, 02:36 AM)degasus Wrote: Yeah, I agree. For further investigation, I suggest to use XFB emulation and to patch dolphin to print a frame number on the screen.Good: a frame number overlay would help; it seems to me that Retroarch prints the framenumber together with the FPS.
Why do you suggest XFB emulation?
(08-04-2017, 02:36 AM)degasus Wrote: The Wii doesn't support 30fps scanout, it just repeats each frame twice. And this is controlled by the game, so it *might* be accurate - but unlikely.For the sake of clarity, I did all my tests with GameCube’s Zelda.
(08-04-2017, 02:36 AM)degasus Wrote: While you're at it, it might be a good idea to also visualize those variables: https://github.com/dolphin-emu/dolphin/b...s.cpp#L200 - They are responsible for syncing the emulated time with the real time.It seems a great idea to me. These stats could be printed with the Graphics->Advanced->Debugging->Show Statistics checkbox enabled.
By the way I checked Dolphin’s logs and I didn’t see any COMMON system too fast or slow log, so (abs(diff) > max_fallback) condition is never met; maybe else if (diff > 0) Common::SleepCurrentThread(diff); is the cause?
(08-04-2017, 02:36 AM)degasus Wrote: It allows to run the emulation faster for a few milli seconds if we're behind the real time. So aabbccDDDEffgg should be a common pattern, not the other way around...I see... but in my video I encountered the reverse pattern: AABBCC[color=#ff3333]DEEE[/color]FFGGHH. Is it possible that a wrong timing evaluation during C frame (believed CCC instead of CC) sets a chain effect that speeds emulation during D frame (displayed once) and then, for compensation, slows emulation during E frame (displayed three times)?
Best regards.
Locutus73