LÖVE

For my current project I just implemented a simple system to create texture atlases on the fly so as to hopefully generate some performance improvements via SpriteBatches + Quads. I could "pre-cook" the atlases manually but I wanted the ease and flexibility of being able to switch textures in and out quickly while developing.

So basically I just enumerate the image files in my texture directory, create a new ImageData that is as wide as all the texture:getWidth() added together, and has a height set to the largest height amongst all the textures, then I paste all the individual ImageData's from the textures into the large blank ImageData.

This creates a single long but not very high texture, probably something around 1400x128 or so. I then use this as the basis of a SpriteBatch from which I use quads to pick out individual textures.

So far so good, and it does offer some performance improvement. My question is where exactly PO2 problems would start to come into play. Does the underlying texture atlas ImageData have to be PO2 (which would mandate me taking the above 1400x128 ImageData to 2048x128)? Do the quads themselves have to be PO2 as well?

What if an individual texture is not PO2, say 52x52, but I then paste it into a texture atlas that is PO2, say 512x128. Will the individual texture ImageData not even load, preventing me from even pasting it? I would've liked to test it myself but I don't have any hardware old enough to test it on.

For systems which can't display non-PO2 images, it will be all good as long as the final image (the texture atlas) is PO2. Quads and the source images don't need to be PO2.

There are a few resources on the 'nets about packing textures efficiently into a texture atlas.