Write a Python script to automate emote packing

[codecat]

trafficstars

Automate emote packing using a Python script. It would take as an input the following:

{
  "name": "Better Chat Global Emotes",
  "emotes": {
    "Kappa": "https://static-cdn.jtvnw.net/emoticons/v2/25/default/dark/1.0",
    "peepoHey": "https://cdn.7tv.app/emote/60aeec1712d7701491f89cf5/1x.webp",
    "Bedge": "https://cdn.7tv.app/emote/60ae8d9ff39a7552b658b60d/1x.webp"
  }
}

Then, download all emotes in emotes and pack them into a single spritesheet using a rectangle packer algorithm. (Maybe this one?) All emote frame positions and sizes can then be placed in the json definition automatically.

Animated emotes must have all its frames placed in the spritesheet as well, and frame times must be automatically placed in the loading json. We will probably also need some kind of optimization for this, so that we don't fill the spritesheet with 500 identical frames. (Doesn't have to be automatic, we can define this in the json described above as well.)

Note: This is a semi-big project with low priority. This might be suitable for a new repository instead.

[XertroV]

I wrote the core of this while making a custom spritesheet today (the core being: take a json doc in the format specified and spit out a png sprite sheet and something very close to Emotes.json. It's not exact: there's an extra dir field for if it's left/right facing, and single-frame emotes aren't optimized in the json (they have a .frames[] with 1 entry, rather than having .pos).

That rect packer repo you linked didn't work for me, but this one did.

The script has a few extra bits (lines 16-216 ish), with most of the important logic being line 284 on. Example output is included as tmp/out.* in the zip (png, json)

sprite-packer.zip

out.json

[codecat]

Very nice! Might have to look into integrating this with the repo. Did you want to make a separate repository for this? That way we could support external sheets in the future, too.

One thing to note is the animated example has duplicate frames (indices 1 and 2 are identical to indices 5 and 4). That might potentially be a bit complex, but it's definitely not required and could be a potential future improvement.