You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
....as the ClassicWB-P96 instance boots up, the bootup time is very much extended, to the point that @0:12 in the video, you can see the gray CLI window briefly, just before the P96 screenmode kicks in ... Note: previously, the CLI window is never seen..ie; it boots too quickly to see it =)
Looking at the commit, I construe the 10ms wait is applying to the main loop, and this is responsible for the behavior.
Test:
Question ~ do we need 10ms to achieve the fix here?
Edit value to SDL_Delay(1); ~ recompile and retest... //decrement an order of ten
Result:
CPU usage works (decreases) as expected when emulation is in Pause state ...ie; still an effective fix to original issue
Boot-up time of emulation much closer to what it used to be, and I no longer see the aforementioned CLI window
Of course, if you put a stopwatch on it, bootup time will be a tiny bit longer (1ms per loop), but it's hardly discernible at the human, user level...if you get what I mean ;)
e8ed4c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fix, although addressing the issue at hand, comes with an unfortunate penalty ~ please view https://www.youtube.com/watch?v=fGrHc-u-78s
....as the ClassicWB-P96 instance boots up, the bootup time is very much extended, to the point that @0:12 in the video, you can see the gray CLI window briefly, just before the P96 screenmode kicks in ... Note: previously, the CLI window is never seen..ie; it boots too quickly to see it =)
Looking at the commit, I construe the 10ms wait is applying to the main loop, and this is responsible for the behavior.
Test:
Question ~ do we need 10ms to achieve the fix here?
Edit value to
SDL_Delay(1);
~ recompile and retest... //decrement an order of tenResult:
Pause
state ...ie; still an effective fix to original issueOf course, if you put a stopwatch on it, bootup time will be a tiny bit longer (1ms per loop), but it's hardly discernible at the human, user level...if you get what I mean ;)
Might you please review/revisit this commit?
TIA
e8ed4c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not ideal indeed.
I'll do some tests to find a better solution.
e8ed4c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A better fix is in, with e2feb3c