Problem with large sprites: Image width cannot be greater than 16384.

[dploeger]

When importing a sprite with larger dimensions (the attached one has 786x935 per frame), the import reports

Image width cannot be greater than 16384.

I guess, you're creating and exporting a sprite frame here and import it, but it gets too large.

[dploeger]

Hm. Can neither attach the aseprite nor the zip of it. If you need an example, give me a hint and I'd share it on my gdrive.

[viniciusgerevini]

Hello @dploeger. Thanks for finding this issue. I guess you found a limitation with using spritesheets in Godot.

I did a quick search and I found this limitation in the docs.

Note: The maximum image size is 16384×16384 pixels due to graphics hardware limitations. Larger images may fail to import.

You are right. I'm using the --spritesheet option from Aseprite, and as the sum of your frames width reaches Godot limits, it mess everything up. To make the plugin work in such cases, I'll have to automatically break the sprite sheet in multiple images. Externally it wouldn't change anything. I'll spike different approaches and check if there are any drawbacks.

By the way, are you using the manual flow, through the dock, or the automatic importer?

[dploeger]

Thanks a lot. I'm using the automatic importer.

[dploeger]

btw: I used multiple layers and tags to organize the file like this:

I'd want the result to be in one SpriteFrames resource with the animations named like - (e.g. right-idle).

Aseprite seems to allow exporting layers and tags into separate files when exporting a sprite sheet. Maybe that will help.

(does the addon support the result the way I described currently or should I open a feature request for that?)

[dploeger]

Maybe you could rewrite the export to use the --save-as command using templates like --save-as sprite-{layer}-{tag}-{frame}.png. This would circumvent exporting it to a sprite sheet with too big dimensions.

[dploeger]

Although... that would result in a very large amount of files...

[dploeger]

Using --split-layers with --sheet doesn't seem to work properly. See aseprite/aseprite#2889

[viniciusgerevini]

I'd want the result to be in one SpriteFrames resource with the animations named like - (e.g. right-idle).

Currently in this plugin you are able to split by layers (right.res, left.res, etc) but not by tags. I wonder what would be the benefit of having right-idle? (besides mitigating the problem). In this case you would have multiple SpriteFrames resources with only one animation.

Although... that would result in a very large amount of files...

Yeah, but I don't think there is any way around it. To support big files, multiple small files would have to be created. However, I could split the images by tag, but maintaining one resource file. That might work and it wouldn't create too many files. It doesn't solve the problem entirely, but it does make it less likely.

There is one immediate thing that can help with this issue. Currently I use the spritesheet default behaviour, which is creating a row. If I change the command to use the packed algorithm, the spritesheet will distribute height/width better. Does not solve for all cases, but it's a good start.

[dploeger]

Currently in this plugin you are able to split by layers (right.res, left.res, etc) but not by tags. I wonder what would be the benefit of having right-idle? (besides mitigating the problem). In this case you would have multiple SpriteFrames resources with only one animation.

Like you see in the screenshot, one tag spans around multiple frames. So "right-idle" would include all frames of the "idle" tag that are on the "right" layer. The same way I created my animations manually now:

There is one immediate thing that can help with this issue. Currently I use the spritesheet default behaviour, which is creating a row. If I change the command to use the packed algorithm, the spritesheet will distribute height/width better. Does not solve for all cases, but it's a good start.

Thanks, but I tried changing that, but it didn't work, because even switching to packed or columns, the image is too big for my sprites. 😢

[zextillion]

I ran into this same issue with my Aseprite file. For various reasons, I can't use the trim functionality to reduce the image width, so I modified the code inside my project to fit for my use case. My use case involves exporting each layer AND tag individually, but this can be generalized for the case where you don't split up layers too.

I added an option to export each tag individually. This creates one folder for each tag inside the base output folder, and the exported layers now go inside this folder. Once all the tag folders are made and sprite sheets are exported, it gets a reference to that layer's SpriteFrames resource. If it's not under the base folder (it hasn't been created yet), it will create it. Otherwise, it will load that pre-existing SpriteFrames resource and add that tag's animation/layer to it.

If this sounds like a good idea to add, I might try to clean up my code and open a pull request.

Note: If the sprites are too big, and there are too many frames in the tag, then it still might end up over the image width limit. This can then be mitigated by using the trim options, but then you'll end up in the situation I was in. To go one step further, you can then add multiple rows to the exported spritesheet to keep the height and width somewhat square-y. Eventually, you'll hit the point where even that's not enough, but if you end up going past that image height/width limit using aseprite animations, I think you have a completely different problem altogether lol

[viniciusgerevini]

Thanks @zxtion . That will certainly going to conflict with the major refactoring I've been working on. I feel I understand the solution, but I can't really visualise it. Feel free to send it if you feel like it.

I had put some thought on this issue. I guess the best approach is to have an option like "Big file mode" or "Big file support", which would export each frame as a separate png. That would be seamless for the SpriteFrames as it embeds the files, but not really that straight forward for the new AnimationPlayer support.

Also, I'm certain the file generated would be bigger than the normal one, but I think it's an acceptable trade off for supporting this case, and also we are talking about pixel art, so it would certainly be smaller than a high resolution equivalent.