CEmu icon indicating copy to clipboard operation
CEmu copied to clipboard

More accurate emulation speed management

Open adriweb opened this issue 6 years ago • 9 comments

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

adriweb avatar Feb 15 '18 13:02 adriweb

I dunno but I probably broke things. I'm not sure where last_time goes.

mateoconlechuga avatar Feb 28 '18 04:02 mateoconlechuga

bump

mateoconlechuga avatar Mar 01 '18 02:03 mateoconlechuga

Well, I broke things but everything still works so I guess it's probably fine then?

mateoconlechuga avatar Apr 05 '18 03:04 mateoconlechuga

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.

runer112 avatar May 11 '18 13:05 runer112

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. Will be mentioned as a caveat in the release note...

adriweb avatar Jun 03 '18 07:06 adriweb

Setting this as a release blocker and v1.1 again, following a discussion with @runer112:

<Runer112> my [release] veto has been constantly applied because of that bug
<Runer112> it has pretty negative usability implications
<Runer112> probably worse than the sum of all bugs in 1.0, from the perspective of the average user anyway
<Runer112> and from our perspective because everybody who downloads it will be reporting bugs about freezes and stuff

adriweb avatar Jun 21 '18 13:06 adriweb

The GUI lock up is unrelated to this issue.

jacobly0 avatar Jun 22 '18 20:06 jacobly0

With the changes from #304, what do we do about this issue?

adriweb avatar Jan 17 '19 07:01 adriweb

I wouldn't really call this a "bug" anymore.

mateoconlechuga avatar Apr 21 '19 21:04 mateoconlechuga