Question about runtime differences.

terrymisu · 25 фев 2013

I just realized that the runtimes each have slightly different files in the data directory, and I fear I may have wasted some time working on my Python port.

Nate - can you explain why the Corona example uses individual images with only a skeleton and walk file, while the other runtimes each seem to use a packed texture file and additional data - for example the .atlas file in the CPP runtime.

I'm a little bit confused about how all of this is bolted together, considering the differences between the various runtimes.

I've made a lot of progress, but I think I need to step back and understand the architecture a little bit better before I can finish the port up.

The Lua stuff looks a bit simpler, so maybe I'll poke around there, but an explanation of why things are different would be much appreciated.

Thanks.

terrymisu · 25 фев 2013

Nate · 25 фев 2013

Corona's spritesheet support is poor. I used individual images because I didn't feel like writing a texture atlas for it, though may still do so for the generic Lua runtime. You can actually use a spritesheet with the Corona runtime by using an "image sheet" in the attachment resolver and passing an "image group" to Skeleton.new. However, Corona spritesheets use an index and not a name to look up regions, which is silly. Another reason I didn't bother with an atlas for Corona is that Corona is not a high performance library and I'm not sure it is worth trying to squeeze more performance out of it. If it is a problem we can add it.

I wrote a texture atlas for SFML because it has an efficient way to draw from an atlas, but didn't have any atlas format parser.

Runtimes are free to use any atlas support built-in to their game toolkit, they don't have to use the atlas stuff in spine-cpp.

An atlas is ideal for performance, because switching which texture is bound is generally an expensive operation.

terrymisu · 25 фев 2013

Ahhhh ok. That totally makes sense.

Can you explain why libgdx has .skel and .anim files in addition to the .json files? Is that what Spine's binary data looks like, or are those files something else entirely?

The JSON parsing for the skeletons in Python came out an order of magnitude cleaner than the C++ code, but I'm finding the parsing of the atlas files to be quite cumbersome.

What generates the .atlas files? Is that your texture packer, or something else?

Nate · 25 фев 2013

The .skel and .anim files are the binary format. I've only written binary parsers for the libgdx runtime, since JSON is enough for people to use other runtimes. Will come back and do it later.

Yes, it's the libgdx texture packer. Also texturepacker.com can output the libgdx format. A line-based format should be easy to parse.

terrymisu · 25 фев 2013

Thanks Nate.

I was able to write an entire atlas parser in less than 50 lines with Python. For now I've just stored everything in a dictionary.

Can you double check my work? Here's what a parsed page looks like:

{'filter': ['Nearest', 'Nearest'],
 'format': 'RGBA8888',
 'name': '../data/spineboy.png',
 'repeat': 'none'}

Here's what a region looks like:

 {'index': '-1',
  'name': 'right-hand',
  'offset': ['0', '0'],
  'orig': ['32', '32'],
  'rotate': 'false',
  'size': ['32', '32'],
  'xy': ['214', '2']}

terrymisu · 26 фев 2013

Nate - Can you post an example or point me to an example of an atlas file that has splits and pads?

It doesn't look like spineboy has this, and I want to make sure I can get it properly incorporated into the Python runtime.

Thanks.

Nate · 26 фев 2013

Sure, looks like this:

zoom-horiz-bg
  rotate: false
  xy: 1, 1
  size: 40, 11
  split: 19, 19, 0, 11
  pad: 14, 14, -1, -1
  orig: 40, 11
  offset: 0, 0
  index: -1

Splits and pads are not used by Spine. They are usually output by the texture packer, with certain input images:
https://code.google.com/p/libgdx/wiki/T ... inePatches
Here is what the splits mean:
https://code.google.com/p/libgdx/wiki/G ... mmatically
Pads are similar, except they are used to determine how to much to pad something that is drawn on top of a ninepatch. Ninepatches are used extensively in UIs.

mr.Ugly · 26 фев 2013

Nate написал
However, Corona spritesheets use an index and not a name to look up regions, which is silly. Another reason I didn't bother with an atlas for Corona is that Corona is not a high performance library and I'm not sure it is worth trying to squeeze more performance out of it. If it is a problem we can add it.

well i would like to see corona spritesheet support

Nate · 27 фев 2013

As mentioned, "You can actually use a spritesheet with the Corona runtime by using an "image sheet" in the attachment resolver and passing an "image group" to Skeleton.new." Then in the AttachmentResolver, do what you need to do to get the image from the image sheet.