2D graphics - why use spritesheets?

Question

I have seen many examples of how to render sprites from a spritesheet but I havent grasped why it is the most common way of dealing with sprites in 2d games.

I have started out with 2d sprite rendering in the few demo applications I've made by dealing with each animation frame for any given sprite type as its own texture - and this collection of textures is stored in a dictionary. This seems to work for me, and suits my workflow pretty well, as I tend to make my animations as gif/mng files and then extract the frames to individual pngs.

Is there a noticeable performance advantage to rendering from a single sheet rather than from individual textures? With modern hardware that is capable of drawing millions of polygons to the screen a hundred times a second, does it even matter for my 2d games which just deal with a few dozen 50x100px rectangles?

The implementation details of loading a texture into graphics memory and displaying it in XNA seems pretty abstracted. All I know is that textures are bound to the graphics device when they are loaded, then during the game loop, the textures get rendered in batches. So it's not clear to me whether my choice affects performance.

I suspect that there are some very good reasons most 2d game developers seem to be using them, I just don't understand why.

Answer 1

A strong argument for using spritesheets is that the number of available textures on a graphic card can be limited. Therefore your graphics library would constantly have to remove texture and re-allocate textures on the GPU. It's much more efficient to just allocate a large texture once.

Also consider that texture sizes are usually power of 2. So if you have a 50x100px Sprite, you'll allocate textures with the size 64x128px or in the worse case 128x128px. That's just wasting graphics memory. Better pack all the sprites into a 1024x1024px texture, which would allow 20x10 sprites and you'll only lose 24 pixels horizontally and vertically. Sometimes even sprites of different sizes are combined into one huge sprite-sheet to use the texture as efficient as possible.

Addendum: A very important reason to use sprite-sheets is to reduce the amount of draw-calls on your GPU, which can have a notable impact on performance. This has been stated in other answers and I'm adding this for the sake of completeness so that this gets some more visibility.

Answer 2

I'd say the arguement to use would be the ability to render multiple things in a single draw call. Take for example font rendering, without a spritesheet you'd need to render each character with a separate texture swap followed by a draw call. Throw them into a spritesheet and you can render entire sentences with a single draw call (the difference characters in the font being picked out by just specifying the different UV's for the corners). This is a much more efficient way of rendering when a very real overhead of rendering stuff on a lot of platforms is in making too many API calls.

It can also help save space, but it depends on what your packing into the spritesheet in the first place.

Answer 3

Each draw call has a certain amount of overhead. By using sprite sheets you can batch the drawing of things that aren't using the same frame of an animation (or more generally, everything that's on the same material) greatly enhancing performance. This may not matter too much for modern PCs depending on your game, but it definitely matters on, say, the iPhone.

Answer 4

In addition to performance considerations, sprite sheets can be handy when creating the art; each character can be in its own sheet, and you can see all the frames just by scrolling around. It helps me keep a consistent look across all the frames.

Additionally, I code in AS3, and each image file requires a separate embed instruction. I'd rather have a single embed of an entire spritesheet than 24 embeds for all the frames, even if I'm using a separate resource class.

Answer 5

Another reason so use spritesheets with XNA is that with Xbox360 development there's a known issue with slow deploy/load times in relation to the number of files you have in your project. So combining lots of small image files into a single image file will help combat that issue.

Answer 6

I'm not going to mention memory/GPU here, since there's enough answers like that.

Instead, it can clear up your art as you work on it - and after. Instead of having to flick through 10 images to see the walk cycle, you can see all the frames in one go. If you wanted to distribute this, you've only got 1 file to deal with instead of 10.

And then it's also cleaner (from a organizing point of view) to have character.png and enemy.png over characterwalk01 through to characterwalk10, then characterattack01 to characterattack05, and it goes on.

Answer 7

The graphics memory does not have a bloat up memory management like file systems on disks; the oposite is the case: it is kept simple and fast.

One such simple and fast memory mangement might be like having only one single giant 4096x4096 sprite that is cut in multiple smaller sprites by halfing its width and/or height. (There exists a similar 1-dimensional memory-managing technique, but I forgot the name.) Eventually, Defragmentation has to be performed.

To skip such memory management at run-time, developers fill single large sprites with multiple smaller sprites automatically at compile-time or even while in the desing-process of the graphics.

Answer 8

Also don't forget the I/O operations it might save you during initialization. If you are loading from a CD drive, each file is an extra I/O call, and might take some time to seek (modern HDD's are about 15 ms per file, CD's maybe 50-100ms?). This can save you a lot of initialization time as only one file has to be fetched. It also allows your OS to cache these I/O operations, in case your application is doing something else (like waiting for GPU).

Answer 9

Other than being more performance efficient, I find it simply easier. It requires a little extra work to make sure your images are always within their bounds when creating the art, but it's a lot easier being able to see all the images you're dealing with at the moment.

It's also easier to code, in my opinion. I simply have an array of objects like:

sheet = {
    img: (the actual image),
    rects: [
        {x:0, y:0, w:32, h:32},
        {x:32, y:0, w:32, h:32},
        {x:64, y:0, w:32, h:32}
    ]
};

sheets.push(sheet);

Then for each item I give it two values, sheet and rect. The sheet would be the index in the array of objects, and the rect would be the index in that sheet's rects array.