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.
