Reset Throttle on savestate load #11449
Conversation
| @@ -101,8 +101,7 @@ void CoreTimingManager::Init() | |||
| m_is_global_timer_sane = true; | |||
|
|
|||
| // Reset data used by the throttling system | |||
| m_throttle_last_cycle = 0; | |||
| m_throttle_deadline = Clock::now(); | |||
| ResetThrottle(0); | |||
There was a problem hiding this comment.
this should reset to m_globals.global_timer, which is zero, but i dont think that it should be passed in, because there is never a situation where the throttle clock should be set to anything different then the global timer when resetting.
| @@ -382,6 +387,12 @@ void CoreTimingManager::Throttle(const s64 target_cycle) | |||
| } | |||
| } | |||
|
|
|||
| void CoreTimingManager::ResetThrottle(s64 cycle) | |||
| { | |||
| m_throttle_last_cycle = cycle; | |||
There was a problem hiding this comment.
you should probably remove the cycle argument and make it reset to GetTicks()
There was a problem hiding this comment.
Good point.
But that makes me wonder about what happens to m_is_global_timer_sane during savestates. Is there a bug there?
There was a problem hiding this comment.
I think the save-state code can only be triggered on the cpu thread from within an event, so it should always be true when the savestate code runs (and there would be more bugs if we were saving or loading with a non-sane global timer)
|
I had throttle set to "unlimited", and on first emulation start (not using save states) after updating to a build including #11348 , I only got a black screen. It didn't occur again, but I wonder if it would have been fixed by this PR? |
|
the fallback code was supposed to stop this from happening, and it did, but there was a last second fix that introduced a lot of stuff when the cycles get changed. I cant guarantee that this will fix that issue you had, but it does fix the save states one. |
Fixes regression from #11348, where loading a save state from the past would cause issues.