While file size doesn’t necessarily equate to performance the reduction of nearly 500% for each animation cycle (23kb → 5kb) will undoubtably help with loading times when scaled to a large release game. Only difference is how it is exported in a single sheet. The exports are all from Aseprite from the same file with the same resolution and file format.

The file size containing all frames of the walk cycle is 23kb while the sprite sheet itself is only 5kb. Just as a quick example take a look at the screenshot below. Advantages here seem immediately intuitive. Having all of those files bundled into a single character sprite sheet with all animations would be SO much cleaner. If you have dozens of multi frame animations it makes the resource manager frustrating to navigate as you’re scrolling at best dozens if not hundreds of files that are all part of the same resource. I’ll keep an eye on this conversation to read future comments on the matter. If we get enough user input and the feature makes it to development, the engineers would have to think of a technical solution to evenly cut a sprite sheet (since not every element has the same size).Īs Silver said, working with sprite boundaries is tricky because getting one extra pixel on the frame cut would mess the whole animation (thanks Silver-Streak for the documentation!). If it does improve performance, might be another question… Therefore, importing a sprite sheet even when the art has been made custom is a possibility too? (I need more data from user’s experience on this). When I produced animated art for video games I exported them frame by frame, but the developper used a solution to create sprite sheets to improve performance (we were making educational video games optimised for limited technologies). Defold and CT.js both support atlas generation but not direct spritesheets (Defold has some workarounds using tilemap atlases, ct.js does not accoeding to their documentation)Īnd those who create their own art export frame by frame (since they animate frame by frame). Interestingly, from a quick google a lot of engines generate atlases (spritesheets) on their final build, but only support individual images during dev. A spritesheet splitter would not eliminate this problem, while a texturepacker and spritesheet support would eliminate this problem. I imagine the technical ask would require an UX panel for sprite objects that allows them to auto detect sprite boundaries from the sheet (or allow the user to manually define them) and use them for respective animations, then use spritesheet.js to generate the data json, then use that for rendering in Pixijs.Īlternatively you could have something that just autosplits spritesheets for users as a shorter term solution, but while spritesheets don’t have a huge benefit for performance, they are important for html5 hosting optimization on places like Itch.io which has filecount limits for uploaded html5 games. It supports spritesheet data made by spritesheet.js ( GitHub - krzysztof-o/spritesheet.js: Command-line spritesheet generator supporting Starling / Sparrow, PIXI.js, Easel.js and cocos2d) and others.

Import texturepacker into unity