• Editor

  • Run two animations - Cocos2d

    İngilizce
Related Discussions

  • Nate

  • Gönderi #21
  • Bu yayın İngilizce içinde
spineUser yazdı

can you refactor your CCSkelenton class?

We're all going to need to subclass it to get the functionality we want and it's currently not extension friendly lots of construction code is in the static constructor, meaning I have to duplicate that code and diff it when you do runtime updates... not nice.

Yeah, good point. I'll fix that up.

spineUser yazdı

I don't get why we have state1 and state2 from the same stateData in the same state.. what's the function of that? I'm presuming it's a typo.. or is the state1 assigment menat to be above the previous line?

AnimationStateData stores a mapping where the keys are "animation A + animation B" and the value is "mix duration". Multiple AnimationState instances can use the same AnimationStateData. In the example I used a single AnimationStateData for both. You could use a separate one for each. As mentioned, you could also store the AnimationStateData externally, so it can be reused if you are creating multiple of your CCSkeleton instances.

CCSkeletonAnimation

I like that idea.

biggest pain points so far are:
playing 2 animations at once,
chaining animations together.. i.e knowing when one ends and another starts..
to that end blocks for animation completion would be immensely useful..
many animations are one time only and sometime chain together..

i.e.
flying - looped,
stop flying - one time,
attack - one time,
start flying - one time.

these might go in sequence such as : flying-> stop flying -> attack.
attack -> start flying ->flying

In lieu of another mechanism to chain various animations together, blocks for animation completion would be immensely useful in this case (we could easily and cleanly use them to drive a simple state machine). When I get more time I will put some code together here for managing this kind of stuff as I anticipate using it heavily.

I deleted the youtube video - that was a dick move: there were better ways to make my case than being pissy. I apologize for my conduct here.

  • Nate

  • Gönderi #23
  • Bu yayın İngilizce içinde

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.

Chaining animations sounds great to me!

  • Nate

  • Gönderi #25
  • Bu yayın İngilizce içinde

A good part of the day was spent fixing bugs and refactoring the atlas and attachment stuff. I've got the CCSkeletonAnimation stuff about half done and will have something to show tomorrow.