-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More accurate emulation speed management #184
Comments
I dunno but I probably broke things. I'm not sure where |
bump |
Well, I broke things but everything still works so I guess it's probably fine then? |
Mateo has suggested that this outstanding issue is the cause of the bug that can lock up CEmu for a while upon giving it focus if "Pause emulation on focus change" is enabled. |
This may take a bit more time to analyze and take care of, so we might as well postpone it for a later release, instead of making it block v1.1. |
Setting this as a release blocker and v1.1 again, following a discussion with @runer112:
|
The GUI lock up is unrelated to this issue. |
With the changes from #304, what do we do about this issue? |
I wouldn't really call this a "bug" anymore. |
Closing this thanks to all the improvements since then, and probably especially the recent ones by @calc84maniac. |
As discussed between @jacobly0 and @runer112.
Basically about frame drops, being too early/late, catching up, etc.
09:01:46 <@runer112> if you're ahead, sleep until next_time
09:01:57 <@runer112> if you're less than 0.1s behind, full speed ahead
09:02:15 <@jacobly> should I go with 100Hz?
09:02:25 <@runer112> if you're more than 0.1s behind, manually pull up cur_time (or pull back next_time?) so the gap is only 0.1s, and then full speed ahead
09:02:52 <@runer112> err
09:02:59 <@jacobly> oh, so only drop a multiple of .1s at a time?
09:03:05 <@runer112> no
09:03:10 <@runer112> drop any excess over 0.1s
09:05:12 <@jacobly> but then we stay stuck at .1s behind?
09:05:33 <@runer112> you shouldn't
09:05:39 <@runer112> if it's behind, it should run unthrottled
09:05:46 <@runer112> it should be able to catch back up
...
10:39:24 <@jacobly> basically the question is should time spent in the debugger be dropped or should we just reset afterwards
10:41:52 <@runer112> I guess ideally, after resuming from something like debugging, you'd set the defecit to 0
The text was updated successfully, but these errors were encountered: