New Spine Runtimes documentation

October 29th, 2016

We have a big update for our Spine Runtimes documentation! Similar to the Spine User Guide for the editor, we now have a full guide for the Spine Runtimes:

Spine Runtimes Guide

It will teach you how to load, render, and manipulate skeletons in your applications using the Spine Runtimes. Especially useful is the API Reference which we have lovingly crafted and painstakingly cross referenced so you can more easily explore and understand how the runtimes work. Enjoy!

Discuss this post on the Spine forum.

Spine's roadmap

October 22nd, 2016

If you haven't seen it yet, take a peek at our waffle:

What the heck is a waffle? It's an alternate view for GitHub issues. You can see the same issues on GitHub by clicking the little cat icon on the waffle or going directly to the editor issues or runtime issues. The waffle just provides a nicer high level view.

Previously we had two waffles, one for the editor and one for the runtimes, now they have been consolidated into one. You can filter to see only editor issues or only runtime issues. You can also filter by milestone to see what is coming up next, such as what will be in Spine 3.6.

If you find an issue you are interested in, go to that issue on GitHub and click the "Subscribe" button:

This will give you email notification when there is progress on that issue.

Discuss this post on the Spine forum.

Spine Lua runtimes updated to Spine 3.4

October 11th, 2016

Our Lua-based Spine Runtimes have been in hibernation mode for a little while, but no more. We are happy to announce the update for spine-lua, spine-love, and spine-corona to Spine version 3.4!

All Lua-based Spine Runtimes now support meshes, texture atlases and all the other goodies we've released over the past few months. Let's look at the details.

Spine Lua

With the update, the spine-lua runtime now supports all features available to you in the latest Spine editor, version 3.4.02. This includes features like path and transform constraints, meshes and linked meshes, as well as texture atlases. There are no API breakages, only API additions for the aforementioned features.

We've also revamped the code base and applied Lua best performance practices, such as localizing variable access so data can be more easily lifted to registers in LuaJIT, as well as using metatables for faster function invocation.

Finally, the spine-lua runtime now uses vertices arrays for both region and mesh attachments. This simplifies the code base considerably and allows an easier implementation of mesh rendering in the various Lua based engines.

Spine Löve2D

The new spine-love runtime now supports all features of the latest Spine, including rendering meshes and linked meshes! We've considerably revamped the internal rendering infrastructure, applying batched rendering for greater performance.

API-wise, we had to change the API slightly to make future modifications and improvements easier. Instead of extending the spine-lua Skeleton"class" with a draw method, we've now introduced a new spine-love specific class called SkeletonRenderer. It ensures that Skeleton attachments are properly batched during rendering.

Check out the spine-love example for some usage examples of SkeletonRenderer and the simplicity of using texture atlases.

Spine Corona

The new spine-corona runtime is considerably smaller due to the internal changes of spine-lua, going from 400LOC to 100LOC! Furthermore, the new spine-corona runtime now supports mesh and linked mesh rendering. In fact, the new spine-corona renderer uses meshes for all types of attachments, unifying the rendering code, allowing better batching, both by us as well as the underlying C++ code of Corona, giving us much better performance.

The spine-corona API has stayed the same, so you can just drop in the latest spine-lua and spine-corona into your project. You'll also probably want to change your loading code to use texture atlases.

Check out the spine-corona example to see spine-corona texture atlases in action!

Up next

On the Corona side, we can expect some more performance improvements. Currently, Corona does not batch indexed meshes, so we do some of the work ourselves. Once Corona adds this feature we will also have batching across skeletons, not just batching within each skeleton.

All Spine Runtimes are now compatible with the latest stable Spine editor, version 3.4. Spine 3.5 is nearing completion, bringing new features that need to go into all our runtimes. With the cleaned up code base, adding those features will be a lot easier and happen more quickly than in the past.

We also have a few changes in store that will make AnimationState much more versatile. Stay tuned for more on that.

Finally, we'll be looking into adding support for new game toolkits, with Unreal Engine and Godot being our top contenders.

Discuss this post on the Spine forum.

3.5.00-beta released

