Sprite sheets consume unnecessary graphics memory.

Hello, engine developers and users who are interested in this topic. I think this is especially relevant for mobile developers.

Question for developers Ashley and Tom: our engine is constantly growing and filling up with various interesting and useful tools.

It would be nice to fix this mess in the sprite sheets. Currently, sprite sheets are compiled automatically and quite densely. We can even choose their size (512, 1024, 2048). But this compilation is often illogical and leads to unnecessary memory consumption at the level.

In the screenshot, I have given an example of a sprite sheet with only three images, and they will never be used on the same level but are always loaded together.

It is high time to do something about this, perhaps adding a tag to the sprite to which it belongs to a separate scene. Or maybe you have another solution.

Construct attempts to group images based on their usage on layouts in your project (similar to the way layout-by-layout image loading works as described in memory usage. Have you designed your project this way? Or do you rely on a lot of dynamic loading, in which case Construct won't be able to know which images go together?

Spritesheeting is also a broad and complex topic with a lot of subtle tradeoffs. Even if Construct separated the images to different spritesheets as you want, in some cases it might actually increase memory usage: removing one image might not actually allow the spritesheet to be resized any smaller, and adding a new spritesheet may increase the total memory usage. For example in your image, removing image 3 doesn't look like it'd allow the spritesheet to step down a size, but then you added a new spritesheet. More spritesheets also means reduced runtime performance and a higher download size.

Spritesheets fundamentally trade-off memory granularity with efficiency. It's hard to design spritesheets for an entire project that never unnecessarily load something. Many projects will use different sets of images at different times within the same layout, and may well make use of dynamic loading and unloading. The only way to guarantee nothing is ever loaded unnecessarily is to turn off spritesheeting, but then that will make the project significantly less efficient.

In short there are a lot of non-obvious things going on with spritesheeting. A worst case scenario is we add some feature to manually configure this, someone goes and spends hours tweaking their spritesheet layouts, and then it's less efficient than what Construct would have done automatically. Or it significantly increases the download size and load time, and they wonder if it was worth it to de-optimize that. Or it turns out it only reduced overall memory usage by 2% because Construct was actually doing a decent enough job, and something else would have been a much better use of their time. Having spent many years tweaking the trade-offs with the spritesheet generation in Construct, I'd definitely say it's one of those areas that sounds straightforward, but is full of endless edge cases and complexity. Leaving Construct to do a reasonable job automatically is probably good enough.

Can you not design your layouts with the right initial objects placed? Then both layout-by-layout memory loading, and spritesheet generation, should work better.