Starling 2.6

Daniel Sperl on February 11, 2020

In the blog article accompanying the previous Starling update, I wrote that Adobe should hopefully soon decide how to move on with AIR. Well, shortly after that post, it actually happened: Adobe transitioned support and future development of AIR to Harman.

That’s one topic of today’s blog post; the other is that there’s a brand new Starling incarnation available! Read on to find out all about it.

AIR moving to Harman

We all felt it for the past few years, right? Adobe didn’t quite know what to do with AIR any longer. Its commitment to the platform, which had started out so strong, had slowly trickled away. In their brave new “Creative Cloud” world, AIR was an obscurity that didn’t fit anywhere anymore; and one that clearly lacked a business model.

Thus, most of us were actually relieved to hear that Adobe had finally made up its mind, even if that meant giving AIR into different hands. Harman has apparently been a close partner of Adobe for a long time, with deep knowledge of the platform and its ecosystem, so it seemed like a really good match.

We’re now a few months into the transition, and my feeling is still very positive.

  • Harman quickly provided support for 64 bit Android builds via AIR 33. As you know, Google now requires 64 bit apps when publishing for Google Play; even though there’s an exception for AIR until August 2020, this wasn’t sure when Harman took over.
  • They’ve been really responsive and keen on input from the community. A special kudos to Andrew Frost!
  • Some bugs that had annoyed the AIR user base for a long time have finally been fixed.
  • They even took over the issue tracker I set up mainly for Starling users! Granted, it’s a temporary solution, but it still works so much better than the old one (just remembering that one gives me the shivers).

As expected, this move also brought a change (or let’s say: an introduction) of a revenue model. However, the pricing model seems really fair to me, especially since small developers can still use the SDK for free (at the price of having to display a short splash screen). Development and support of AIR is a considerable investment, so let’s hope that this model works out and maybe even pushes the platform to a second bloom in the future. Fingers crossed!

As for the current state of affairs – beware that you need to select a different version of the AIR SDK, depending on the platform you want to deploy to.

  • For iOS and macOS, it’s recommended to still use AIR 32, which is the final major release from Adobe. It can be found here: Download AIR SDK from Adobe
  • For Android and Windows, you should use the newer AIR 33, which is being developed by Harman. Find it here: Download AIR SDK from Harman

By the end of the year, AIR 32 should become obsolete and you will be able to use Harman’s releases across the board. I recommend you keep an eye on the latest release notes to find out which route to take!

Starling 2.6

Since Starling is now purely a spare-time project for me, it’s hopefully understandable that I haven’t done quite as much development this year as in the past. However, I’m always having an eye on the forum and issue tracker to stay on top of everything, and there is this constant itching in my fingers to add some new features.

Thus, I decided to wrap those latest changes up in an official release!

New Options for Shadow and Glow

My favorite new feature concerns the DropShadow- and GlowFilter classes. Compared to the classic Flash API, those two always lacked two really handy features –– which are now finally available in Starling, via two new properties:

  • Enable inner to let the object act as if it was cut out of a surface. The shadow/glow will appear inside of it, rather than behind.
  • Enable knockout to draw just the shadow/glow, not the object itself.

Here are the default variants:

And here with knockout = true:

The filter API is one of the areas of the Starling API I’m most proud of, so I really enjoyed playing around with it again.

ButtonBehavior

Typically, when you react to touch or mouse input in Starling, you listen to TouchEvents. One exception is Starling’s button, which dispatches a special TRIGGERED event.

That’s because the Button contains some additional logic: when a user touches the button, she has the option of canceling the operation by moving the finger sufficiently far away before raising it from the screen. Furthermore, buttons make it easy to change their texture/color/alpha during MouseOver or when disabled.

All that logic is part of the Button class –– and rather painful to implement if you need it somewhere else. For example, a user interface might require a simple, colored TextField to be used as a button, without the need of state textures.

The solution I came up with is to extract that button-specific behavior into a separate class: ButtonBehavior. Instantiate the behavior and pass it your desired display object, and it will make this object dispatch TRIGGER events just like a regular button. It will also tell you whenever the state of the pseudo-button ought to change, so you can react accordingly.

Here’s an example that should make it easy to understand: the aforementioned TextButton:

public class TextButton extends TextField
{
    private var _behavior:ButtonBehavior;
    private var _tint:uint = 0xffaaff;

    public function TextButton(width:int, height:int, text:String="",
                               format:TextFormat=null, options:TextOptions=null)
    {
        super(width, height, text, format, options);
        _behavior = new ButtonBehavior(this, onStateChange);
    }

    private function onStateChange(state:String):void
    {
        if (state == ButtonState.DOWN) format.color = _tint;
        else format.color = 0xffffff;
    }

    public override function hitTest(localPoint:Point):DisplayObject
    {
        return _behavior.hitTest(localPoint);
    }
}

Note that this class inherits from TextField, so you’ve got all its properties and methods at your disposal – in addition to true button-like behavior.

  • Basically, instantiating ButtonBehavior and forwarding this to its constructor is all you need to do.
  • Implementing onStateChange is optional. Use it if you want to modify the TextField depending on the button state.
  • Forwarding hitTest is optional. Its sole purpose is to extend the hit area if the TextField is too small to be comfortably touched.

Enhanced ‘drawToBitmapData’

The drawToBitmapData-method on DisplayObject is useful if you need actual pixel values of an object. Previously, it had one annoying limitation: you couldn’t draw objects bigger than the current back buffer (i.e. the stage size). This limitation is finally gone – the method now works with objects of any size.

That’s it, folks!

Thanks a lot for still using the little bird, and/or for still following its progress! As always, you can grab the new version from the download section or by a quick git pull from the Git repository.

I’m wishing you all the best for your current and upcoming projects – see you around in the forum!