Atlas control

Hello!

I am working on a mobile game for kids. Is the typical 'doll house' type of game, similar to toca boca, aha world, avatar world etc. This kind of games are scene and prop heavy.

This is an example of part of a scene:

One of the issues I have is the lack of control over the atlases. As I have several location, ideally I would like to bundle the props by location so I am not loading unnecesary big atlases. I believe this functionality does not exist in Construct, as they are auto generated.

Is there any plugin or work around for that? Thank you!

First of all it's worth asking: is this really a problem? Modern devices all have loads of memory, and it doesn't look like your project is that image heavy. So long as the peak memory usage is reasonable, then optimizing it is actually a waste of time - you may as well spend your time on something more significant.

So is your peak memory usage actually a problem? If so the first place to look is our guide on memory usage which includes general advice on optimizing it.

If you really want to adjust Construct's spritesheets, there are two things you can do: the main one is to adjust the project advanced setting Max spritesheet size. Lower maximum spritesheet sizes will allow finer memory loading granularity which can result in lower peak memory usage, but at the expense of efficiency (reduced runtime performance and increased download size).

The second thing is to make sure you've organized all your objects on to layouts appropriately. Construct has an algorithm that tries to group objects used together on the same layout on to the same spritesheet, in order to avoid situations like having one spritesheet with content from several different layouts that are never used together. If your project doesn't abide by that (e.g. by placing everything on the same layout) then Construct doesn't have any clues about how to group objects together and so that algorithm will prove ineffective.

I'm skeptical that any feature to manually adjust spritesheets would really be useful in practice - with its current design, Construct frequently discards and regenerates spritesheets as you edit your project. So any manual changes would likely be quickly reverted. Even if there were other ways to permanently specify how spritesheets were arranged, as you continued to edit the rest of the project and Construct continued to automatically regenerate other content, I'd imagine it would be easy to accidentally end up with a set of spritesheets that are actually less efficient than if you just left Construct to do it automatically - and that might be after having to spend a long time to manually tweak everything. It doesn't seem like a good thing to spend time on when designing your project, especially if the peak memory usage is not really a problem to begin with.

Please allow me to go off topic for a moment. I have another question that has puzzled me for a long time.

Does the engine still support the "texture batching" technology? If I reuse the same sprite 30 times in this layout, is its image memory usage calculated as 1 or 30?

If this sprite has 10 animations, but they are all playing the same animation, is its memory usage 10 * 30?

If these sprites are not yet on screen, will they use memory even if they are not rendered?

What can I do if I sometimes feel that the arrangement of the sprite sheet is not "smart" enough?

Automated arrangement is probably never going to be absolutely perfect, but my view is it's basically good enough. For it to not be good enough, you need to base the evidence on measurements. For example, what is the peak image memory usage of your game? These days if it's under 1 GB, it's hard to think of any device that could not run it outside of things like bottom-spec Raspberry Pis. Even low-end phones ship with 4 GB RAM these days. So why improve it if it's not a problem?

It's like trying to improve the performance of your game when it already runs at 60 FPS on low-end devices. It's a case of job done - theoretically it could be faster, but nobody will actually have a better experience of the game. So why not spend your time on things that actually do improve the experience of the game?

Does the engine still support the "texture batching" technology?

Construct has sophisticated batching technology. If you make 30 instances of the same sprite, and they are all drawn together, Construct will issue a single draw call with a single texture specified. In many cases, Construct can issue a single draw call to draw multiple objects, providing they are from the same spritesheet. With the WebGPU renderer, if multi-texturing is enabled, it can issue a single draw call to draw multiple objects from any of up to 14 different spritesheets. On top of that, you can enable image deduplication on export to make sure even different objects with the same image only export the image once. It's a very well optimized part of Construct - modern devices can handle hundreds of thousands of on-screen sprites and still hit 60 FPS.