Loading Image
Currently, every 30 frames on the Spine editor's dopesheet marks 1 second.
15 is half a second.
30 is 1 second.
60 is 2 seconds.
90 is 3 seconds. etc...
Internally, in the saved format (json and binaries) and in the spine runtimes, all key times are saved and processed according to time in seconds and never frames. This is because Spine is key-animated similar to most 3D games, where actual frame intervals can vary a lot and framerates can go as high as your computer and device will allow: typically 60fps maximum on regular computers and devices. And way higher if your machine supports it.
This can be a source of confusion if you come from an animation program like Flash or any other pre-rendered setup, where it does specify discrete integer frames where nothing exists in between.
Loading Image
Fig 2. In most modern game engines, time between game loop/render updates can vary so the time cursor almost never lands perfectly on one of the 30 "frames" in a second
But in Spine, despite the dopesheet snapping at 30 fps, the time cursor can land on "frame 1.456346" or "frame 5.52325". But really, any fraction of a second that the game engine's timer can land on can be a possible "frame" or pose. In the Spine editor, you can see this clearly by slowly scrubbing the dopesheet timeline while holding Shift, or opening Playback view and setting the speed to 0.1x.
Loading Image
Fig 3. Hold Shift to disable snapping.
This means at runtime, it's better to check or set times according to seconds.
If you know the dopesheet frame number, you can convert it to seconds by dividing that frame number by 30. (for beginner programmers, make sure you force your calculation to do float division, or else you will end up with unhelpful whole numbers. You can do this by specifying one of the operands as float, for example: timeInSeconds = frameNumber / 30.0f.)
[more details to follow...]
