A texture atlas, or sprite sheet, is a single image containing a number of smaller textures or sprites. This is useful as it is more efficient for the graphics card to process (it doesn’t have to keep switching textures when drawing different textures, as it can just use the single texture and sample from different parts of it). It is also faster to load into RAM, as you are only loading in one image, as opposed to several smaller ones, so the loading can be done in one stage.
It is useful to be able to quickly and easily generate texture atlases from a number of source sprites to speed up development. A useful tool when developing using the XNA framework is the SpriteSheet Sample available on the XNA Creators Club website. One downside of this, however, is that you must still manually generate the XML file list by hand, which can be a pain if you have a lot of textures to place on the sprite sheet. Another is that it is XNA only
Because we also do development on the iPhone, it was useful to have a similar generator for that platform, as well as for the XNA framework, so we created a tool to easily generate the texture atlases for us. The packing code is based on the SpriteSheet Sample code, though the tool is written in plain .NET, so does not require the XNA framework to be installed (though it does require the .NET framework). The tool can produce a PNG file with the combined textures, as well as an accompanying binary file, called a TXA file, with the information on each of the packed textures. It also supports removing transparent borders from textures to produce a more compact output. It can also optionally produce a C style header with enums in, so you don’t have to look up the textures by their names.
The help files for the texture atlas generator tool contain information on the format of the TXA files, so you can write your own loaders if you wish.
As well as the PNG + TXA combination, the tool can produce an XNA XML file (and optionally a C# file with enums in) which can be imported into your Content project to build the sprite sheet during compile time. You do need to include the XNA projects in yours to access the Content Processor and runtime types. The runtime library also includes extensions to the SpriteBatch class, to make it easier to draw using the textures.
Finally, there is a runtime library to load the texture atlas on an iPhone. The iPhone code uses the PVRTexture class from Apple’s sample code, so you can convert the PNG to a PVR if you wish using Apple’s texturetool (though this can be problematic as the textures may ‘bleed’ into each other). The iPhone runtime library also requires zlib and libpng
Each zip contains a Readme.txt file containing license information and other tips. You’re pretty much free to do what you want with these things, use them however you see fit (commercial or non-commercial), but remember they are provided as-is, and we accept no responsibility for anything
We’ve tried to tidy them up to make them usable by other people, but if you’ve got any problems or questions, post in the comments and we’ll try and help. There may be bugs in these, so let us know if you find any!
- Texture Atlas Generator
- XNA Runtime and Pipeline Libraries
- iPhone Runtime – Requires zlib and libpng















Ah, great program, I’ve been looking for a good sprite atlas builder!
I noticed one small problem, it seems to duplicate the edge pixels, so if you have e.g. a 32×32 image where the edge pixels are black, and the 30×30 center pixels are white, you get an extra black border of pixels around the whole sprite in the generated sprite atlas.
If possible, it would be great if you can remove these extra edge pixels or just make them transparent instead (that way they work as a 1 pixel separator between the sprites as well), thanks
Comment by TMK — May 25, 2010 @ 2:13 am
Yeah, it adds a 1 pixel border around each sprite so that if there is any filtering when you’re drawing (say, if the texture is resized), then the edges will be filtered with the border pixels. If the border pixels were transparent, then any pixels at the edge of the sprite would be blended with the transparent pixels. Duplicating the ones around the edge eliminates this “bleeding” of colours outside of the image if there is any texture filtering. Hope that makes sense
Comment by Rew — May 25, 2010 @ 5:54 pm
Ah, cool, that makes sense
Awesome tool by the way, great job
Comment by TMK — May 25, 2010 @ 11:11 pm