Thanks for removing the video.
Maybe AnimationState could handle chaining animations? setAnimation would set the current animation as it does now, addAnimation would queue an animation to play after all the currently queued animations. These would be fire and forget though. Not sure how to get a callback for when the animation changes if the the change happens inside AnimationState. Using a C function pointer for a callback is not very nice.
Doing it in AnimationState would be nice because all runtimes would benefit. The alternative is to scrap that and do it in runtime specific code. However, the callback issue will come back and haunt me, because it will be needed for the "event timeline" feature. This is where animations can trigger some event, so the trigger is like a callback. Solving how to do callbacks in spine-c now would be great.
Maybe registering a callback is just a pointer and invoking a callback when an event occurs uses a struct like:
struct Callback {
CallbackType type;
void* listener;
void* payload;
};
This struct would be given to game toolkit specific code which would interpret the listener and payload based on the type and call a method on the listener, invoke an ObjC block, etc. However it is done, due to the convenience of ObjC blocks, callbacks should be done using those for cocos2d, so don't worry there. 🙂
Tomorrow I'll separate out CCSkeletonAnimation so it has n number of AnimationStates. I'll also refactor things so it is easier to extend. Not sure about callbacks yet, but I'll play around with something.