New Starling(MyClass) gives "Invalid root class"

When targeting html5 and MyClass extends MovieClip and when I call:-

starling = new Starling(MyClass, stage);

I get:-

Error: Invalid root class: {__name__ : [MyClass]} 
          at starling_core_starling.initializeRoot
          at starling_core_initialize
          at ...

When I change MyClass to extend Sprite, I still get the same error.

Looking at initializeRoot in the class Starling, it’s failing to decide that an instance of MyClass is of type DisplayObject in the line:-

 if (__root == null || !Std.is(__root, DisplayObject)) throw new Error("Invalid root class: " + __rootClass);

Has anyone seen this before? What needs to change to get this to run without raising an error?

Does your “root” for Starling extend starling.display.DisplayObject, instead of openfl.display.DisplayObject?

No, but now I understand. I see that starling and openfl aren’t in the same class hierarchy tree and they also have incompatible signatures. E.g. starling.display.MovieClip constructor has a different signature to openfl.display.MovieClip's constructor. Not very interchangeable is it, which makes more work in trying to convert flash code to use starling.

Are there any articles on converting flash to starling that includes a discussion on these compatibilities and why these incompatibilities exist?

OpenFL is GPU-accelerated, you do not have to use Starling if your code uses Flash classes already. What motivations are there for switching your code to Starling?

I’ve been asked to use Starling and targeting HTML5, iOS and Android.

@chrisvelevitch Historically Starling is an AS3 (Flash) library created to use Stage3D (display through GPU) in a way that mimics regular flash display list. It looks very similar API-wise but it’s much different under the hood.

You might want to take a look at Starling’s website for starters : https://gamua.com/starling/help/

@singmajesty my take on this is I have no idea how OpenFL GPU acceleration works. Whereas with Starling I know how to optimize performance : minimize draw calls, use texture atlases etc
Also I doubt it’s all GPU accelerated : sprite.graphics stuff for example. I’ll post about that at some point, I have UI items looking very bad when I move them : it’s all smooth on flash target but stutters on windows target despite framerate being a solid 60fps. Not a priority for me right now, hence why I didn’t post about it yet :slight_smile:

This is a key reason I have migrated my current OpenFL project to Starling also. The other reason is I’ve been developing with AS3/Starling for years, so there is the familiarity of it, which speeds up dev.

Here’s the basics of OpenFL GPU acceleration as of today:

  • Tilemap is one draw call per Tileset/shader. The default use results in one draw call per Tilemap. Simple
  • Bitmap is one draw call each, no batching in the current release
  • graphics.drawTriangles is one draw call
  • graphics.drawQuads is one draw call
  • TextField (and most remaining Graphics calls) render in software, then the final texture is rendered with GL

Bitmaps perform well for most projects, but Tilemap, drawTriangles or drawQuads is more ideal for many game objects or for particle systems

3 Likes

Thanks ! That’s very useful to know (also I hope my previous post didn’t come out as sounding harsh or something, definetely not the intention ^^)

Just to make sure I understand correctly : if I have 2 bitmaps sharing the same bitmapdata (and one after the other in the display list order) it results in 2 draw calls, right ?

Currently, yes, but you could combine them into one Tilemap to make it one draw call