Starling 1.5

Daniel Sperl on May 20, 2014

As always, it has been a busy spring here in Austria. Over the last weeks and months, I added a huge number of optimizations, bugfixes and new features. Our little bird learned something new almost every day!

Thus, it’s high time for a new stable version, so that all of you can make use of those enhancements! And that’s exactly what I want to do today. Hold tight and follow me through a quick tour around Starling 1.5!

Automatic Profile Selection

Adobe recently introduced the new Stage3D profile “Baseline Extended”, which finally allows us to use textures up to 4096x4096 pixels. And with the upcoming AIR 14, there’s already another new profile on the way: the “Standard” profile, which will allow more complex AGAL programs (among other new features).

This is great news, because those new profiles allow for much more flexibility. However, it’s also becoming increasingly difficult to always select the right profile on the right device. For this reason, Starling now offers new ways to pick a profile.

Here’s one way of doing it: pass an array of profiles to the Starling constructor and let it pick the first one that works on the current hardware:

new Starling(Game, stage, null, null, "auto", ["baselineExtended", "baseline"]);

Alternatively, you can simply pick the best of all that are available, using the “auto” String.

new Starling(Game, stage, null, null, "auto", "auto");

Later, when Starling has been initialized, you can find out which profile was chosen via “starling.profile”. That way you can adapt your game logic accordingly, e.g. you can load the super-uber-HD textures if it’s the extended profile.

The default stays at “baselineConstrained”, though, to be on the safe side. After all, there’s some additional testing required if you support multiple profiles.

Automatic usage of RectangleTextures whenever possible

For some internal / architectural reason, the default “power-of-two” textures of Stage3D always allocate additional memory for mip-maps — no matter if you’re actually using them. This is quite annoying, because it means that you’re always wasting one third of your precious texture memory.

Beginning with “baseline” profile, though, Stage3D supports “RectangleTextures”. Their most notable feature is that their sidelengths don’t have to be powers of two. However, what makes them actually even more useful is that they do not allocate that mip-map memory.

[To avoid confusion: I’m not talking about a new Starling Texture class here. I’m talking about a class that’s used internally when textures are uploaded to the GPU. All of this happens behind the scenes.]

Starling now defaults to those new memory-saving textures whenever possible. To make use of this feature, follow these steps:

  • Start Starling in “baseline” or “baselineExtended”-profile (or use the new “auto” argument shown above).
  • Pass “false” to any Texture / AssetManager argument asking for mip-maps.

When you do that, Starling will use RectangleTextures automatically, saving you a whopping 33% of texture memory. W00t!

Support for rotated SubTextures

Some loyal TexturePacker users might have already noticed it: when you choose Starling or Sparrow as output format, you can let it rotate your textures in the atlas, for even more efficient texture distribution. This is supported by Starling 1.5!

Perhaps this will allow some of you to save even more memory by reducing the number of atlases altogether.

New “touchGroup” property

This is a feature that has been requested for a long time, and now it finally found its way into the official version. Display object containers have a new property called “touchGroup”. If enabled, the container acts as a single touchable object.

That’s similar to the “mouseChildren” property you might know from traditional Flash, and it means that the container can become the “target” of a touch event.

Significantly reduced start-up time

In the past, Starling’s AGAL programs were created all at once when Starling was initialized. Most games use only a fraction of those, though, so that’s actually a waste of time and resources.

Thus, those programs are now created on the fly before they are first needed, which reduces the start-up time of Starling immensely. (Thanks to Starling user ajwfrost for making me aware of this problem!)

Many small convenience additions

  • You can now use custom settings for individual textures in the AssetManager.
  • There’s a new “SystemUtil” class that contains helpers for multi-platform development, e.g. if you’re running on Desktop or Mobile.
  • The “delayCall” method of the Juggler now pools the delayed calls.
  • The Juggler contains a new “repeatCall” convenience method.
  • You can now “mute” MovieClips.

It just works™

On mobile, you often have to fight with peculiarities that happen just on some device families, but never on your development devices. Starling now works around many of them, so you don’t have to care.

  • The RectangleTexture limitations (RenderTexture!) on the iPad 1 are avoided.
  • The AssetManager now supports AIR’s new background execution mode.
  • There are additional checks for context loss, which make handling it more stable.
  • The AssetManager can now cope with a lost context while it is processing its queue.

And on and on and on …!

As always, the complete changelog can be found on GitHub.

A huge THANKS to all the developers who supported me with bug reports, feature suggestions and pull requests! Starling wouldn’t be where it is today without your help, guys.

Please give the new version a go! I’d be happy about any feedback — just leave your comments below!