Open thomasboyt opened 9 years ago
Patching the Ticker constructor is also tricky because the Ticker already exists when the dev tools are opened - you'd have to destroy & recreate the ticker.
Starting to think a more reasonable option would be to actually patch Coquette.
Another option is to just go full Ruby on it and monkey patch the Date
object to give the deltas we want. I believe timekeeper could be used for this, e.g.
var time = new Date(0);
tk.freeze(time);
this.start();
var time = new Date(16);
tk.freeze(time);
This would pretty much have to be an opt-in behavior (e.g. a checkbox in the interface), but if it actually works, could go a step further and pause time when pause is clicked, which would then prevent timeout or interval-based timers from all firing at once when you unpause!
actually, I'm pretty sure there's no way to unfreeze time without resetting it to the actual current time, so this wouldn't solve that problem :<
also, the date should be frozen to current and incremented to current+16, to prevent internal date tracking from freaking out (like here in 33rpm)
So, there's a "step" button now, but it's a bit weird because there's no delta time in the frame (it's set to 0 for the first frame after
start()
, see https://github.com/maryrosecook/coquette/blob/master/src/ticker.js#L13-L17). This means that noupdate
code is going to go that depends on a delta time (e.g. moving things).Easiest way to do this would be to set a "perfect" delta time for 60fps, which would be
1000/60
ms (~16.67). Easiest way to do that would probably be to monkey patchstart()
to accept an initialprev
time. Unfortunately, any monkey patch wouldn't have access to thegameLoop
variable that's in the closure, so likely the entire Ticker constructor needs to be patched to store that in its context :(