Single header C library for parsing/using exported data and playing animations

[foxnne]

@ZackeryRSmith

Reasoning

This is an extension of a note that parsing the atlas requires a lot of manual labor. The goal of the project was to export a simple json file that included all the data needed to align the sprites back to a grid using the offset and source for each sprite, and then animations being just lists that include timings for each sprite index.

{
    "sprites": [
        {
            "origin": [
                0,
                22
            ],
            "source": [
                0,
                0,
                22,
                22
            ]
        },

...

"animations": [
        {
            "name": "pencil_default",
            "frames": [
                {
                    "sprite_index": 0,
                    "ms": 1000
                }
            ]
        },
...

this describes the pencil used in Pixi as a cursor. It is the first sprite in the atlas, and the origin is set to the pencil tip such that it is drawn at the mouse position offset from the top left.

However, It seems to really trip people up that this origin value includes the origin of the sprite set through Pixi. We currently do not have UI to set the sprite origin, so every sprite currently defaults to an origin at the top left corner.

This means the exported atlas data includes the distance the sprite shrunk when it was packed, such that each sprite can be back aligned to stack with other sprites of the same origin.

When Pixi allows users to set a per-sprite origin, this will allow the artist to specify the origin point at design-time and the programmer no longer has to choose and set an origin, or manage setting these origins per sprite later on when drawing them in-game. The idea would be that the final sprite rendering code just offsets the sprite position by the origin value and the sprites would be drawn correctly. i.e. origin at characters feet rather than the top left of the sprite.

Proposed changes

I don't really believe theres much of an issue with the data we are exporting. But I want to make using that data easier.

• Potentially just find a better name for origin such that it better describes that the value includes the offset to realign the sprite at the origin the user specifies.

• Eventually write a small portable single-header C library that can be consumed in other languages that can help users interpret the data Pixi exports. I think this would be a great bridge to allow other frameworks and engines to very simply import and use Pixi data

[ZackeryRSmith]

One of the biggest pains to me is accessing a specific sprite by name without adding an animation. At the very least my usage of Pixi in PixTTF will likely not extend past icons. Adding a blank animation for each icon would effectively double the file size of the atlas. Not doing so would require me to manually keep track of which sprite is at each sprite index. In my case I would much prefer

{
    "sprites": [
        {
            "name": "pencil",
            "origin": [
                0,
                22
            ],
            "source": [
                0,
                0,
                22,
                22
            ]
        },

...

Of course for animations this essentially makes no sense. name can easily be an optional field in those cases. Another approach is defining a more generic way to store arbitrary user defined data. An example of that may look more like

{
    "sprites": [
        {
            "origin": [
                0,
                22
            ],
            "source": [
                0,
                0,
                22,
                22
            ],
            "metadata": {
                "name": "pencil"
                // assuming the data here is arbitrary allows for fields like
                // "category": "tools"
            }
        },

...

Personally lean towards the latter, however the former is certainly viable but less "extendable"