Travis

Hey all,

I'm new to these forums, and I'm developing my own runtime that following my engine code's conventions, and uses its own datatypes internally (my own vector, matrix, easing classes, etc). I was just wondering, is there any documentation on file format? Also, is there any information on the binary format?

So far, I was able to get the bones and the slots loaded up. I just have some questions a few things work:

-Is there always a "default" skin? For example, when loading the atlas, if the sprite definitions doesn't specify which skin will be attached to it, should I just assume that it's the first skin loaded from the animation file?

-What is the "index" field that's listed at the end of each sprite definition in the .atlas file? I looked at the libgdx documentation, and it looks like it could be related to filename suffixes?

-I noticed that the spineboy.json file I'm working with right now has an animation labeled "drawOrder" right under "animations". Is this an animation, as in a setup?

-Each animation key has a "curve" field that's always got 4 float between 0.0 and 1.0. After looking through the C runtime source code, it looks like they are interpolation weights for x1, y1, x2 and y2 coordinates? Am I close?

Ok, it turns out I forgot about this link regarding the JSON format:
http://esotericsoftware.com/spine-json-format/
Travis
  • Сообщения: 2

Nate

There is always a default skin.

Atlas indexes:
https://github.com/libgdx/libgdx/wiki/T ... ge_indexes

"drawOrder" is an animation name in spineboy, for testing draw order.

All other questions should be answered by the JSON docs. :) Feel free to post if not.

Why not use spine-c (or other generic runtime) and write an API on top of it that meshes with your game toolkit? Then you get bug fixes, new features, etc without having to implement and maintain it yourself. This will save you considerable time, both initially and long term. The official APIs are intentionally low level so they are flexible enough to handle pretty much all animation needs. It is expected most any game will want to write an API over the top based on the particular needs of the game.
Аватара пользователя
Nate

Nate
  • Сообщения: 9766

Travis

I seriously thought about it, but I wanted to write it myself. With that kind of control, I can optimize loading time a little bit better for slower devices. Even then, I just like being a control freak haha.

If I was working on this in Unity where everything is emulated anyway, I'd be down for using the other code, but for some reason, when I write anything that's lower-level code, I like writing it from scratch. I like writing loaders like this anyway.

I see, so the animation called "drawOrder" will be treated as any other typical animation, but the drawOrder timeline will be treated as a timeline for changing the draw order of the sprites (aka attachments) over time. Also, I noticed an attachment had additive blending applied to it in the JSON file. I could see why that type of blending could be useful when drawing moving objects on top of each other to make them look like one object, but additive blending is only useful if pixels have partial alpha, right? For example: having glow-like sprites overlapping with additive blending gives a nice neon look, but drawing two objects with either completely opaque or completely transparent pixels won't affect anything, right?

Either way, I'll just draw additive sprites in a separate vertex array, which means it could take up to two draw calls to draw an object.
Travis
  • Сообщения: 2

Nate

FWIW, spine-c is pretty efficient for loading. The object model isn't going to force any inefficiencies on your rendering or procedural animation. Its weakest point is using linked lists instead of a hash map in Skin, but since attachments are looked up in a skin so rarely (worst case, a couple times a second), it isn't much of an issue. NIH is perfectly fine, as long as you realize you are doing it and that it may end up taking more of your time. Often the fun can be in how you get there, not solely in the destination. :)

Yes, additive blending is mostly useful for when using images with alpha that combine for interesting effects, and it usually breaks batching in most rendering systems.
Аватара пользователя
Nate

Nate
  • Сообщения: 9766


Вернуться в Runtimes