I’ve built a simple game engine ontop of OpenFl.
In my logic, everything has to inherit a class called GameObject (which extends openfl.display.MovieClip)
An asset called ‘assets.swf’ contains all the sprites and movieclips I want to display.
When I call Assets.getMovieClip I convert the hierarchy into GameObjects, by convert I mean copying all the properties over and stealing the children (I lure them with sweets), then killing the old MovieClip (this is just barbaric), but this breaks any animation within the asset.
So I’d like to know if it’s possible to tell Assets.getMovieClip to use my GameObject class instead of openfl.display.MovieClip?
I know it’s likely the ‘wrong’ way to implement my own system ontop of openfl, and somewhat inefficient, but this is a just a quick project and I don’t want to rewrite a load of stuff now.
It’s a hack, but you could change this line to your
Long-term, I think we should get the “base class” property from the FLA working for this, what do you think?
Oh wow that’s delightfullysimple.
Means I have to edit the source files though… Considering the way haxelib works I don’t like this.
Just make it a compiler argument, right?
I was thinking more like:
Supporting a custom “Base Class” value other than MovieClip. I think the Adobe Animate complains if it is not a known AS3 class, but there may be a way to work around that
Another alternative (if possible) would be to add the display MovieClips as a child of your game object. This adds one level of indirection, but does allow you to use them as-is
that would mean my display object count would almost double. I haven’t done a speed test but I assumed my way - while somewhat messier - would be better for performance.
I like the idea of using the baseclass value from the swf, however I assumed the base class reference string was completely ignored during compilation if said class didn’t exist.
I also like my idea of just saying “ALL SWF MOVIECLIPS ARE MYCLASS” as a tag in the project.xml.
It’s a bit graceless but that doesn’t bother me.
The more options the better
We’ve tried to design DisplayObjects to be as light as possible, so I haven’t seen a notable performance cost to having additional non-rendered display objects, but if we do find anything that seems heavy we can look into improving it