Let's consider the common use cases:
-
Most often you want an animation to run after the previous animation, minus any mix time.
-
The next most common use case is probably having a previous looped animation run for X seconds, then change to a new animation.
-
Probably any other use case is uncommon enough users can calculate the time however is required.
To get 1, you can pass 0, whether delay is left as it is now or always added to the end time as you suggested. Eg, walk then jump:
state.setAnimation(0, "walk", false);
state.addAnimation(0, "jump", false, 0);
To get 2, as it is now you can just specify a positive time and this is the time the next animation is run:
state.setAnimation(0, "walk", false);
state.addAnimation(0, "jump", false, 5);
For your suggestion, you'd need to fetch the duration of the previous animation and subtract it from the time you want the next animation to start. This is a little unintuitive what "end time" is when the previous animation is looping. Eg, if you want to walk for 5 seconds, then jump:
TrackEntry entry = state.setAnimation(0, "walk", true);
state.addAnimation(0, "jump", false, 5 - entry.endTime);
// or:
state.setAnimation(0, "walk", true);
state.addAnimation(0, "jump", false, 5 - skeleton.findAnimation("walk").duration);
I think I like the current implementation the most. Delay is the time to change to the next animation. Since it is never useful to queue an animation with a delay of 0 (you might as well use setAnimation), then we can overload 0 to mean, "the end of the previous animation, minus mix time". Since negative delay is also never useful, we might as well overload <= 0 to mean "the end of the previous animation, minus mix time. plus the negative delay". It complicates understanding what the delay parameter does, but seems like it is easiest to use.
It's still open to discussion of course, just sharing my thoughts on why I think the current approach is ok.