Initial Support for HaxeFlixel

[troyedwardsjr]

This works with Gama11's OpenFL 8 compatibility branch:

https://github.com/HaxeFlixel/flixel/pull/2136

As well as Beeblerox's OpenFL 7 compatibility branch:

https://github.com/HaxeFlixel/flixel/pull/2068

Working on all targets tested so far, especially HTML5.

Module namespace animation changed to animations because it conflicts with the HaxeFlixel API's namespace.

Works with DragonBones 5.0 data like the current master branch.

Working demo for Flixel in samples/HelloDragonBones.

https://i.imgur.com/ktlSM5w.gifv

[jgranick]

I see a few changes to the Starling code, other code (such as @:keep throughout) as well as the aforementioned package name change.

Why is the package name change necessary? Could you explain the need for some of these other changes? @Gama11 Is a Flixel-specific renderer within DragonBones desirable?

[troyedwardsjr]

@jgranick I thought at the time that there weren't any new commits to Starling so I just copied it over from the previous pull request I made instead of doing a proper git diff. The @:keep was a mistake left over from a bad IDE search and replace.

Both have been reverted now, let me know if there are any other issues.

The animations name change is necessary because FlxSprites have a property called animation:FlxAnimationController and the dragonbones class FlixelArmatureDisplay extends a FlxSprite much like your OpenFLArmatureDisplay class extends an OpenFL Sprite, both of which implement an IArmatureDisplay interface. You'll get compiler errors if you try to override that property, so either the Flixel API needs to be changed or the OpenFL Dragonbones library needs to be changed to accomodate.

[Gama11]

@Gama11 Is a Flixel-specific renderer within DragonBones desirable?

As opposed to putting it elsewhere? Or at all?

[troyedwardsjr]

@jgranick Created a new pull request on a different branch (https://github.com/openfl/dragonbones/pull/10) without all of the unnecessary baggage of this branch's commit history so that I didn't have to rebase it.

[Gama11]

GitHub actually has several options when merging, so that probably wasn't necessary. :)

[troyedwardsjr]

@jgranick Readded the Fix DCE and Fix compilation with Starling 2.+ commits to this branch. Should be good to go now if don't see any other issues.

[jgranick]

@troyedwardsjr I want to leave the animation property as-is. I discussed with @Gama11 and I think there is a short-term solution.

Extend FlxObject or FlxBasic instead of FlxSprite, then if you need to, keep an FlxSprite instance locally to use for the rendering. Override your draw method, and in it, call the draw method of your internal sprite. That should render properly. Then there's no conflict with the animation property.

Long-term, it might be nice to find a way to integrate DragonBones animation with the Flixel animation system, so you can use a FlxSprite.animation field that behaves like Flixel animations.

I apologize this isn't quite as tidy a solution, but it does prevent breaking other code.

I'm willing to help make this change, or feel free to change it on your end, if you could :smile:

Thank you!

[troyedwardsjr]

@jgranick Done and tested with the demo. I can create a new PR but everything should check out with this branch and the master branch if you look at a git diff with the master branch and squash. Let me know if you see any other issues.

[jgranick]

Thank you for all of your work on this!