Starling 2.0 Final
Daniel Sperl on April 19, 2016
It’s been several weeks already since I offered you a first look at the brand new version of Starling (if you haven’t read my previous post yet, make sure to do so before continuing: Starling 2.0 Beta). Many developers were brave enough to take it for a test ride or even port their existing games over to the new version. That feedback was extremely valuable for me — thanks a lot to everyone who participated!
So you kept me quite busy, but it was well worth the effort: not only was I able to move lots of potential issues out of the way, but I could also spend some more time on polishing the new version.
Thus, finally, it’s time to make the next step and publish the official version! Read on to find out all about the additional changes that made it into the “Starling 2.0” release.
Bringing CPU usage down to ZERO
Sometimes, it’s the simple things that have the biggest impact. Remember the new “render cache” I introduced in the new version, which optimizes CPU workload for static parts of the display tree? It turned out I could even take this one step further. (A huge thanks to maximgavrilov for coming up with this idea!)
It happens surprisingly often in an app or game that a scene stays completely static for several frames. Just look at the Starling Demo or the Feathers Component Explorer: as long as you’re not directly interacting with the app, they are mostly static. So why redraw the stage at all?
That’s exactly the point of the new skipUnchangedFrames-property. If enabled, static scenes are recognized as such and the back buffer is simply left as it is. On a mobile device, the impact of this feature can’t be overestimated! There’s simply no better way to enhance battery life.
You might ask why I didn’t activate this feature by default. The reason: RenderTexture and VideoTexture classes need special treatment when it’s enabled (requiring a call to setRequiresRedraw whenever their content changes), so I decided to better not cause any unpleasant surprises. Still, it’s highly recommended to always activate this feature; especially since it doesn’t cost anything, performance-wise.
One more thing: to make it easy to recognize if you are utilizing this optimization in a given moment, I modified the statistics display slightly: it will now turn dark green whenever a significant amount of frames is being skipped. Keep an eye on that!
Optimizing Filters
As described in my previous blog post, the filter API of Starling 2 is a massive improvement over the previous version. It’s easier to write custom filters, you can use them more flexibly, and they make automatic use of the render cache.
However, in cases where the render cache did not kick in, they were also a little bit slower than before. Well, not any longer! I spent a lot of additional effort on that API and brought it up to speed. The final render pass now draws directly into the back buffer, without detour over a texture.
You need even more speed? Performance junkies now have all the options they need: cache the filter output, use a lower resolution, or even change the textureFormat to a lower bit depth — all without compromising any of the original API enhancements.
All modesty aside, you won’t find a filter API anywhere else that’s as easy to use, as fast, or as flexible as this! 😎
Optimizing the Rest
A huge part of my time was also spent on performance optimizations throughout the complete rendering pipeline. I found a number of shortcuts to exploit as well as bottlenecks to avoid, bringing up performance to a fantastic level.
All in all, my tests indicate that the CPU consumption of Starling 2 is typically a little higher than 1.8, which is simply a side effect of the additional flexibility (it seems the old saying about the “free lunch” has some truth in it, after all). On the other hand, GPU usage was reduced significantly, meaning you can move around more pixels than before and you’ve got more options to speed things up manually.
As for bug reports, I was actually surprised how few problems popped up, despite the big number of testers! I think that’s a testament to the robustness of the new architecture; cleaner code makes for less bugs, that’s the simple truth.
Wrapping it all up
I’m extremely happy that I can finally scrap that “beta” sign and make Starling 2.0 “final”. Personally, it marks the conclusion of a long and exciting development phase that confronted me with way more challenges than I ever anticipated — and I’m very proud of the result.
Now, what comes out of this is all in your hands! I can’t wait to see the ways in which you push the new architecture to its limits. (Deferred Shading, anyone? A new filter collection? Or Cross-Texture Batching?)
You can download Starling 2.0 at the usual place, of course! Don’t forget to drop a comment below to tell me how it works for you. I’m looking forward to your feedback!
But wait, before you go, there’s one more thing. It’s …
Give-Away-Time!
Beware: The offer described below ended on May 31rd, 2016.
To celebrate the release of Starling 2, the guys from MyFlashLabs approached me with a special offer exclusively for Starling developers: they are giving away some of their most popular native extensions for free!
All you have to do is put those ANEs into the shopping cart and use the coupon-code “free-ane-for-starling-users” at checkout.
Pro developers who need more ANEs and want guaranteed support can save even more money: MyFlashLabs agreed on a 60% discount on their club membership (coupon: “club-for-starling-users”). As with the individual ANEs, this offer may be used only by Starling developers.
Knowing that many Starling developers are struggling to find great ANEs, I simply couldn’t say “no” to this offer. 😉 My thanks to the complete MyFlashLabs-team!
