Every tres file loads the whole spritesheet

[Keetz]

I am pretty sure every .tres file generated loads the whole spritesheet and then use uses a region of that spritesheet, leaving a huge impact on memory which is the exact opposite of what using a spritesheet should do.

Right now it is better performance wise to just not use this plugin, and just have each frame individually in godot.

Example: Let's say we have a 10x10 setup, with each "frame" being 128x128 pixels. That means the whole spritesheet is a image sized 1280x1280 pixels (if everything is perfectly packed and so on, example! :smile:)

So the idea is that we only have to load the 1280x1280 file once and just use different parts of it.

Alternatively we would load each frame individually and therefore load 100 files that are 128x128 pixels.

But!

As this plugin works right now, it generates a .tres file that loads the spritesheet and then defines a region that should be drawn.

This means that the plugin, in this example, generates 100 .tres files, one per frame. Each one of these 100 frames loads the complete spritesheet and then only draws a set region of it. So we now have 100 .tres files, that each load the 1280x1280 pixels big spritesheet.

This can easily leave a huge impact on memory!

[piratesephiroth]

This issue is weird if it regards sprite animation because you can group all your frames in a single AtlasTexture then load it onto your sprite and specify how many vframes and hframes it has.

If that's not what's happening then the plugin is really very broken.

[CodeAndWeb]

I know about this issue. It seems that godot is loading the texture file multiple times instead of sharing the reference to it. There's already a bug reported and will hopefully be fixed soon:

https://github.com/godotengine/godot/issues/21506

[Keetz]

@piratesephiroth yes, in godot you can just assign a png file (spritesheet) to a sprite and set VFrames and HFrames, but that is not how this plugin works, so it isn't really applicable here.

[piratesephiroth]

Well, @CodeAndWeb, I found a workaround but I didn't make a pull request because I don't understand resource saving in godot.

Things work exactly as expected if you load the texture in the atlas as an external resource.

I mean, instead of using

[sub_resource type="StreamTexture" id=1]

flags = 7
load_path = "res://.import//.import/derp.png-ad63f2aabbe17b2b7bb609883db63a77.stex"

you use

[ext_resource path="res://.import/derp.png-ad63f2aabbe17b2b7bb609883db63a77.stex" type="StreamTexture" id=1]

[piratesephiroth]

OK, turns out it is a silly problem with this plugin indeed. It was intentionally denying the caching of the texture.

I still submitted a super simple pull request though, hah

[jesperkondrup]

Nice! I can confirm that setting this last argument in the "image_loader.gd" to false seems to work: image = ResourceLoader.load(total_path, "ImageTexture", false)

[CodeAndWeb]

The updated plugin is already in the asset library.... thanks to @piratesephiroth