What is Starling?
The Starling Framework allows you to create hardware accelerated apps in Haxe. The main target is the creation of 2D games, but Starling may be used for any graphical application. Thanks to OpenFL, Starling-based applications can be deployed to all major mobile and desktop platforms, including the web.
Figure 1. This red little fella represents the logo of the Starling Framework.
While Starling mimics the classic display list architecture of OpenFL, it provides a much better performance: all objects are rendered directly by the GPU (using the Stage3D API). The complete architecture was designed for working well with the GPU; common game development tasks were built right into its core. Starling hides Stage3D internals from developers, but makes it easy to access them for those who need full performance and flexibility.
Why another display API?
As outlined above, Starling’s API is very similar to the native OpenFL API, namely: the openfl.display package.
So you might ask: why go to all that effort to recreate OpenFL inside … err, OpenFL?
The reason is that the original openfl.display API, with its flexible display list, vector capabilities, text rendering, filters, and whatnot, was designed in an era of desktop computers.
Those computers had powerful CPUs, but (by modern standards) primitive, fixed-logic graphics hardware.
Today’s mobile hardware, on the other hand, has an almost reversed setup: a weak (i.e. battery-conserving) CPU with a very advanced graphics chip.
The problem: it’s difficult to change an API that was designed for pure CPU rendering to suddenly use the GPU efficiently.
To its credit, the OpenFL project is very aware of this issue. That’s why it includes a low level graphics API called Stage3D. That API is decidedly low-level; it’s basically a wrapper of native graphics APIs like OpenGL, allowing developers to access the raw power of the GPU.
The problem: such a low-level API doesn’t help users of the classic display list much, at least not right away.
The Stage3D API is as low-level as it gets, so it’s nothing a typical developer can (or should!) directly work with when creating an app or game.
Clearly, OpenFL needed a more high-level API, built on top of Stage3D, but as easy to use as openfl.display.
Well … this is where Starling enters the stage (pun intended)!
It was designed from ground up for Stage3D, while mimicking the classic OpenFL API as much as possible.
This makes it possible to fully leverage today’s powerful graphics hardware, while using concepts countless developers are already familiar with, allowing them to move from openfl.display to starling.display relatively easily.
Starling’s philosophy
One of the core aims of Starling was to make it as lightweight and easy to use as possible. In my opinion, an open source library should not only be easy to use — it should also encourage diving into the code. I want developers to be able to understand what’s going on behind the scenes; only then will they be able to extend and modify it until it perfectly fits their needs.
That’s why Starling’s source is well documented and surprisingly concise. With a size of just about 15k lines of code, it’s probably smaller than most games that are written with it!
|
I really want to emphasize that: if you’re one day stuck or confused why your code isn’t working as expected, don’t hesitate to step into the source code of Starling. Oftentimes, you’ll quickly see what’s going wrong, and you’ll get a much better understanding of its internals. |
Another important goal of Starling is, of course, its close affinity to the display list architecture. That’s not only because I really like the whole idea behind the display list, but also to make it easy for developers to transition to Starling.
Nevertheless, I was never trying to create a perfect duplicate. Targeting the GPU requires specific concepts, and those should shine through! Concepts like Textures and Meshes aim to blend in seamlessly with the original API, just as if it had always been designed for the GPU.