Sprite3D and What's Next

Daniel Sperl on October 21, 2014

Last week was the Flash Online Conference #10, featuring sessions about many current and upcoming projects around Flash and AIR. There were lots of really interesting talks from Adobe engineers as well as framework developers. For example, Chris Campbell spoke about the Flash roadmap, and Josh Tynjala showed the brand new version of Feathers. It was an amazing event that underlined just how much is going on right now in the Flash ecosystem!

I was invited to this conference as well, and I had prepared a lengthy presentation about the upcoming Starling version and the future roadmap. However, it somehow was not meant to be — due to technical problems, I repeatedly dropped out of the broadcast and could not show the presentation to you.

However, I’m now making up for these problems with this blog post! The advantage: you’re not bound to any real-time restrictions and can read & watch whenever you’ve got the time. ;-)


I’m currently working hard on the next official release of Starling, which is going to be version 1.6. As always, the new version is stuffed with bug fixes and optimizations; but there’s one new feature that I’m especially proud of, and I know that many of you have been waiting for this a long time.

That feature is the new “Sprite3D” class. Basically, it allows you to take any display object and move it around in a three-dimensional coordinate system. This means that you’ve now got a real perspective projection — useful not only for special effects, but for whole new concepts Starling wasn’t capable of in the past!

In fact, to really appreciate the power that this feature brings, you have to see it live. Start the video below and watch me sprucing up a simple game of memory by adding some fancy 3D transitions!

[Update: The project used in this video is now available on GitHub.]

Not too bad, right? Now, before you start playing around with this feature (it’s already part of the latest development version), let me tell you a little more about it.

First of all, you might ask: why is there a new class? I could have added the new 3D properties to the standard “DisplayObject” class, after all (like it was done in Flash 10).

Well, at its heart, Starling is still a 2D engine. All the code that you’ve written in the past was 2D; that includes custom display objects with your own AGAL code. By having the 3D logic in a separate container, I could make sure that all of the old code still works. Even more important: new code doesn’t get any more complicated than before, because all of your objects are still plain and simple 2D objects. The only difference is that you can now move them around in space — with the help of “Sprite3D”.

This doesn’t mean that you’re restricted to flat objects, though. This picture, for example, shows a combination of six Sprite3Ds combined to form a cube. (Yes, you can put a Sprite3D in a Sprite3D!)

Nevertheless: Starling is not a 3D engine, and this means that there are a few limitations you should be aware of:

  • Starling still does not make any depth tests. (Visibility is determined solely by the order of children.)
  • One Sprite3D means one draw call. (Update: Except when your sprite is in fact not 3D transformed; Starling will treat it just like a normal 2D object then. This mitigates the problem for a great part.)
  • You cannot call “flatten” on a Sprite3D. (But you can flatten objects inside a Sprite3D.)
  • You cannot call “cache” on a filter that’s on top of a Sprite3D. (Uncached filters work fine, though.)

Other Changes

That’s not the only change that you can look forward to, of course. Starling 1.6 contains many under-the-hood enhancements!

For example, the recent release of Flash / AIR 15 brought a change that relaxed the ways that RenderTextures can be used. Thanks to this, I could finally enable Starling to support nesting of filters! I.e. you can now add a full-screen filter to a scene that already contains filtered objects.

Thanks to the same enhancement, I could reduce the memory requirements of “persistent” RenderTextures by 50%, because I no longer need to use double-buffering. This also means that drawing into such a texture is now faster than before (one less draw call).

Other enhancements include parallel asset loading in the AssetManager — drastically reducing your loading times — and an updated “Button” class, which now contains “over” and “disabled” states. Of course, I’ll describe all those changes in detail when the new version comes out, which should be sometime within the next 4-6 weeks!

Roadmap for 2015

After this release, I’ll start to work on the following features:

  • Stencil masks (fast masking with arbitrary shapes)
  • FragmentFilter chaining (adding several filters on one display object)
  • Custom batching

The latter will probably require some changes to the public APIs of Starling, in which case this will be released as a new major version (Starling 2.0). The idea is that people should be able to write their own renderers and to efficiently batch together even custom display objects.

As always, I can’t give any time schedule on this — but rest assured, I’m working hard to get those features in your hands as quickly as possible!

That’s it for today! I hope you liked this little peak into Starling 1.6 and the upcoming roadmap. Feel free to ask any questions below, or to tell me what else I should add to the upcoming releases!