September 16th, 2016

Today we are happy to have released Spine version 3.5.00-beta!

First beta release

This is our first beta release. The "beta" tag means that one or more of the officially supported runtimes have not yet been updated to work with the editor release, otherwise it is just as stable as a normal release.

By default, your Spine installation won't automatically update to a beta version when set to use the "Latest" version. Beta releases allow us to do editor updates without everyone being upset that the runtimes are not yet updated. If you want to use the latest beta, you'll have to check the beta checkbox in your Spine settings:

After 3.4.02, if you always use a non-beta release then you can be certain that your exports will work in an official runtime. Here are a few reasons you may want to give up that guarantee and use a beta release:

  • You are exporting images or video, so lacking runtime support doesn't matter to you at all.
  • You want to try out our fancy new features ASAP. You can always go back to any older Spine version, just be careful not to save your projects with a newer version, since older Spine versions won't be able to open them.
  • You know the runtime you are using has already been updated to work with the beta editor version. Some runtimes will be updated before others and we won't do a non-beta release until all runtimes are updated. Each runtime's README on GitHub specifies the most recent Spine version it works with.
  • You want to animate with the latest version and are OK with waiting until the runtimes have been updated.

Just keep in mind that if you update to a beta release, do a bunch of work, and then are upset that the runtimes have not yet been updated... well, we will find sympathy difficult!

Runtime status

Before going over a few new features, let's talk about the current status of the runtimes. We've been making fantastic progress -- all of the runtimes are updated to work with 3.4.02 except the Lua family of runtimes. We are nearly finished with spine-lua and the rest will come very soon after. Some runtimes have seen massive improvements, especially spine-js which has become spine-ts as described in our last blog post. To really see the power of spine-ts, be sure to check out our new demos page!

As soon as the Lua family of runtimes are updated to 3.4.02, we will start a new round of updates to bring them all up to version 3.5. We have greatly beefed up our resources for keeping the runtimes up to date, so in the future they will not lag very far behind the editor updates.

Now let's move on to what is new in 3.5.00!

Constraint order

The order constraints are applied can be specified by dragging constraints in the tree, which enables all kinds of fancy rigging. Previously the order was fixed: IK, then transform constraints, then paths. By default Spine guesses at a reasonable order, but you can customize it for full control. For example, you might have a transform constraint set the position of an IK bone, then apply IK, then apply another transform constraint. Constraint order will also be crucial as we add more constraints in the future.


The frames per second for playback can now be specified on the Playback view. While the default of 30 frames per second is probably fine for most, some animators have an intuitive sense of how many frames a certain movement to take when animating at 12 or 24 frames per second. Changing the FPS can also be useful when animating fast movement. You can always hold shift to set keys between whole number frames, but it may be more comfortable to change the FPS higher than default, for example to 60. This way you still get snapping to whole number frames.

Changing the FPS affects the speed of the animations at runtime and the setting is for the entire project. Changing the FPS does not change the frames for existing keys, so your animations will run slower or faster. This means you should set the FPS before you start animating.

Disabling scale

We weren't happy with how unchecking Inherit scale worked previously. In some situations where negative scale is involved to flip a character, rotating a parent bone would cause a child bone to appear to rotate in the opposite direction. Due to some mathematical breakthroughs, we now have a much more robust "disable inherit scale" feature which works in every scenario.

Unfortunately disabling inherit scale does work slightly differently than it used to: nonuniform scale (different X and Y scale) on a parent bone still affects the rotation of the bone which has scale disabled. This makes sense in practice and it's unlikely to cause problems with existing projects, but we're mentioning it for full disclosure. If this behavior is not what you want, consider using a transform constraint to take the parent bone's position and rotation but not scale.

Disabling reflection

Along with the new disable inherit scale comes a new feature: the ability to disable scale but not reflection. Reflection means the use of negative scale to reflect or "flip" a bone to the other side of one of its axes. Now when you disable scale you can choose to still inherit reflection, so the bone doesn't scale when its parents are scaled, but still flips when its parents are scaled negatively.

Discuss this post on the Spine forum.