Starling 1.0 - Ready for Mobile!

Daniel Sperl on February 29, 2012

Some of you will already have noticed it: Starling silently went “1.0” with the launch of the new website. As the new logo clearly indicates, our young bird has left the eggshell and is looking for adventures in the real world!

But that’s not all: at the beginning of this week, the release candidate of AIR 3.2 was published, which added support for mobile devices.

I think I should emphasize this more:

At this very moment, you can use Starling to develop content on mobile devices! In other words: games that are created with Starling run not only in the browser, but on 90% of all smart phones and tablets out there (iOS and Android).

Personally, I think that’s pretty cool. =)

Starling 1.0

This update is warmly recommend to any Starling user. To prepare the framework for deployment on mobile devices (read: devices with tight hardware limitations), we worked hard to ensure maximum performance, compatibility, and responsiveness. The results of these efforts show not only on mobile devices, but in the browser, as well.

At the same time, the Stage3D team at Adobe did some amazing work on the underlying Stage3D technology. They pushed the performance to a level I did not think possible a few weeks ago. The result: on iOS, Starling is almost as fast as its native cousin, Sparrow. This makes Starling more than suitable for any mobile game you can think of.

What follows is a description of the most notable changes and additions of Starling “one point oh!”.

Handling a lost Device Context

On Windows, many graphics drivers have the nasty habit of losing their rendering context on some occasions (e.g. when you “Ctrl-Alt-Del” to lock the computer, or if a 3D screensaver comes up). For Starling content, this meant that an exception was thrown, and the game was over. Ouch.

The new version can handle such an interruption. This comes at a price, though: the bitmap data of all textures has to stay in memory; it is needed to recreate the textures in the case of a device loss. For that reason, this feature is turned off by default. But activating it is simple: just call

Starling.handleLostContext = true;

before you create your Starling instance.

Reduced Memory Consumption

Old versions of Starling, especially the very first release, created a lot of temporary objects. This resulted in quite a heavy burden on the garbage collector. In the browser, one could live with that; on mobile, it’s unacceptable, because it will cause very distracting hiccups.

Through some internal changes, it was possible to get rid of almost all of those temporary objects. When you profiled previous versions, you saw thousands of Matrix and Point objects being created during the rendering and mouse processing phases. Now, they are gone, completely. The same happened in many other places.

This forced me to change a few public method definitions (most notably the hitTest-method of DisplayObject), and if you’re overriding one of those methods, it will break your code. But the compiler will point that out to you, and it’s easy to fix.

Performance Improvements

I analyzed the code for performance bottlenecks and optimized it at several places. The movie clip class, for example, is much more efficient than before. I also got rid off a few inline methods (closures) at critical places. Thanks for the team from Adobe and to several GitHub users for pointing me at some of those issues!

Other changes

Here’s a short overview about other noteworthy changes. For the full list, have a look at the changelog on GitHub.

  • The Sprite class now contains the property useHandCursor, which acts just like that of the native class: it displays a hand cursor while the mouse is hovering over that object. The SimpleButton class defaults to this setting now.
  • The DisplayObjectContainer class has a new method sortChildren, which allows you to sort the child objects by an arbitrary criteria. That should be very helpful for isometric games and other use-cases where the z-ordering needs to be flexible.
  • I added an Ant build script for the Starling swc library.
  • The IAnimatable interface was simplified by removing the isComplete property. That method caused some confusion in classes that implemented this interface. (The juggler, who relied on that property, now listens to the event REMOVE_FROM_JUGGLER instead.)
  • Heads up: the MovieClip class now dispatches an event of type COMPLETE instead of the old MOVIE_COMPLETED.
  • Furthermore, I fixed several bugs in different areas – thanks to all the users in the forum and on GitHub making me aware of those!

Outlook

If there’s anyone who still doubted it: I’m certain that this update makes sure that Starling is a mature, reliable and competitive framework for cross-platform development. Furthermore, it provides a solid foundation for all the features we have planned for the future – so stay tuned!

I can’t wait to see the content you will create on the basis of our little red bird!