An updated Spine runtime

[jeremyfa]

Moved issue from https://github.com/HaxeFlixel/flixel/issues/1973 to the flixel-addons repo as suggested by @Gama11

Hello team,

I am currently using Flixel to develop a game that uses Spine animations. My first attempt was to try to use spinehaxe with the related FlxSpine class and example, but I quickly ran into problems: the spine runtime is a bit outdated compared to the official runtimes, thus I could not read all animations properly (no shear, for instance).

Spine and some of its latest features being a requirement for the game, I checked if it would be easy to improve the current spinehaxe repo, but at the end, the quickest and most efficient option was simply to make a new port based on the official AS3 runtime. The result and complete explanation can be found here:

https://github.com/jeremyfa/spine-hx

The idea is to stay as close as possible to the official AS3 implementation, in order to make updates easy when the official runtime will be improved.

Then, I edited FlxSpine class (and related) to use this new runtime. The code can be found here, along with the updated example from flixel demos:

https://github.com/jeremyfa/flixel-spine-hx

I also slightly changed how the animations are drawn when using quads: some 2d transformations could not be expressed by just changing rotation/scale of FlxSprite objects, so I added an FlxTransformableSprite that can use a custom matrix for drawing. So, the drawing of each sprite is simply done by getting the matrix values provided by the runtime (Note that this FlxTransformableSprite is completely independant from FlxSpine/Spine and can be used for other purposes).

The code is pretty recent, but so far, all the animations I tested work as expected, even when using latest Spine features. Feel free to give it a try!

[bendmorris]

We had a short exchange about this on Twitter.

Spinehaxe was based on the AS3 runtime of the time, but it always seems easier to port from scratch instead of tracking changes in the AS3 runtime and keeping it up to date - like you did with spinehaxe, and like I did with @nitrobin's spinehx (and we all need to get better at naming things too 😛 ) It's a full time job to keep it up to date, they introduce new and breaking changes constantly.

I think it will be annoying for users to keep shifting where the Spine support lives, and introducing small API differences (to use FlxSpine you have to interact with the runtime as well.) There needs to be a solution that keeps one library up to date and doesn't keep reinventing it. Not to mention that spinehaxe is used by more than just flixel users.

This was the main reason I started the discussion about consolidating third party support libs. I don't care which port ends up being used as long as we make sure it's sustainable. I tried using your library as a drop-in replacement for one of my projects and it didn't immediately work due to breaking API changes.

In this case, I wonder if we could get Esoteric itself to own the Haxe runtime? Haxe is close enough to AS3 for the updates to be straightforward, if enough of us are using Spine maybe they'd consider it. There are 18 official runtimes, and we might be more popular than AS3 at this point, so why not? If they're willing, your version could be used as the starting point, but I'd want to simplify some of the "compat" package which IMO is not necessary - the copied files from OpenFL, the "Dictionary" Map wrapper for example.

:+1: on FlxTransformableSprite, that was definitely needed!

[jeremyfa]

Some notes about choices made that may differ from current spinehaxe repo:

• The name is spine-hx because it follows the official naming adopted in the official runtimes repos (spine-as3, spine-ts etc..).
• The package name is spine instead of spinehaxe, just like in the official runtimes (like, the as3 version uses a package name spine and not spineas3)
• The API changes follow exactly the ones changing on the official runtime as it is a direct port of the code. If an updated haxe version has breaking changes, that means the official runtimes do as well. It sounds fine to me.
• I didn't add any haxe specific code on the spine-hx repo, on purpose. Anything Haxe specific should stay outside of the runtime, as a separate helper.

While changes are happening quite often on the official runtimes, I don't think it's really an issue to apply changes as long as we really stick with a single reference implementation (as3) and we don't try to make our own changes to the haxe runtime (we need to favor parity over the rest).

I would also not qualify the maintenance as a "full time job". It's however a regular job that has to be done at every significant Spine update, like when moving from Spine 3.4 to 3.5. According to the changelogs, this happens about once every 2 months.

That means, once every 2 months, someone has to check this link of spine-as3 changes and apply the same changes to the spine-hx repo.

That sounds doable to me, given that we stick with the rules above.

[jeremyfa]

Regarding the compat package, we could indeed remove it eventually, as long as the code stays almost identical to the AS3 version.

It's there mainly because of how the code was generated (with as3hx) 🙂 .