[BUG] Frames not in correct order when exporting PNG atlas with Alias

synchra

Hello, I hope this is the proper section to post this in, I am not sure. We aren't sure if this is a bug or not, it's definitely a bug for us with our game workflow though!

When I export a PNG sequence packed as a texture Atlas, the frames will not be listed in the proper order in the Atlas file when I am using Alias to get rid of duplicates. This causes the playback to be super wonky in the Godot Engine for us. It works fine if we just re-order the frames but by default they're not in order when we export with Alias. They're in the right order when I don't use Alias but that makes much bigger files obviously and we'd like to make these as small as possible.

I am on a MacBook Pro (Apple M3 Max Chip) running MacOS Sonoma 14.5 and I am using Spine 4.2.33 Professional. Here's some examples of the Atlas files:

handupperarm-l-loop-idle-alias.atlas

14kB

handupperarm-l-loop-idle.atlas

14kB

synchra

Spinebot How do I submit this as a feature request, also where do I submit a bug report? I thought that you were supposed to post bugs to the forum but I couldn't find the bug report section.

Nate

Sorry, Spinebot didn't provide terribly useful information. When that happens a human will come along and delete Spinebot's pose. Sometimes it's great and gets you unstuck right away, sometimes it's not so great. 🙂

Generally posting in the forums for assistance is the right thing to do. We can create issues on our tracker, if it turns out assisting your requires fixes. If you are 100% sure you have a bug, you can post on our tracker yourself, but please don't use the tracker for discussion, only for bugs. You can see an overview of our editor and runtime issue tracking on our roadmap.

Can you explain how you are using the atlas? Are you using it with skeleton data? For that the order of entries in the atlas should not have an effect.

In general there is not an attempt to output atlas entries in any particular order. When using alias likely entries are in a hash map, so the order is effectively random. When not using alias, the order is probably coming from however the OS decided to list the files in the images input folder. This may or may not be what you want. Since the packer does not specifically order the entries, relying on this OS behavior isn't great and of course doesn't work with alias.

I think it does not make sense for the packer to try to sort the entries because some entries may appear on different atlas page images.

The packer has a feature indexes which causes it to remove suffixes that are underscore and a number, eg _123. It then stores the entries with the same name but a different "index". At runtime you can get all the entries with a particular name, then use the index field to sort them. This packer feature is not used by the Spine Runtimes, instead it's intended use is when packing frame-by-frame animation that will be rendered by application code.

I know libgdx fully supports indexes but I'm not sure about other runtimes/game toolkits. For example, spine-unity appears to read the index field but I don't see that it sorts the regions. You can sort them using the index field yourself pretty easily.