Starling 2.5

Daniel Sperl on April 2, 2019

There’s no denying it: Starling has seen easier years than 2018/2019! The Flash Player’s end-of-life is looming ahead, and Adobe, it seems, still hasn’t quite figured out what they want to do with AIR. In other words, it’s time for a quick …

Recap and Outlook

Adobe started to fund and support Starling in 2011, when it was introduced. Yes, it’s been almost 8 years since the little red bird launched. Unbelievable!

If it weren’t for Adobe, there would be no Gamua, and I’d never have made the jump to become independent. Actually, I still can’t believe my luck – what a privilege I’ve had, to get the chance of creating a piece of software that’s now powering countless games and apps around the world!

Alas, that funding ended with 2018, so I’m no longer able to work full-time on Starling. However, the emphasis lies on “full-time” here. You all know that Starling has always been my labor of love, so a lack of funding doesn’t really prevent me from keeping to pour in many hours and lots of sweat and love. :)

My promise has always been to keep Starling in shape as long as people are using it, and this promise still stands!

For example, I recently moved the Starling Forum to a fantastic new engine, migrating more than 110k posts and 7k users along the way. If you haven’t seen it yet, definitely check it out!

Most importantly: people are still creating fantastic games and apps with Starling; for example, my own humble Find it!, or the amazing AAA-quality Summoners Fate!

As for Starling itself: its API is stable and mature, so there’s no need for massive changes anytime soon. Frankly, working on it full-time is not really necessary any longer!

That’s why the focus in the last year had already shifted slightly, towards better documentation and extensibility.

Thus, the crucial question is really: what’s Adobe’s next step? They must finally decide and announce what they have in mind for the future of AIR.

Call me naive: I’m still optimistic that we will find out soon. In the meantime, let’s focus on what’s in our control, shall we? And in that respect, there are great news, actually.

As the title of this post suggests, there’s a brand new Starling release available! Not only is it featuring a lot of under-the-hood polishing, but also a few nifty new additions. Check out all important changes below!

Discarding System Gestures

On mobile operating systems, it has become the de facto standard that swipes from the very top or bottom of the screen reveal some kind of system overlay (like the notification center or an app-switcher). Since those input events are still forwarded to AIR, those gestures often lead to actions that the user hadn’t really intended.

For that reason, Starling now recognizes those gestures and will discard any corresponding touch events right away. The logic is quite simple: if a swipe starts within certain margins along the edges of the screen, it will be ignored. On mobile, that’s now the default behavior; but you can customize that, of course. Here are the relevant calls:

// new property on Starling: (defaults to 'true' on iOS and Android)
starling.discardSystemGestures = true;

// which is actually just a shortcut for:
starling.touchProcessor.discardSystemGestures = true;

// set up margins at TOP, BOTTOM, LEFT, RIGHT:
starling.touchProcessor.setSystemGestureMargins(15, 15, 0, 0);

Extended Touch API

While I was working on those gestures, I realized that I could make touch processing easier in general by providing a few more convenience methods and properties to the “Touch” class. Like the following:

function getStartLocation(space:DisplayObject, out:Point=null):Point;
function getMovementSinceStart(space:DisplayObject, out:Point=null):Point;
function get startGlobalX():Number;
function get startGlobalY():Number;
function get duration():Number;

The names should be rather self-explanatory, but the API reference provides more details, of course.

Bezier Easing

Web developers might have come across the “cubic-bezier” function in CSS. It provides a very flexible way of defining a transition curve to be used by tweens. Sounds like a perfect addition for Starling’s tweens, too, right?

In a nutshell, a cubic bezier curve is defined by four points. The transition curve will always go directly through points 0 and 3 – they are fixed at the coordinates 0|0 and 1|1, respectively. Points 1 and 2 are control points that define exactly how the curve is bent.

What’s so great about this technique is how it simplifies creating custom easing functions. Use a visual tool like cubic-bezier.com or Ceaser to draw your curve; then pass the four coordinates to the new BezierEasing.create() method.

For example, you can setup the standard Material Design easing functions like this:

Transitions.register("standard",   BezierEasing.create(0.4, 0.0, 0.2, 1.0));
Transitions.register("decelerate", BezierEasing.create(0.0, 0.0, 0.2, 1.0));
Transitions.register("accelerate", BezierEasing.create(0.4, 0.0, 1.0, 1.0));

Thanks a lot to Rodrigo Lopez for the original idea and implementation! (See Starling Wiki)

Better Native Overlay Handling

The native overlay is a flash.display.Sprite that always lies exactly on top of the Starling display list, with the same values for scale and orientation. It’s been a part of Starling since its very first release, intended to simplify combining native display objects with those created by Starling.

There was always one catch, though: mouse and touch events always ended up in both display lists, even though the native overlay clearly lies on top of Starling’s. In a perfect world, objects on the native overlay should act just like Starling’s regular display objects: only the topmost object should receive the touch.

Well, we’re obviously one step closer to a perfect world! Because that’s just what Starling 2.5 does by default. :)

(In case you want to opt-out of this behavior, disable nativeOverlayBlocksTouches on your Starling instance.)

… and more!

  • Want to terrify your players with a realistic shock wave? The ‘DisplacementMapFilter’ can now do just that.
  • To all users of the Particle System extension: it can now cope much better with low FPS situations!
  • The all-popular ‘Pool’ class now provides methods for standard Arrays, as well.
  • Starling.multitouchEnabled can now be changed whenever you want (previously, it needed to be set before Starling was initialized).
  • The ‘Color’ class can now convert between RGB and HSV/HSL (thanks to Adolio)!
  • The new AssetManager introduced in Starling 2.4 is now much more memory efficient.
  • The ‘StatsDisplay’ aligns correctly even with custom viewPort settings.
  • TrueType text stays crisp even with non-integer contentScaleFactors.

Oh my, I can already hear some busy keyboard stroking – some of you must already be simplifying their code base by making use of those new shortcuts! ;)

The complete change log can be found at the usual place, of course. As always, this release wouldn’t have been possible without all the commitment and help from the community! Most of the changes are a direct result of your comments and reports - thanks to everyone involved!

I hope you agree that this release doesn’t have to hide behind its predecessors! The update is highly recommended for everyone. Please give it a try and don’t forget to leave a post below so that I know the Starling community is still alive and kicking! :)