- Đã chỉnh sửa
Binary export is incorrect
Hi. I'm very happy to see a binary format for spine available and documented! Unfortunately as it stands now either Spine itself is faulty of the specification is incorrect.
If we look at the first few bytes of a .skel file exported by 3.4.02 Pro and decode it using the rules specified in the spec...
The header bytes are parsed OK. We get the hash string, the version string, the width, the height, the non essential flag ( true here ) and the images path (empty here). We then parse the number of bones correctly ( 38 = 0x26 ).
Now we start parsing the first bone. It does not look like all the float parameters are correct, but we can at least parse the first bone and stop at a point that is obviously the start of the next bone. This bone is parsed until we get to the last field - the bone colour. This is obviously incorrect. The colour set in spine is 9B9B9BFF ( correctly read for the first bone ) but here we can see what looks like a one byte offset from where we expect the colour value to be and where it is.
If I was to hazard a guess I would say that the trouble lies with either the bone length, transform mode or colour serialisation.
Anyway, thanks again for including this feature and I hope this can be fixed quickly as a binary spine format is greatly appreciated.
Mike.
We try to keep the spec up to date, but it's possible something was missed as features are added. The spec may also be more up to date than the version of the editor you are using, since we don't attempt to keep a spec for the every editor version's exports. Compatibility is done at the Spine project file level. If you are using 3.5.xx to export, it could be the transform mode enum that was added recently (or the opposite problem if you are using 3.4.xx to export and expecting the transform mode enum which was adding in 3.5).
The reference implementation in spine-libgdx may help, though you won't want to look at that if you are attempting your own clean room runtime implementation. Currently master is v3.4.02 and the dev branch is 3.5.01-beta. Are you writing your own runtime or using an official runtime? If the latter, remember that official runtime support is only guaranteed to be compatible with the latest non-beta editor version.
OK, thanks for the info. I was using 3.4.02.
Not keeping a spec for each released version makes it kind of unreliable for anyone writing a binary loader don't you think?
I tend to keep any specs to be released in our source control repo itself so they can be updated and versioned along with the code. It makes it easy to publish the correct spec with each release.
We have our own system for 2D animation since we didn't really find the performance or blending features we were looking for in the C reference runtime so we load spine files and the data is converted into a format more convienient for us.
Thanks again for the reply,
Mike.