Description
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