Texture Atlases

Texture atlases for 2D games is a great optimization for batching together tons of different sprites (especially quads) with a very few number of draw calls. Making them is a pain. For pixel art or other 2D art, DXT compression is often not a great choice due to the lossyness. One good way to make atlases for 2D games is with the PNG format. Single-file loaders and savers can be used to load and save PNGs with a single function call each.

Here’s an example with the popular stb_image, along with stb_image_write:

This requires two different headers, one for loading and one for saving. Additionally the author of these headers also has a bin packing header, which could be used to make a texture atlas compiler.

However I have created a single-file header called tinydeflate. It does PNG loading, saving, and can create a texture atlas given an array of images. Internally it contains its own bin packing algorithm for sorting textures and creating atlases. Here’s an example:

The above example (if given a few more images) could output an atlas like so:

atlas

Followed by a very easy to parse text formatted file containing uv information for each atlas:

The nice thing about tinydeflate is the function to create atlases has a little bit of anti UV bleeding code inside of it. Most places on the internet will tell you to solve texture atlas bleeding by adding padding pixels around your textures. This might be important for 3D applications or when mip-mapping is important, however, I don’t have this kind of 3D experience. For 2D pixel art games it seems squeezing UVs ever so gently inside the borders of a texture works quite well, and so tinydeflate takes this approach. No complicated padding necessary.

And finally here’s an older video I did with some more information on writing the code yourself to do some of the above tasks.

TwitterRedditFacebookShare

2 thoughts on “Texture Atlases

  1. PH

    From what I gather from your newest article “Writing A Game Engine in 2017”, you do care about iteration times and simplicity.

    And as such, I feel that Texture Atlases – as commonly applied – a separate asset preprocessing step – is a bad fit.

    What I propose (and use myself) – is an ‘online’ (‘always-on’) texture packer used in combination with a filesystem notifications. That makes adding assets seemless. All the changes to the assets on the disk are immediately reflected and packed (or ‘removed-from’) appropriate atlas automatically. This goes hand-in-hand with the philosophy of having an ‘always-on’ game with a recompilable-reloadable codebase.

    (Especially in 2D games) I feel that introducing any sort of additional build steps or “asset pipelines” is unnecessary complexity and slows down iteration times.

     

    Reply
    1. Randy Gaul Post author

      Hey good comment. I totally agree! In my personal code I actually hook up this header to do something very similar, but I indeed failed to mention this in my newer article. I’ll write another section out, thanks for the quality comment :)

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *