Fortunately, there are quite a few options when it comes to packing textures. The most common ones are:

However, for availability reasons, we are going to use the first of the two as it is more than enough for our purposes. They are both very similar anyway. The next screenshot shows the texturepacker-gui interface:

The following steps will help you pack your textures into an atlas:

You should have obtained something like the following screenshot:

We are going to examine the TextureAtlasSample code to discover how to render atlases so as to achieve a much better performance.

Our TextureAtlasSample needs several members to make the atlas magic happen. You are already acquainted with the camera, viewport, and batch trio. We now introduce the TextureAtlas class, which is used to hold the master texture data along with all its metadata to identify its portions. Each one of the members of type TextureRegion will help us cache our original images to treat them individually:

private OrthographicCamera camera;
private Viewport viewport;
private SpriteBatch batch;
private TextureAtlas atlas;
private TextureRegion backgroundRegion;
private TextureRegion cavemanRegion;
private TextureRegion dinosaurRegion;

The create() method is the place to load our texture atlas and fetch the references to the regions we are interested in. The TextureAtlas class constructor is identical to the Texture one, except that we now pass the .atlas file the packer software we created rather than the path to the image file. To initialize our regions, we call the findRegion() method of the TextureAtlas class passing in the name of the original image without its extension:

public void create() {          
   ...
   
   // Load atlas and find regions
   atlas = new TextureAtlas(Gdx.files.internal("data/prehistoric.atlas"));
   backgroundRegion = atlas.findRegion("background");
   cavemanRegion = atlas.findRegion("caveman");
   dinosaurRegion = atlas.findRegion("trex");
}

Atlases allocate memory to hold their associated texture data very much like Texture objects do. Therefore, it is polite to clean them up whenever we stop using them. Since we will render our images for as long as the example runs, we can only do this right before exiting, in the dispose() method:

public void dispose() {
   batch.dispose();
   atlas.dispose();
}

Finally, let's take a look at the pretty bit, the render() method. As in any classic Libgdx application, we clear the screen with a background color and set the camera combined matrix to SpriteBatch to appropriately transform our draw calls. To render the background centered on the screen, we first get its dimensions with the getRegionWidth() and getRegionHeight() methods. The camera is centered at (0, 0), so we need to render the background at negative half its width and negative half its height for it to also be centered.

The SpriteBatch class has quite a collection of overloaded draw() methods suitable for regions. In our case, we will go through the most complete one to illustrate all the possibilities. First of all, we pass in the region followed by its position in world units. Then, we indicate the local origin of the region starting from its bottom-left corner. Now, we need to specify the dimensions of the region and the scale along both its axes (remember that you need to convert from world units to screen units here). Finally, we pass in the rotation in degrees:

public void render() {     
   ...
   
   batch.begin();
   
   float width = backgroundRegion.getRegionWidth();
   float height = backgroundRegion.getRegionHeight();
   float originX = width * 0.5f;
   float originY = height * 0.5f;

   batch.draw(backgroundRegion,
            -originX, -originY,
            originX, originY,
            width, height,
            WORLD_TO_SCREEN, WORLD_TO_SCREEN,
            0.0f);

   // Render caveman and dinosaur at different positions
...

   batch.end();
}

The result, shown in the following screenshot, is a tricky situation for our caveman, since there is a dangerous-looking dinosaur staring right at him. As an exercise, you could render a crowded scene with both approaches, simple textures and atlases, measure the time it takes in each case, and see for yourself how much faster atlases are.

Take a look at this excerpt of the prehistoric.atlas file under the [cookbook]/sample/samples-android/assets folder:

prehistoric.png
format: RGBA8888
filter: Nearest,Nearest
repeat: none
caveman
  rotate: false
  xy: 1283, 320
  size: 83, 156
  orig: 83, 156
  offset: 0, 0
  index: -1

Nothing surprising, really; everything comes from what we established in the packer settings. The first line points to the master texture, which should be distributed along the atlas file. Then, the pixel format is specified; in this case, we tell Libgdx that the texture uses 8 bits per channel (red, green, blue, and alpha). Right after comes the filter to use when the image is downscaled and up-scaled respectively, and whether or not the texture should be repeated.

What follows is a list of the regions that compose the master texture. Every region starts with a name that is equal to that of the original texture minus the extension. Then, we can find parameters such as dimensions, position in the master texture, origin in the region local space, and offset between regions. Regions can be rotated to optimize space usage, which is also specified in the parameters.

The SpriteBatch class serves as an intermediary between your game code and the OpenGL API, which then communicates directly with the GPU. When you render a texture through a batch, the latter creates a quad and associates a set of texture coordinates to each one of the vertices that form the quad. As you keep rendering the same texture over and over again at different positions, the mesh of quads will grow. The moment you call the SpriteBatch end() method, the quads and their texture data are sent to OpenGL and, at last, rendered on the screen.

However, and here is the secret, every time you tell the batch to draw a different texture, it has to flush the previously built mesh to OpenGL and start from scratch. This is known as texture swapping and is a time-consuming operation. Now it becomes clearer how using a bigger texture and only drawing portions of it as we see fit can make such a great difference.

Imagine you have a background and 10 characters on screen. If each one of the entities has its own texture, the batch will need to swap textures nine times per frame and perform an additional flush operation after the call to end(). Nevertheless, if all those textures are packed, there will be exactly 0 texture swaps and only one draw call to OpenGL.

The biggest drawback of texture packing and atlases is that we cannot just sew all our game textures together regardless of the total size. The maximum supported texture size varies across devices and it can be queried using Gdx.gl20.GL_MAX_TEXTURE_SIZE:

int maxSize = Gdx.gl20.GL_MAX_TEXTURE_SIZE;
Gdx.app.log("TextureAtlasSample", "Max texture size: " + maxSize + "x" + maxSize);