Most animation soft wares use FPS (frames per second) to change animation speed. This is good because most game making soft wares also only use FPS to change animation speed. Unfortunately, aseprite only uses frame duration instead of FPS. This isn’t too big of a problem though since if you want to figure out how many milliseconds is the FPS that you want, you simply need to do this equation: 1000/FPS=Frame Duration(ms). This is why I think aseprite should at least have the option to change it to FPS instead of frame duration.
Previous thread touching on issues related to this: Animated GIF export rounding frame durations - #3 by Treadlight
Github issue for this: Specify frame delays by frame count · Issue #496 · aseprite/aseprite · GitHub
Some questions. These aren’t meant to poke holes in your idea (which is a good one!), but to get some details necessary to even begin thinking about an implementation, as it isn’t as trivial a change as it sounds.
Where would you expect this to be input? Per-frame like durations are, just as an alternative input method to ms? At the start of the document, with all the durations set to the ms equivalent, and working in ms from that point on?
How should framerates that don’t translate cleanly to durations be stored? Durations in Aseprite are stored as integer ms values. Most common framerates do not have integer equivalents (e.g. 30fps is 33.333… ms), so if the FPS is ever converted to ms durations under the hood, the timing of the whole animation will be off quite quickly. To deal with this accurately, Aseprite would need to either change how it deals with durations, or keep track of your desired fps and introduce leap frames to keep the durations on track. But if it does that, then how should this play along with the ability to change durations per-frame?
FWIW, FPS is usually used by timeline-based animation software, while frame-based software like Aseprite use durations, since that makes more sense for that approach. I feel like if this is added, it should be done with the possibility of a future timeline-based UI in mind, with FPS given first-class status in how it’s stored in memory and in .ase files, rather than simply translating things to ms upon input.
I don’t think it needs to be complicated, because it can still be a per-frame duration. It’s just a matter of presentation and math.
Anyone who learns animation learns in terms of frames per second. Coming from animation schools, traditionally we think in terms of 24 fps or in divisions of it (12 fps, 8 fps, 6 fps, etc).
As someone who regularly animates in Aseprite, I’m frequently frustrated by having to do the manual math of a per-frame setting. The math is simple! I’m not asking anyone to fundamentally change how the timeline works, just an option to switch to a UI where that math happens. IE, functionally the same, but instead of specifying milliseconds, specify the FPS for that specific frame.
As it is, I’m already doing this—I want a section of a timeline to be a 12 fps, so I have to input 1000/12. It’s still off by a third of a millisecond, but it’s the closest approximation. The math is so simple.
Functionally, I’m not asking for a change to how the timeline fundamentally works, just to maybe not make the user do the pointless math. I strongly believe you can specify the FPS on a per-frame basis in this way. We’re really asking for a QOL UI, not for a change to how the timeline functions in any way. Here’s my proposal:
