Reducing Draw Calls with Texture Atlases

Every distinct texture or material state can cause an extra draw call. Batching reduces draw calls by grouping sprites that share the same texture and material. Texture atlases put many sprites into one texture so the GPU can draw them in one or a few batches instead of one call per sprite. This matters most on mobile and low-end devices where draw call count directly impacts frame rate. This guide explains how batching works, how to stay within atlas size limits, and why UV padding and power-of-two sizes matter.

How Batching Works

When the engine draws a sprite, it binds a texture and issues a draw. If the next sprite uses a different texture, the engine may flush the batch and bind the new texture. If many sprites share one atlas texture, the engine can submit multiple quads (or a dynamic vertex buffer) with different UVs in one draw call. So the goal is to put as many visible sprites as possible into as few textures as possible without exceeding max texture size or wasting too much space.

Batching is most effective when sprites share not only the texture but also the same material (shader, blend mode, etc.). Changing blend mode or shader state often forces a flush. So in addition to atlasing, keep material variants to a minimum: e.g. one opaque sprite material and one additive material, each using atlases, rather than many per-sprite materials. Sort by texture and material to maximize batch size before drawing.

Practical takeaway

One atlas per character or per scene keeps draw calls low when that character or scene is on screen. Avoid one texture per sprite; that can easily push you into hundreds of draw calls per frame. Use the engine's profiler or stats to see batch count and target a number that your platform can sustain (e.g. under 100–200 for mobile).

Atlas Size Limits

GPUs and platforms have a maximum texture size (often 2048, 4096, or 8192). Your atlas must fit within that. If you have more content than fits in one atlas, you'll need multiple atlases and thus more draw calls when sprites from different atlases are interleaved. Organize atlases by scene or by draw order so that in a typical frame you're drawing from as few atlases as possible.

If your game has multiple levels or areas, consider one or a few atlases per level so that only the visible level's atlases are bound. Avoid spreading one character's frames across many atlases; keep each character or effect in as few atlases as possible so that when they're on screen, you don't pay for extra texture binds. Profile with the engine's draw call or batch counter to see how many calls you get per frame and where the breaks occur.

UV and Padding

Each sprite in the atlas has a UV rectangle. With linear filtering, sampling at the exact edge can sample the next sprite. So we add padding and optionally extrude edges. That keeps the atlas a bit larger but avoids bleed. Power-of-two atlas dimensions (256, 512, 1024, etc.) can help on older GPUs and with mipmapping.

Padding adds a few pixels between sprites so that when the GPU samples at UVs that fall on or near the edge (due to filtering or sub-pixel positioning), it doesn't sample into the next sprite. One to two pixels is usually enough. Extrusion copies the edge pixels into the padding zone so that filtered sampling still gets valid color instead of black or the next sprite. Power-of-two sizes are required on some older platforms and are a safe default; they also work well with mipmapping if you generate mips for the atlas.

Summary

Fewer textures and shared materials mean fewer draw calls. Use atlases to pack many sprites into one texture, respect max texture size, organize by scene or draw order, and add padding (and optionally extrusion) to avoid bleed. Profile to confirm batch count and target mobile/low-end for the biggest impact.