Shared Spritesheets generation and it's optimization for memory usage reduction

Hello everybody!

In this thread, I would like to draw your attention to the generation of spritesheets (shared) in large projects.

I described my problem and the vision of its solution here:

https://construct23.ideas.aha.io/ideas/C23-I-346

You can also vote for it there.

Also, while this problem exists (at least for such large projects), it would be interesting to hear your ideas and thoughts on this matter. Thank you!

Or read it here:

Spritesheets packing improvements. (for less memory consumption in big projects)

Hello! Sorry my English, but I hope you will understand me)

Description and the problem:

I'm working on a big project. The game includes a lot of sprites for different parts of it - sprites for outdoor levels, sprites for indoor levels, another planet sprites, for different mini-games, images for the gallery (like bonus materials) and e.t.c... So, I facing a significant problem with memory waste, because of generated spritesheets also contains sprites from the part of the game that currently is not needed at all.

Just for example: in a generated spritesheet with 1-2 required object at the moment in the current game level - I see a lot of stuff from the another levels (with not cross-used graphics) to which the player will reach only after a few hours and it will be on its own layout... OR a sprite-sheet with one frequently used inventory item in it and bonus-gallery images (which is accessible only via main menu screen layout), which even not a "sprites" but just images placed in files folder of the project. And there is a lot such examples.

I was forced to reduce the size of the generated sprite sheets to 512x512 just to exclude a lot not needed "at the moment" sprites - and got significant (from about 390MB to 310MB) memory usage reduction. Even though the overall image packing density has worsened because of this.

The way to fix this and organize spritesheets generation (my thoughts):

We already have in Construct nice folder structure for the project files organization, and usually developers store all things in their logical, corresponding folders (for example: files for gallery - in one folder, characters - in other, mini-games graphics - in corresponding folder, factory levels, another planet levels.... e.t.c., e.t.c...).

► So, I suggest to make a checkbox setting in a project settings which will enable per-folder spritesheets generation. While enabled - it will "batch" generation of spritesheets not for whole project at once, but per folders. So the dozens (or even hundred) of sprites in one folder will not mixing in their spitesheets with hundreds of sprites from another folder.

I believe, for big projects this will help to reduce memory usage significantly. And it looks like it's not hard to realize this kind of spritesheets generation.

Thanks for your attention!

This would be amazing but i think it would be better if we could turn a Regular Folder into a Spritesheet Folder (so a setting per folder) instead of a global project setting turning all Regular Folders into Spritesheet Folders.

This way we would still be able to use folder for organisation purpose as it works right now and create just a few special "Spritesheet folder" dedicated to memory optimisation whithin the same project.

It could be an option on the right click context menu of Object Folders :

Right Click > Turn into Spritesheet Folder (that folder would have a slightly different icon so we immediatly know this folder will force spritesheet packing for all its children)

Right Click > Turn into Regular Folder (turn back the spritesheet folder into a regular folder)

Regarding nested Spritesheet Folders, it should probably pack the Spritesheet subfolder into a single spritesheet and the content under the Spritesheet parent folder that isn't itself under a Spritesheet subfolder into an other spritesheet.

Which means each Spritesheet Folder would be guaranteed to generate a different spritesheet no matter the size of its texture and their parent/child relationship.

Yes, nice idea Overboy! Thanks!

P.S.: Just not sure what you mean about "no matter the size of its texture" - I think the generator itself should work as it works now in terms of textures size - if it can't pack all sprites in folder in one spritesheet of required size - it just increment file name and generate another spritesheet for this folder.

So, instead of spritesheets name like "shared-3-sheet7.png" it can be like "[FOLDERNAME]-sheet5.png"