I'm attempting to implement basic save/load capabilities. I've got pretty much everything working, but my game includes a stopwatch-style (counts up) timer. I can serialize the currentTime
on the timer to disk easily, but that property is read only. I can't identify any way to set a timer to a non-zero value in order to restore its state when loading the game. There's playdate.timer:reset()
but there seems to be no way to simply set()
the time on the clock. Am I'm missing something obvious?
I looked at the source for the timer implementation in the SDK CoreLibs directory, and I don't see a way to do this (and the implementation and comments imply that '.currentTime' wasn't originally read-only, but now very much explicitly is - I'm assuming for <reasons> - maybe someone from Panic will fill us in ).
Thanks for looking into this. In the meantime I've managed to work around it by independently serializing the timer's currentTime
and a separate timeOffset
that I use to reflect the total time on the clock when loading the game. It's a little clunky, but it works.
I didn't write the original implementation, but I'm guessing Dan had currentTime
and timeLeft
marked read-only because there's a lot of work properly validating the input value there--if you give it a value out of bounds, what should it do? But here's a quick and dirty patch. Instead of
elseif key == "timeLeft" or key == "currentTime" then
print("ERROR: playdate.timer."..key.." is read-only.")
I think
elseif key == "currentTime" then
table._currentTime = value
elseif key == "timeLeft" then
table._currentTime = table.duration - value
would do what you want (just don't go out of bounds). As I just mentioned on another thread, the nice thing about CoreLibs is you can tweak it as you need.
Thanks, Dave, that’s very helpful. It’s obvious why timers are focused on countdown behaviors, although I’m curious about the absence of a basic upward counting timer in the API, especially given the presence of both Standard Timers and Delay Timers, which seem to take the same arguments and provide the same behavior. I would have expected the standard variety to function like a stopwatch. Setting the duration to a maximal value works, of course, so it’s not a big deal; just an observation.
Hey @dan, Eben's got a question about timers!
(I think that should send him a notification..)
Hey sorry for the delay! I honestly can't remember why currentTime is read-only, other than it was probably easier to do it that way at the time.
As far as countdown vs upward counting timers, I never really considered the difference - default timers do indeed count upwards (but not to infinity, as a stopwatch would - is that the difference?). If you're just looking for a stopwatch a playdate.timer might be overkill compared to just recording a start time and computing elapsedTime = startTime - playdate.getCurrentTimeMilliseconds()
? Or maybe it would make sense for us to add a simple playdate.stopwatch to CoreLibs? Just thinking out loud here