Copy constructors for Skeleton and AnimationState.

[PazerOP]

Add "copy constructors" for Skeleton and AnimationState in 3.7. Callbacks set on AnimationState will be retained. It is the duty of the user to unset them if they shouldn't be copied. Special care needs to be taken for the manual memory managed runtimes (C/C++).

• [ ] spine-libgdx

---

• [ ] spine-csharp
• [ ] spine-xna
• [ ] spine-monogame
• [ ] spine-unity
• [ ] spine-tk2d

---

• [ ] spine-c
• [ ] spine-cpp
• [ ] spine-sfml
• [ ] spine-cocos2d-objc
• [ ] spine-cocos2dx
• [ ] spine-ue4

---

• [ ] spine-ts core
• [ ] spine-ts webgl
• [ ] spine-ts canvas
• [ ] spine-ts threejs

---

• [ ] spine-as3
• [ ] spine-starling

---

• [ ] spine-lua
• [ ] spine-love
• [ ] spine-corona

Original comment

As far as I can tell, there doesn't seem to be a way to create a new instance of an spSkeleton or spAnimationState that is a copy of an existing instance (in the C api). I am currently having to do a lot of work to get this set up, and in my opinion this functionality should be built in.

[badlogic]

Could you elaborate on your use case for copying these structs?

[PazerOP]

Certainly.

Our current use case involves an ECS-based game engine. We have support for duplicating/cloning entities and all their components (for spawning multiple enemies using a preconfigured template entity, for example). For all of our simpler components this works fine, but this is not fully possible for our SpineAnimator component.

Our SpineAnimator component consists of std::shared_ptrs to an spAtlas, spSkeletonData, and spAnimationStateData (it's my understanding that these can be freely shared between different instances of spAnimationState and spSkeleton). The SpineAnimator component also contains std::unique_ptrs to spSkeleton and spAnimationState. Copying these is the problem.

Currently, when we need to copy these SpineAnimator components, we just create new instances of the spSkeleton and spAnimationState and set the "idle" animation. Since our animation system is driven by our movement system, it is non-trivial to reapply the previous animations using the spAnimationState_xxx functions.

I would just write my own functions to copy the various components, however it is difficult to determine what pointers are owned by the various spine objects and which are shared. I don't think I could write correct functions for all of those without fully understanding the entire spine runtime codebase.

[NathanSweet]

Related: #1185

[badlogic]

@PazerOP Thanks for the input on this! We've decided to go ahead and add "copy constructors" to all runtimes. I've modified your initial issue comment accordingly, so we can keep track of the progress.

We'll not back port this to 3.6, but instead add it to the 3.7 branch.