Mastering C# and Unity3D

Rendering Spriter Sprites With Starling

Spriter is a tool for creating sprite animations out of multiple images. By moving, rotating, and scaling them over a timeline you can create much more efficient 2D animations than traditional full-frame animation. While Flash animation has worked similarly for years, it’s largely incompatible with the Stage3D API that is quickly becoming mandatory to achieve adequate performance. Today’s article will show you how to use Spriter in your Stage3D-powered Flash app via a Starling and some custom classes I’ve created.

The Spriter tool is currently in the alpha stage of development, so it is not yet stable or fully-featured. However, you can download it and try it out. As such, the file format that it exports may change before the final release. My code to work with Spriter may stop working if that happens and require some modifications.

Starling, on the other hand, is quite a bit more stable. It’s currently on version 1.2 and being used in several production Flash apps. Still, new versions may break backward compatibility and, by extension, the below code.

Lastly before we look at the code, what I have is based on the work of two other developers. First, Abel Toy created several Flash-based implementations for loading and displaying Spriter sprites. Unfortunately, this code no longer works with the latest Spriter file format version. I then merged in the work of Oddysee that updates the file format handling to the latest version. Then I made a series of optimizations to Abel Toy’s code that improved performance so that it’s roughly 50x faster:

The bulk of the speedup here was really the conversion to using a texture atlas. The old code had two approaches. The first was to draw each image making up the sprite as its own draw call. The second was to compose the image on a BitmapData and upload it as a texture. Both of these approaches pale in comparison to the texture atlas approach which requires only a single draw call, no CPU-side composition, and no uploading textures every frame.

Now, to use the code you’ll need to prepare the assets. Here are the steps:

Export the sprite from Spriter

Pack the sprite images into a texture atlas with a tool like Texture Packer (free lite version or full license)

I hope you find this code useful. Even if you don’t use Spriter, it’s a good example of how to improve performance in Stage3D apps. I don’t currently have any plans to maintain or improve this code, but I certainly welcome any of you to do so. If you do or you have any questions about it, feel free to post a comment!

I am using Flambe (haxe game engine) for a game I’m building. They recommend ‘Flump’ http://threerings.github.com/flump/ which is also a (AIR) tool to export animations from flash. Flambe has its own loader/player for Flump exported stuff, so that gives a nice intergrated flow, but it’s also ready for Starling (btw I never used it for starling). so maybe worth testing too. It generates atlases too, and you’re able to preview the atlas and the animations before exporting. I find it a nice workflow, since most animators already know flash.

Yeah, my implementation was really dumb. I did it very quickly and then abandoned it.

I was in talks with the spriter guys to make it official and keep improving and adapting to the format, but it never came to fruition.

But yeah, I realise how what I did was quite shit. I actually did the FlashPunk version first, because that’s what I used. In FlashPunk, the adds and removes are quite faster because of the way the display list works. It also didn’t have TextureAtlas. When porting to the other backends, I just naively translated code and that’s it. I didn’t have experience with GPU accelerated coding, that’s why I didn’t even know about atlases :P

Thank you for posting this, anyways! I keep getting e-mails about making my implementation work, and I just tell them other people have already done it and better than me.