I'm still at the very early stages of my game design -- nowhere near actually needing the sprites yet -- but a thought occurred to me: What's the best way to approach sprites of different dimensions?

In context, my game will use sprites to represent different space ships (long-range plans include a 3D engine with actual ship models, but for now it's 2D with simple sprites). I've always thought of using sprite sheets as the best way to handle multiple different sprites in games. But some of my ships will be bigger than others. So while one ship might be represented by a 20x15 sprite, another might be 25x18.

How should I best approach this? One sprite sheet and somehow include in my sprite objects the dimension of each frame? Or should I group the sprites into different sprite sheets based on their size? Or should every frame on the sheet be the same size (the "biggest"), and just not use up the entire area for every sprite? Maybe abandon sprite sheets entirely in this case?


One solution would just be to pack as much as you can on a single sheet: Texture packing algorithm

Part of the data that results from that is where the sprite is in the texture and how big it is, so you can use that information to draw the portion of the image that you need for a given sheet.

Be sure to not use mipmaps, though.

  • \$\begingroup\$ Oh, excellent resource, thanks! Regarding mipmaps -- is your warning against them because they're non-rectangular nature wouldn't work well with this packing algorithm, or is there some other reason to avoid them? (I don't need them in my case anyway, at least not for the foreseeable future, I'm just curious.) \$\endgroup\$ – Kromey Mar 30 '11 at 22:38
  • \$\begingroup\$ If you pack oddly shaped sprites on a mipmap, you're not going to get as clean breaks as, say, packing a multiple of 2 number of power-of-two sprites on a texture. You'll get bleeding between sprites. \$\endgroup\$ – Tetrad Mar 30 '11 at 22:44
  • \$\begingroup\$ Its because you pack the textures close together, when you start to apply mipmapping to them they will blend in unintended ways. That would be more of a 3D concern anyways though when dealing with distance from the camera and using lower quality (smaller) textures. No worries in a basic 2D sprite engine :) \$\endgroup\$ – James Mar 30 '11 at 22:46

You could round them to the next power of two (or any other size, but powers of two are always convenient) and collect all of the same power of two in a single sprite sheet.

  • 1
    \$\begingroup\$ So you're suggesting that if I had sprites that are e.g. 22x17, 24x19, and 30x24, they'd all be rounded up to 32x32 and then stored in the same sprite sheet? And then another sprite that might be 12x10 would be rounded up to 16x16 and kept on a separate sheet? That seems a reasonable approach... \$\endgroup\$ – Kromey Mar 30 '11 at 22:34

A few other notes on texture "atlases" as they're usually called, or sprite sheets.

  • Make sure you disable any filtering.

The reasoning behind this is that any kind of filtering will blur one texture/sprite into the next.

If you really must use filtering, ensure that you leave a gutter area around each image to account for the filtering. The trick here is to extend the last pixel into the gutter area so that any filtering (or averaging) will average the same colour as the last colour in the actual texture.

If you use a black (or other solid colour) as a gutter region, you will be in some very weird averaging. and leakage back into the original image.

  • Try and use power of two sized textures

Yes, all the graphics cards now support non power of two textures. Most of the time they just inflate the texture to the nearest power of two in the driver underneath you. Be nice to your graphics card, use a power of two, your texture cache will thank you.

  • There's lots of really cool packing algorithms

But in reality, a simple "left" until it wont fit, then "down" works surprisingly well, especially with regularly(ish) sized textures.

  • Pack heavily used textures first.

It can be very useful though to pack often used textures near to each other to minimize cache thrashing and texture cache use!


If you insist on a sprite sheet, there are algorithms that will generate the smallest possible area with all the sprites in it (or write one yourself for fun). However with basic compression, you're better off making a big, but organized sprite sheet:

  1. Easier to manage and look at
  2. You can always pack it if you ever get to ship
  3. Even if you don't, basic compression will make the difference negligible

However using separate files for each sprite is a more modular way of going about this. The difference is organizational and personal preference - I learned to use sheets from the first tutorial I saw. Then I figured it would be easier to use separate PNGs for everything, and that's stuck with me.

Edit: Here is an another answer that links to two tools for texture packing.

  • \$\begingroup\$ It looks like you meant to include a link there, but it seems to have gotten lost; can you try again to post the URL please? Also, good point on the compression bit -- I do intend to use compression, whichever way I go, so an easier-to-view, but slightly larger, sprite sheet could work better for me, at least in the early stages. \$\endgroup\$ – Kromey Mar 31 '11 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.