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.

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.

Not sure we are talking about the same thing :-)

I want a quick way, when given keys at:
0, 4, 8, 16, 32, 64
to scale them (by for example 1/4) to result in keys at:
0, 1, 2, 4, 8, 16

I don't want to move them one by one (there may be loads).

I didn't know about bone visiblity effecting the dope sheet - thanks! That will be useful elsewhere - but it doesn't really help with the scaling issue.

Anyway, my script solves it for me. Just would be nice in the editor.

Aha!

I missed that you could grab the end of the selected time span and drag that to scale!

Thanks for the help BinaryCats and apologies for my slow uptake!

Mike.

I absolutely agree with this suggestion! It would really make tweaking animations easier.

You could either:

1. Add an additional bone under the root that you move your skeleton into and then attach the bg to the true root:
   Root -> NewRoot
   Root -> BG

2. Just create another skeleton to contain the BG.

HTH

The Shift command just moves all following frames as well as the frame you are currently moving. It helps a little but is a far cry from actual time scaling (especially if you want to time scale some bone frames and not others).

The JSON export/import came to the rescue though as I just wrote a small script to process the json and scale all keys I want scaled :-)

I could really do with this as well.

Complex animations have keys spread over the duration of the animation making manual time scaling of the animation incredibly painful.

This is a really basic tool in most animation packages, I'd love to see it in Spine.