Creating a City Building Game with SFML Part 3: Textures and Animations

Before we can draw any graphics, we need to discuss the difference between sprites, textures, and images. In SFML, an image (sf::Image) is exactly how it sounds; a collection of pixels in a 2D array. They can be easily manipulated on a per-pixel level, but they can’t be drawn to the screen. A texture (sf::Texture) is an image that can be drawn, and lives in the graphics card instead of in RAM. Textures are not efficiently mutable however, and cannot have their pixels accessed individually. As such they are best created once and drawn repeatedly. They do not have any kind of position however, and so cannot be drawn without the help of another class, the sprite (sf::Sprite).

Sprites are both drawable and transformable, so they can be drawn to the screen. Thus, to create our background, we’ll need both a texture, and a sprite. We could create both of these in GameStateStart and maintain them there, however if we want to reuse the background in another game state we would have to load the texture and create the sprite all over again! Instead we will use a texture manager to store our textures, which will be part of the Game class. Create a texture_manager.hpp file:

  4. #include <SFML/Graphics.hpp>
  5. #include <string>
  6. #include <map>
  8. class TextureManager
  9. {
  10.     private:
  12.     /* Array of textures used */
  13.     std::map<std::string, sf::Texture> textures;
  15.     public:
  17.     /* Add a texture from a file */
  18.     void loadTexture(const std::string& name, const std::string &filename);
  20.     /* Translate an id into a reference */
  21.     sf::Texture& getRef(const std::string& texture);
  23.     /* Constructor */
  24.     TextureManager()
  25.     {
  26.     }
  27. };
  29. #endif /* TEXTURE_MANAGER_HPP */

Our texture manager will work by storing an std::map that maps strings to textures; when we want a texture we will call the getRef function with the name of the texture we want and the manager will return a reference to it. This way our textures will not be destroyed unless our manager is, we don’t have to use a bunch of pointers storing each individual texture, and our pointers will have easy to remember names instead of indices in an array. This method is not the best way to handle textures, but it is a simple way of doing it. In larger games (where the VRAM space is actually an issue) you would require ways of unloading textures so that only the required textures were loaded at any one time. For our purposes though, this will do fine. In a texture_manager.cpp file, place

  1. #include <SFML/Graphics.hpp>
  2. #include <map>
  3. #include <string>
  5. #include "texture_manager.hpp"
  7. void TextureManager::loadTexture(const std::string& name, const std::string& filename)
  8. {
  9.     /* Load the texture */
  10.     sf::Texture tex;
  11.     tex.loadFromFile(filename);
  13.     /* Add it to the list of textures */
  14.     this->textures[name] = tex;
  16.     return;
  17. }
  19. sf::Texture& TextureManager::getRef(const std::string& texture)
  20. {
  21.     return this->;
  22. }

