My little game consists of the following scenes (collections):
start screen
loading screen
game screen
end screen
Should I use one atlas for the whole project or would it be better (performance!) to use one atlas per collection (and maybe an additional one for sprites that are used on multiple scenes)?
Option 1
sprite.atlas
Option 2
sprite.atlas (for sprites used on multiple scenes)
start.atlas
loading.atlas
game.atlas
end.atlas
Maybe there are even other options that I don’t know of.
What is your game? Is it a web game that has to be really small? Or is it mobile maybe?
Are your images huge (HD) making very big atlases?
Are all sprites used in all collections mixed or some are some collection specific, e.g. GUI only for menus that are not in game and vice versa?
General advice is to optimize when it’s really needed.
If optimisation is needed - most important advice imho is: Make one texture (aka atlas) for everything that will be drawn in one draw call.
On Memory
If game loads slowly - verify what is a bottleneck first. In fact it many times can be a huge texture, so it’s better ofc to work with smaller ones, but sometimes you don’t want a compromise on the quality. But sometimes your game is very small graphics-wise and you can put everything in one atlas and it will be still small
Good rule is to keep each atlas at max 2048×2048 because some devices (especially mobile) can’t handle bigger resolution textures. You can split atlases further if you exceed that or use multi paged atlases.
All textures stay resident in GPU memory once loaded - even if a lot of that atlas isn’t used in a given scene. This can spike your GPU VRAM usage and increase initial load times. So if this will be really a bottleneck you can only load what you need when you need it, then unload the previous atlas when you switch contexts.
If possible and needed use texture packing, e.g. Texture Packer that Defold has extension for. Read also about texture profiles (Texture profiles in Defold)
On Performance
I usually have separate 2-3 separate atlases, most commonly separated sprites for in game characters and GUI elements, sometimes more for separate layers/materials, because those are drawn anyway in separate batch calls.
This is the very useful text on breaking batching and what’s this:
If your scene is fairly simple (few overlapping materials) and you care most about minimal draw calls, one big atlas wins.
If you constantly switch between sprites from different atlases, you’ll see extra draw calls, but if you can group your render logic (draw all of scene A sprites before B), you can still batch within each atlas.
Also one good tip I am using for my atlases - always put a little bit more effort into making “Animation” in each atlas, even if you have a single image that you want to use (e.g. GUI elements), e.g. add Animation “gui_panel_white” or something and only then add the single image representing that panel to it and set animation to “None” if it’s a static one. Useful especially early in development, because if you keep changing names of your images (which until I figured out convenient to me and proper naming conventions happened a lot) was a pain in the atlas to change the images AND change all the animations calls or “Default Animation” properties for sprites and GUI nodes.
If you use single image “animation” everytime, you don’t have to change your code in scripts, it will always be “gui_panel_white”, but you only switch the image in atlas in that animation.