C, C++, and Objective-C runtime updates

April 3rd, 2016

Recently there have been a few API changes that are worth mentioning. These affect the C, C++, and Objective-C runtimes which are: spine-c, spine-cocos2dx (v2 and v3), spine-cocos2d-iphone (v2 and v3), spine-sfml, and spine-torque2d.


Like all the other runtimes, spine-c has an attachment loader mechanism to allow attachment creation to be customized. For example, you can use this to provide your own implementation of a RegionAttachment. most commonly this is used to setup some game toolkit specific data for rendering. However, unlike many other languages, C is not OOP and it can be difficult to subclass an attachment or to override methods. C also has explicit memory allocation and deallocation. This made customization via an attachment loader harder than it really should be.

To remedy this, we've replaced the newAttachment attachment loader method with three new ones:

  • createAttachment: This is called when a new attachment instance is needed. This allows you to customize which class is used and to do some initial configuration of the instance.
  • configureAttachment: This is called after the attachment has been configured using values from the JSON or binary data. This is a good place for further configuration that relies on that data. For example, at this point a mesh attachment's vertex and UV data is available and you might want to put that in a data structure your game toolkit can use to render.
  • disposeAttachment: This is called just before the attachment instance will be disposed. This allows you to free any memory you might have allocated and stored in the attachment's rendererObject field.

A related feature is that attachments now have an attachmentLoader field. If an attachment loader performs allocations that require disposeAttachment to be called, it should set this field. In that case, it is important that the attachment loader not be disposed until after the skeleton data is disposed. Note that AtlasAttachmentLoader does not do this, so can be disposed of right away.

These changes won't affect code that uses AtlasAttachmentLoader. If you use your own attachment loader, you just need to rename newAttachment to createAttachment to get the old behavior.


cocos2d-x is a game toolkit that relies heavily on a 2D scene graph. Previously, rendering with spine-cocos2dx was not able to batch draw calls across scene graph nodes because the skeleton renderer was doing its own drawing. This has changed to pass the geometry off to cocos2d-x so the framework can do the drawing, batching were possible. The result is that now many skeleton scene graph nodes can be drawn in a single OpenGL draw call, assuming they use the same texture.

This shows 50 spineboys being drawn with just 1 draw call (plus 1 more to draw the stats at the bottom left).

Unsurprisingly, this works using the new spine-c features described above. For cocos2d-x, it is now required to use the new Cocos2dAttachmentLoader, which stores some cocos2d-x data on each attachment. It is important not to dispose the attachment loader until after the skeleton data has been disposed. The skeleton renderer uses the attachment's cocos2d-x data to draw more efficiently than before and with batching across scene graph nodes.

These changes won't affect code that uses the createWithFile methods on SkeletonRenderer or SkeletonAnimation. However, if you are loading the skeleton data yourself so you can use it with multiple scene graph nodes using createWithData, then you must change your loading code to use a Cocos2dAttachmentLoader. See the BatchingExample source code for an example of how to load skeleton data using Cocos2dAttachmentLoader. Again, remember not to dispose of the loader until after the skeleton data is disposed.

Discuss this post on the Spine forum.