Benefits of using starling over openfl?


#1

It is still unclear to me what are the benefits brought by starling-openfl. I mean openfl already mimics the conventional Flash AS3 library and is supposed to render as much as possible using GPU. So what does starling provide that openfl do not already have (didn’t use openfl-starling yet so this is a naive question)? And wouldn’t it have been a better idea to directly integrates starling advantages into openfl rather than having a tier lib (because for now, if I want to switch from a regular openfl project to one using starling, I have to change pretty much every openfl.display import to replace them by starling ones)?


#2

From my point of view, OpenFL seeks to mirror the Flash API, which is a great multi-purpose API for producing building multimedia experiences of all sorts.

Starling seeks to enhance a part of what the Flash API can do, specifically 2D hardware accelerated content like games and 2D experiences, providing many benefits to the native API as well as a few caveats when used, although with Daniel’s and the communities work on it, the list of caveats is shrinking (like recently, being able to convert display objects to BitmapData, a fairly trivial thing in native Flash). It replaces a number of Flash’s object types with Starling versions and tailors them for 2D image asset based development, both removing and adding functionality.

peteshand also comments on the hardware accelerated aspects of OpenFL compared to Starling Haxe, here:
http://forum.starling-framework.org/topic/starling-haxe-faqs


#3

well the peteshand comment stating that “OpenFL on the other hand still relies on CPU driven flash displaylist and HTML5 canvas.” seems outdated as openfl now also use GPU hardware accelerated rendering whenever possible if I am not misleading. Anyway I don’t really see why Starling is kept as an independent library rather than being directly merged with openfl (by adding its additions, like pivot on sprites for example, directly into openfl classes) as both have similar display API (and I don’t see any case where you would rather use CPU 2D rendering than GPU one so openfl should always use GPU hardware accelerated rendering, by default, which is exactly what starling was build for)


#4

I’d love to get clarification from one of the senior folk here, but as far as I’m aware OpenFL still uses the CPU for some things. The Flash API is similar in that hardware acceleration exists, but it really comes down to the specifics of what you’re doing and how you’re doing it. Understanding those things is a mountain of work. I have seen mentioned that OpenFL uses the GPU and is hardware accelerated, but I believe that’s on the basis that you’re doing things in a particular way.

The beauty of Starling, is everything you do in the display list, is in the GPU. That has amazing benefits, but also caveats which is why, I believe, it can’t replace the standard Flash API/OpenFL API.


#5

I think this is still the case.

Even in places where OpenFL does use the GPU, it doesn’t do so perfectly efficiently. If it was perfectly efficient, then there would be no difference between using bitmaps and using Tilemap. (But in practice, Tilemap runs a lot faster.)

I think the main difference is that Tilemap uses batching and ordinary bitmaps don’t. I think Starling might use batching too, so I’d expect it to render faster.


#6

I agree with all you said.


#7

In OpenFL, we include multiple renderers – OpenGL (including WebGL and GLES), Cairo, HTML5 canvas, and HTML5 DOM. We default to OpenGL on all targets and fallback to Cairo or canvas (depending on whether it is native or HTML5) when hardware is not available, or when using bitmapData.draw

OpenFL is designed to provide a broad range of Flash features. I believe we have done this without compromising performance or seriously impacting the final file size (thanks to features such as dead-code elimination and minification).

We have been focused on better support for Stage3D. This (in a sense) is less flexible than the core OpenFL display object support, because it has no software fallback. Flash Player has a software fallback for Stage3D content, but I would assume that direct HTML5 canvas calls (like our canvas renderer) would be more efficient on HTML5 than trying to simulate GL :slight_smile:

The goal for supporting Starling is to provide a broad set of choices for developers. Particularly, porting an existing title that already uses Starling is much simpler if there is a solid Haxe version of Starling.

The addition of Tilemap fills an important (missing) role in the core Flash API – the need for a hardware quad batch. I hope that we can continue to improve that API to feel as if it were a core API, and to continue to grow more useful.

I hope this answers some questions.

Away3D 5 was also released, I’ll be writing more in a blog post soon :smile:


#8

Hey everybody, I was wondering about the same things as Thomas.
Well as far as i understood, openFL converts the code to native android and iOS code, so won´t that be faster than using Starling … whatever that does with the code?
Or to be more specific: Which targets would benefit in which use case by using Starling-openFL instead of blank openFL?
I´m not a big fan of having to rely on various library dependencies and having an overly complex setup and I think this could also drive away potential new developers interested in openFL.
I completely see the benefits if you want to port an existing Starling project, but I guess this is a pretty rare case and so I was wondering why everybody is so excited about starling-openfl :wink:

Maybe if you answer my questions I´ll become enlightened too :slight_smile:


#9

Away3D 5?? Seriously?


#10

Hi there, I’m currently working on a game ported from Starling to Starling Haxe, so it’s obviously a good choice to switch in my case.
Starling has a lot of great tools for a game developer and I’m really glad I can keep using them.
Also, I do think it’s a great way to attract new people because Starling is quite popular among devs who used to create with flash.
Since OpenFL try to mirror the flash API, why wouldn’t it include the most popular engine to work with stage3d.

Plus, it’s not just OpenFL vs Starling, there are Haxeflixel, Haxepunk… that works on top of it too if I’m not mistaken.
And that’s the power of it, to choose the engine you like and mix it with other available API that are not available in the original version, for example, I use the Joystick/Gamepad API, UDPsocket, editing files and target c++… and still use my beloved Starling framework, that’s just awesome !


#11

Is there any link I can check ?
I tried to check the official website here, but cannot find anything related :
http://away3d.com/download/


#12

You can do : haxelib install away3d 5.0.0
or check it out at : https://github.com/openfl/away3d


#13

Oh, is it only available for Open FL ?


#14

Don’t know about that actually, though am using it along with OpenFL.


#15

It relies on the Stage3D API, so yes, it’s OpenFL only.

Since Stage3D is a relatively simple abstraction layer over OpenGL, you might be able to port it to Kha or Snow or whatever. However, when I say “relatively simple,” all I mean is it’s simpler than OpenGL. Porting it would not be an easy task.