In loadTexture we take the name to give the texture and the path of the file it’s stored in. We then load the texture from that file and add it to the map with the name given. In getRef we return a reference to the texture whose name is passed to the function. If you are not familiar, std::map can be accessed like an array (as we did to add the texture) or by using the at member function. The atfunction provides bounds checking, and will throw an exception (error, in other words) if the specified element does not exist. As such, it’s only useful for reading or writing to existing elements, and not for creating new ones. That’s all for our texture manager! And unlike our state manager, we won’t be going back to it. Speaking of the state manager, it’s time to change game.hpp and add our new manager!

  1. #include "texture_manager.hpp"
  3. class GameState;
  5. class Game
  6. {
  7.     private:
  9.     void loadTextures();
  11.     public:
  13.     std::stack<GameState*> states;
  15.     sf::RenderWindow window;
  16.     TextureManager texmgr;
  17.     sf::Sprite background;
  19.     void pushState(GameState* state);

As you can see we’ve added our texture manager, texmgr, and we’ve declared a new private function called loadTexturesloadTextures will fill texmgr with the textures we need. We’ve also finally created background! Inside game.cpp we will define the loadTextures function

  1. #include "game.hpp"
  2. #include "game_state.hpp"
  3. #include "texture_manager.hpp"
  5. void Game::loadTextures()
  6. {
  7.     texmgr.loadTexture("background", "media/background.png");
  8. }

Using the loadTexture function that we created, we add a new texture called "background"from the media/background.png file. Lastly we need to change the Game constructor to call the loadTextures function and set the texture of our background

  1. Game::Game()
  2. {
  3.     this->loadTextures();
  5.     this->window.create(sf::VideoMode(800, 600), "City Builder");
  6.     this->window.setFramerateLimit(60);
  8.     this->background.setTexture(this->texmgr.getRef("background"));
  9. }

Using the getRef function we set to the texture of the background to the "background" texture we created in loadTextures. Finally, we can compile the code! If everything has gone well you should have a window with a lovely background, that can be resized and, even better, properly closed!

We now have most of the game engine structure out of the way, there’s just one or two things left. The first of which being the AnimationHandler class. We’ll use this class to provide animation support to any sprites we create, by including an AnimationHandler as a member variable in the class that contains the sprite. We could create a new AnimatedSprite class using inheritance instead, but I prefer this method.

Before we begin, let’s discuss how the handler will work. We’re going to keep this simple, so each sprite will have its own texture file that will contain all the animation stages for its different animations. It would be more efficient (for the computer, not us!) to store multiple sprites in the same file, but that makes the code and asset creation more complex so we won’t do that. Anyway, we’ll split the texture file into a grid, where each frame of the same animation extends to the right, and each animation extends downwards.


The handler will have an update function that takes a timestep dt and moves the animation to the next frame if necessary. First let’s create an individual Animation class, which the handler will store an array of. In animation_handler.hpp

  4. #include <SFML/Graphics.hpp>
  5. #include <vector>
  7. class Animation
  8. {
  9.     public:
  11.     unsigned int startFrame;
  12.     unsigned int endFrame;
  14.     float duration;
  16.     Animation(unsigned int startFrame, unsigned int endFrame, float duration)
  17.     {
  18.         this->startFrame = startFrame;
  19.         this->endFrame = endFrame;
  20.         this->duration = duration;
  21.     }
  23.     unsigned int getLength() { return endFrame - startFrame + 1; }
  24. };
  26. #endif /* ANIMATION_HANDLER_HPP */

It’s such a simple class we could have used a struct if not for the getLength function. startFrame and endFrame are the zero-based indices of the start and stop frame in the grid, and duration is the amount of time one frame should last for. I find that this is nicer to work with than a frequency or frames-per-second value. And now we create the handler itself (underneath Animation and before that header guard).

  1. class AnimationHandler
  2. {
  3.     private:
  5.     /* Array of animations */
  6.     std::vector<Animation> animations;
  8.     /* Current time since the animation loop started */
  9.     float t;
  11.     int currentAnim;
  13.     public:
  15.     /* Add a new animation */
  16.     void addAnim(Animation& anim);
  18.     /* Update the current frame of animation. dt is the time since
  19.      * the update was last called (i.e. the time for one frame to be
  20.      * executed) */
  21.     void update(const float dt);
  23.     /* Change the animation, resetting t in the process */
  24.     void changeAnim(unsigned int animNum);
  26.     /* Current section of the texture that should be displayed */
  27.     sf::IntRect bounds;
  29.     /* Pixel dimensions of each individual frame */
  30.     sf::IntRect frameSize;
  32.     /* Constructor */
  33.     AnimationHandler()
  34.     {
  35.         this->t = 0.0f;
  36.         this->currentAnim = -1;
  37.     }
  38.     AnimationHandler(const sf::IntRect& frameSize)
  39.     {
  40.         this->frameSize = frameSize;
  42.         this->t = 0.0f;
  43.         this->currentAnim = -1;
  44.     }
  45. };
  47. #endif /* ANIMATION_HANDLER_HPP */

First up we have that std::vector of Animations we mentioned. t is the elapsed time since the animation started or looped, and is used to determine when the next frame should occur. Every time update is called we will increase t by dt to keep track of the time. currentAnim is the (vertical) index in the grid or the (horizontal) index in the std::vector used to keep track of which animation is running. The next three functions are self-explanatory (or are with the comments), but then we have some SFML code.

An sf::IntRect is a rectangle with integers for its start coordinate, its width, and its height. Since we’re using a single texture for all of the animations, we use an sf::IntRect to keep track of which section of the texture the sprite should show. Later we’ll tell the sprite to use that section of the texture by using sf::Sprite‘s setTextureRect member function. The constructors are rather straightforward, so we’ll move on to writing the algorithms for the handler to use. In animation_handler.cpp we first create the update function

  1. #include <SFML/Graphics.hpp>
  2. #include <vector>
  4. #include "animation_handler.hpp"
  6. void AnimationHandler::update(const float dt)
  7. {
  8.     if(currentAnim >= this->animations.size() || currentAnim < 0) return;
  10.     float duration = this->animations[currentAnim].duration;
  12.     /* Check if the animation has progessed to a new frame and if so
  13.      * change to the next frame */
  14.     if(int((t + dt) / duration) > int(t / duration))
  15.     {
  16.         /* Calculate the frame number */
  17.         int frame = int((t + dt) / duration);
  19.         /* Adjust for looping */
  20.         frame %= this->animations[currentAnim].getLength();
  22.         /* Set the sprite to the new frame */
  23.         sf::IntRect rect = this->frameSize;
  24.         rect.left = rect.width * frame;
  25. = rect.height * this->currentAnim;
  26.         this->bounds = rect;
  27.     }
  29.     /* Increment the time elapsed */
  30.     this->t += dt;
  31.     /* Adjust for looping */
  32.     if(this->t > duration * this->animations[currentAnim].getLength())
  33.     {
  34.         this->t = 0.0f;
  35.     }
  37.     return;
  38. }

Firstly, we don’t update if the current animation does not exist. The next line just saves us some writing every time we want to know the animation’s duration. If each animation takes durationseconds, then from t between 0 and duration, we’re on frame 0, t between duration and 2*duration we are on frame 1, t between 2*duration and 3*duration we are on frame 2, and so on.

If we divide t by duration them frame 0 is between 0 and 1, frame 1 is between 1 and 2, and so on. Thus if we round t / duration down (i.e. cast it to an integer) we get what frame of the animation is playing. So if the new time t+dt gives a different answer using that formula to t we need to advance the animation to the next frame. Can you see when this wouldn’t work? So long as dt < duration, we’ll only ever advance one frame at a time, but if dt is too large we should skip a frame of animation! That’s why we calculate the new frame on the next line, instead of just incrementing the frame number.


This brings us to another problem, however. If we have a 4 frame animation (0-3) then when we are on frame 3 we should not go to frame 4 or 5 or higher (depending on dt), we should loop back to frame 0, 1 or whatever is next! To do this we simply take the modulus of the frame with the number of frames to ensure that the animation loops correctly. This shows a limitation of our animation handler: every animation loops, and nothing happens at the end.

We then compute the rectangle of the texture that the sprite should show using the pattern mentioned before (frames move to the right). Regardless of whether the frame has changed or not we advance the elapsed time by the timestep and then ensure that the elapsed time resets round to 0 if it is greater than the duration of the animation. By setting it to 0 instead of taking the modulus (which is awkward with a floating point value) we may introduce a slight jitter at the end of the animation, but this is only noticeable if multiple frames are being jumped at once. Adding the last two functions,

  1. void AnimationHandler::addAnim(Animation& anim)
  2. {
  3.     this->animations.push_back(anim);
  5.     return;
  6. }
  8. void AnimationHandler::changeAnim(unsigned int animID)
  9. {
  10.     /* Do not change the animation if the animation is currently active or
  11.      * the new animation does not exist */
  12.     if(this->currentAnim == animID || animID >= this->animations.size() ||
  13.         animID < 0) return;
  15.     /* Set the current animation */
  16.     this->currentAnim = animID;
  17.     /* Update the animation bounds */
  18.     sf::IntRect rect = this->frameSize;
  19. = rect.height * animID;
  20.     this->bounds = rect;
  21.     this->t = 0.0;
  23.     return;
  24. }

addAnim just adds the specified animation to the animation std::vector, and changeAnim sets the current animation to the new one (if the new one is valid) before setting the bounds rectangle to the first frame and resetting the elapsed time. And with that our game engine is essentially complete! In part four, we’ll move back and add some more to GameStateEditor before moving on to the Tiles.

Source code for this section