Support for time-based frame advancement

[ebeneliason]

This utility is fantastic, but its utility is limited by the fact that it only supports frame-based animation. Although switching to time-based animation would likely require a fair amount of work, the approach seems relatively straightforward given that you could use a playdate.graphics.animation.loop to handle the frame tracking. Its properties seem well positioned to provide everything you'd need to support the current JSON config and API as it is today.

Technically this would be a breaking change and could impact some games when compiled against the new version, though you could minimize that significantly by setting a default delay on the loop object based on playdate.getFPS().

[Whitebrim]

Keep in mind that games processing is based on frames, not milliseconds. If your timer ends in the middle of a frame, then it will not be processed until the next frame and the actual timer call time will be longer than you specified. You also need to keep in mind that the device can sometimes slow down and lag, giving out unstable fps, in such cases, the animation based on time will be ahead of the rest of the game.

If you want to use milliseconds, then I recommend converting them to frames. With 30 fps set, one frame will be 33.33ms long, at 40 fps 25ms, at 50 fps 20ms.

[ebeneliason]

Keep in mind that games processing is based on frames, not milliseconds.

That's not entirely true. Lots of games do time-based rather than frame-based processing — especially any which involve any sort of physics simulations. Using time-based calculations ensures that the game runs the same regardless of the frame rate, which may vary based on the context in which it is run (e.g. simulator vs. hardware), or even based on what's happening in the game at the moment. (If a game runs at a fully locked frame rate this doesn't matter, of course, but that's not always the case in practice).

If your timer ends in the middle of a frame, then it will not be processed until the next frame and the actual timer call time will be longer than you specified. You also need to keep in mind that the device can sometimes slow down and lag, giving out unstable fps, in such cases, the animation based on time will be ahead of the rest of the game.

Yes, but this actually emphasizes the point. If an animation is locked to frames and the frame rate varies, then the speed of the animation will also vary. If a game happens to run far above the expected frame rate then animations will be too fast; if the game lags and runs below the expected frame rate, they will be too slow. I'd much rather drop frames to keep the animations in sync with the action in the game than have them play in slow motion if the action dips the frame rate.

The goal of time-based frame updates is to ensure consistent animation playback speed regardless of the effective momentary frame rate of the game. The APIs provided by the Playdate SDK for managing animations abide by this principle, and provide time-based frame management via the delay property, which specifies the time interval that must elapse before advancing to the next frame. That value can and should be set based on a calculation like the one you suggest, based on the target FPS for the game.

[orphu]

I will +1 this idea. This library seems very useful, but after reading through the docs this is a big limitation that stood out to me. I'd argue "most" games animate and translate sprites based on delta time between frames to ensure they are frame rate independent.

[Subcide]

Just wanted to +1 this also. The game I'm making has a slow-motion mechanic with everything implemented with delta-time. It's a bit weird having the animations stay the same speed when everything else slows down. Breaks the illusion a bit :) (there's other ways around it of course)