Hello all, im working on a idle game that ideally has the user not sleep the system. For this reason I need to be extremely careful when im using update.
I know theres ways to stop, and resume the playdate.update entirely, and I can see that I can use a button press callback to reactivate playdate.update.
I really want to be able to just every hour or so, do some quick calculations and save it. But I dont really say any way to do this without leaving playdate.update running so I cna track time either via timer, or in the update loop directly. I can set refresh rate to 1 frame per second, but thats still 3600 updates for a hour wait.
Does anybody have any ideas, or is this just a hard limitation i have to deal with
If you're using the sprite system (so supporting partial refresh) and you don't draw anything during and update, then the screen won't refresh or redraw anything at all, using almost no power.
Regarding the 3600 updates: you could keep count of them, only do something when it reaches 3600, and then reset it to zero and start the count again. But check the accuracy as I feel this might not be accurate enough.
But I'd be inclined to use a clock/time-based system which will no doubt be more accurate.
I've thought about this as well. I don't think there's a good way of doing a very slow periodic update with Lua. You'll need to have the update running. You don't have to refresh the screen, so at least if you bomb straight out of your update if you don't need to step your simulation, you're using the minimum power possible.
A playdate.update that runs once per second and does nothing but gets the system time and checks it against a variable will use very little power indeed.
My Playtime clocks use timers for long-term things and even minute-to-minute timekeeping. Nothing happens during update() except refreshing of the timers.
Then I set the refresh rate low until a timer triggers something to happen. At that time I temporarily boost the refresh rate to show animation.
Sorry for the late reply, fun IRL stuff kinda got in the way of this project for a bit there.
Ive kind of found a solution, playdate.wait() actually does exactly what I want, however the problem now being that there doesnt seem to be anyway to actually cancel the playdate.wait().
I want to be able to do like a playdate.wait() for one hour, but if at any point the user presses a button, i cancel the wait and reenable the playdate update. During playdate.wait() either the button callbacks (pd.BButtonPressedDown for example) dont respond, or playdate.start() and or stop and than start do not cause playdate.wait() to cancel.
I know theres some more or less good work arounds, but i would really like to be able to shutdown the update entirely.
Once again this is possible with start/stop. But I also need the game to be able to wake itself for a second once every hour or so, so just doing playdate.stop and then doing playdate.start() on user input also doesnt quite fit what im trying to do.
Note: Im currently using sprites for prototyping but will be fully removing them and doing manual draw calls eventually for maximum optimization of not even having to call sprites update method
I would advise to not do premature optimisation. Leave the optimisation until after your game is finished.
Also the pace at which the SDK changes is by its nature slow and considered, so it's advisable to write your game for the SDK as it stands right now rather than planning for a change or feature that may never arrive.
All this to say, get your game working and then drill into this stuff.
Oh for sure. The only reason why I worry about playdate.waits() now is because i need to abandon the project entirely if i cant get it to work like I want as it is core to the whole idea.
Looks like thats what i'll have to do. Thanks for all the help everyone! Im going to run some tests on all these and probably do a combination of everything.
Im curious about running a looped playdate.wait() for like 2milliseconds at a time, and this would allow a delayed input to come through. But i fear this is probably worse on power than the above stated solutions.
In my experience wait() winds down the CPU and then after the wait is over the CPU has to wind back up to full speed. In my tests (for a while I used it in Daily Driver for my custom frame limiter) this used more power than not waiting at all.