SDL2 Shooter 2 tutorial
SDL2 Widget tutorial
SDL2 Adventure tutorial
Orb source code
— Sprite Atlas Tutorial —
In the previous tutorial, we looked into preparing the files we want to use in our atlas by recursively listing files in a directory. In this step, we'll actually use the information gathered to produce our atlas. This is where the real meat of the tool comes into play. To see it in action, run make, and then ./gen02 to create the atlas. It will produce a file called atlas.png. If you open this, you will see an image like the one above.
The tool works by taking an empty image (or rather, rectangle) and subdividing it as it places images, essentially creating two children of the root. The parent itself is marked as being in use. When the next image processed, it will look for an empty node into which it can fit, walking down the chain of nodes, before subdividing. The process continues in this way until all the images have been processed. Don't worry if you don't get the concept. All will become clear as we step through the code.
Inspecting the code
First up, we've added a new struct to structs.h:
This struct will be used to hold the data about a node and its children (showing how it was subdivided). We'll see a lot more of this guy in a bit. As before, we'll move onto main. main is now a somewhat long function, so we'll look at it in stages.
One of the first things we want to do is create a root node, and make it the same size as the atlas itself. The x and y coordinates are set to 0,0, while the w and h (width and height) are set to the atlas's size. We also tell the root node that it is not currently being used. This root node is the one we will start with when placing images.
Next, we want to create an SDL surface:
As with the root node, we create a surface of the same size as the atlas itself. This is the surface upon which all our images will be placed when we make the atlas.
Now for the main for-loop. There's quite a bit to it.
In summary, the loop is going through each of the images that we have been loaded and locating a node on the atlas in which to place it, via the findNode function. If the first attempt to locate a node fails, the node search will be called again, but this time with the w and h swapped. In effect, this is rotating the image to see if it can fit that way instead. Upon successfully finding a node, the image will be blitted into the node space (being rotated if need be). The progress will be logged, and failures output. Finally, the loaded image and the allocated filename are freed. Overall, it's quite straightforward. However, the findNode function is extremely important to the success of the atlas creation, so we should look into how it works.
We check the input node (root) and check to see if it's being used (meaning that an image is already occupying the space). If so, we descend into the children, checking the first and second to see if they are in use. If the first child is unused, it will be returned, otherwise the result of the second will be returned (which may be null). Pay close attention here: the check with the children calls findNode again, as this is a recursive function!
Now comes the fun bit. If we find a node that is unused, and the node is big enough to accommodate the image we wish to insert (by testing the input w and h against the node's width and height to see if both are smaller or equal), we will use it. Using the node involves splitting it. We're doing this in the splitNode function, as below:
The first thing the function does is mark the candidate root as being in use. It then creates two child nodes, with the input node as their parent. The first node is told to occupy the space to the right of the space the incoming image will occupy, based on the width and height (w + h) inputs. The second child will be told to occupy the space below these two. As this can be hard to visualize just by looking at the code, consider the image below:
When the next image is inserted, and assuming we have determined that node #1 will be the node we will use, the splitting will be carried on that node, resulting in the following:
Node #1 now has two child nodes, #3 and #4. Notice how thin node #4 is. Only very small images could fit in there. But the atlas gen program would figure that out for us, making optimal use of all the space available. Something to keep in mind: the first child is ALWAYS to the right of the image and the first node to be checked. This is why we sort the images by their height, so we can build our atlas from left-to-right, then top to bottom.
This process will happen for each image, effectively breaking the root node down into many different cells, into which images can be placed. One thing to keep note of it the padding variable. This adds extra space between the images, on the right-side and the bottom. The reason for this is to avoid texture bleed. When images are placed adjacent to each other, texture bleed can result when applying. This means that part of one image (usually no more than a pixel's worth) will also be used. This mostly happens when using decimals (due to rounding issues), rather than integers as we're doing here, but it's still worth padding the padding to avoid the issue.
With our node selected, it comes time to blit the image to the main atlas. If the image was rotated, we want to swap the w and h variables and call the special blitRotated function:
This function simply copies the pixels from the source to the destination, copying them in an ordered way to have them output rotated clockwise. As you can see, it's quite a simple function, so we won't say any more on it. Rotating is actually quite rare, so for most other images we will use the standard SDL_BlitSurface function.
Finally, with all of that done, we can save the atlas. SDL provides a handy function for doing this, taking just the surface and the filename as parameters:
We're saving the atlas as a PNG to preserve the transparency and ensure it is stored in a loseless format. The last function we'll touch on is that which handles the command liness arguments:
We can specify the size of the atlas by using the -size argument, followed by a number (ideally, this should be a power of two). Specify the directory to scan by using -dir, followed the by the path, and adjust the padding by using the -padding argument. For example, the following will create an atlas of 1024x1024, using images found in a directory called sprites (relative to the binary), and with a padding of 5 pixels between images:
./gen -size 1024 -dir sprites -padding 5
Be aware that there is no error checking performed on these inputs, so be sensible with the arguments supplied.
We now only have one step remaining in the creation of our sprite atlas, and that's to store the coordinate data of each of the images that we've added to our atlas. This is obviously vital if we're going to be able to make use of the atlas, otherwise we will have no way to retreiving our sprites. We'll look at this in the next tutorial.
The source code for all parts of this tutorial (including assets) is available here:
It is also available as part of the SDL2 tutorial bundle (with on-going updates):