Request for Spritesheet format specification

[andrewmcwatters]

Hey folks! We'd like Grid v1.8.0 to include some basic spritesheet animation functionality, so you don't have to roll your own anymore. Below are comments regarding this format. @Planimeter would love to have your input on the matter.

[andrewmcwatters]

This post reserved for developing revisions.

Revision 3:

Changes:

• Added width and height

Example:

return {
  width = 32,
  height = 64,
  frametime = 0.6,
  animations = {
    {
      name = "Walk",
      from = 1,
      to = 4
    },
    ...
  }
}

Behavior:

Spritesheet image width and height (not to be confused with frame width and height seen above) will be automatically detected by engine, and as a result, no such members will be necessary in the metadata.

from and to will represent the frame number start and end values for a given animtype, such as "Walk" above.

[dykatz]

A concern I have with just that is when a sprite sheet atlas is not aligned perfectly on a grid, or is packed so that frames are in a semi-random order, this will not work. I believe that instead of a simple from = 1, to = 4, we should send in a list of rects. On a side note, the subtable animations is redundant, and should be removed, and the name attribute can simply be the key.

Here's my take at it, for max flexibility:

return {
  walking = {
    fps = 45, -- Use this key to properly set the frame time
    anchor = 'center', -- maybe also use `anchorx` and `anchory`
    image = 'image.png', -- different animations can be on different sprite sheets
    { x = 16, y = 32, w = 32, h = 32 },
    { x = 50, y = 32, w = 32, h = 32 },
    ...
  },
  ...
}

[andrewmcwatters]

I guess my initial thought was that frametime would be a member outside of animations, since I'm not sure if animators would want to use variable frame time across animtypes.

I agree with the sentiment concerning packed spritesheets, but feel that individual rects/quad definitions per-frame is perhaps more granular than necessary. It's certainly not out of the question, though.

In an ideal world, you'd pack animations such that no gaps existed. What immediately comes to mind is the way that freetype-gl packs glyphs.

That being said, I would guess you'd find very little tools capable of doing this.

Bringing @ryan-kingstone and @Polkm into this. I'm curious what they have to say. Perhaps @vrondakis as well?

[andrewmcwatters]

@muddmaker image is a great feature, by the way! I'd like to see that in the engine.

[dykatz]

That being said, I would guess you'd find very little tools capable of doing this.

There is actually a public domain stb library that does exactly this!

A possible improvement to the design is have a location where default values can be put for w, h, fps, and the like, while still leaving them to be overridable later, which makes things less data heavy, while still allowing for the flexibility.

[andrewmcwatters]

Very cool lib code! Does anyone know if there are existing gamedev tools out there that use this? My experience is just with Adobe's toolset, and I don't think PS has anything this fancy.

I just want to be mindful of any defacto tools out there in order to export to something easy to work with. I agree with default values and overrides, I'll add that to r3.

[andrewmcwatters]

Also, it should be mentioned that the current recommended toolchain for creating these animations will be Adobe Photoshop. I don't think this is exactly an optimal recommendation, however. Perhaps we should include more than one recommend tool for use with this format.

[dykatz]

Why would it matter what the tool is? Will you be writing plugins for image editors that allow the ease of making and packing these as well? Or will you be making a separate utility for generating these?

[andrewmcwatters]

It really shouldn't matter what the tool is, but in practicality, some frequently used tools like PS export frames in really convenient ways.

On a related note, I had discussed with some team members about the possibility of having the engine automatically seam together individual frame images in development mode and generate spritesheets if it detected an export from a tool with a predictable name series: goblin 1.png, goblin 2.png, ... so you can do all your testing in livereload development.

[dykatz]

Will grid also have support for the types of interpolated animations generated from anything like spine? I generally like that style more, as they are less frame rate limited and store less data on sprite sheets/texture atlases.

[andrewmcwatters]

I think spine is super cool, but to implement those types of animations is a bit outside of the scope of Grid at the moment. We're promoting dogfooded(?) features from Vertex Adventure into the public engine.

With the upcoming addon functionality (#61) this could certainly be possible, though.

[andrewmcwatters]

Marked for initial release today in v1.8.0.

[andrewmcwatters]

Released in v1.8.0