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.
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.
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.
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.
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!
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.