AnimationState can now queue animations to be switched to later via a new function, addAnimation. This takes a delay, which is the time from the start of the previous animation queued (or current animation if none are queued).
CCSkeleton for both cocos2d and cocos2d-x has been split into CCSkeleton and CCSkeletonAnimation. CCSkeleton just draws the skeleton and can be subclassed more easily to apply your own animations. CCSkeletonAnimation extends it and provides a simple API for applying one or more animations and queuing animations to be played later. Eg, to apply two AnimationStates in cocos2d:
animationNode = [CCSkeletonAnimation ...];
// By default the CCSkeletonAnimation has one animation state with index 0.
// Having one state is very common so methods that don't take a stateIndex use index 0.
[animationNode setAnimation:@"walk" loop:NO];
// Delay of 0 will play it after the previous one, any mix duration
// is taken into consideration.
[animationNode addAnimation:@"jump" loop:NO afterDelay:0];
[animationNode addAnimation:@"walk" loop:YES afterDelay:0];
// This adds a second animation state with index 1.
[animationNode addAnimationState];
// Note that index 1 is specified.
[animationNode setAnimation:@"wings" loop:YES forState:1];
There are no callbacks at this point. If callbacks are invoked when an animation is complete, users will have to track when animation has completed. Eg, they might want an animation to loop twice, then do something. Or they might want to play 3 animations, then do something.
I think it might be more flexible to have callbacks be based on time. CCSkeletonAnimation could have a list of callbacks, each of which has a time and block. When the time has elapsed, the block is executed. Eg:
[animationNode addCallback:some afterDelay:1.4f];
Once we have this, we can add methods like:
[animationNode addAnimation:@"jump" loop:NO afterDelay:0 forState:1 callback:something];
Internally that would compute the time when the added animation is complete and add the callback using that time. However, this doesn't make sense for animations that loop, since the callback would only be scheduled to execute once. The solution I guess would be to schedule the callback from when you want it to happen:
[animationNode addCallback:some afterDelay:someAnimation->duration * 3];
If you want it to happen on every loop, you could reschedule it inside the callback.
What do you guys think?
Right now I really need to move on to getting the other runtimes done so I can start getting editor features done. If I spend too much time along the way, things will never get finished. I don't want to sacrifice the quality of the work I do, but at the same time I need to prioritize a massive workload. Where possible I will need to punt non-essential features down the road. In the meantime, if someone wants to contribute via github, I will find time to evaluate and merge contributions.