SFML Game Development: If you've got a firm grasp of C++ with a secret hankering to create a great game, this book is for you. Every practical aspect of programming an interactive game world is here – the only real limit is your imagination.

There are two possibilities when using SFML: download the pre-built libraries, or recompile them yourself. The first option is simpler, but you have to wait for major versions (2.0, 2.1, and so on) to be released. If you want to use the latest development sources, you can download the current Git revision. The configuration software CMake is used to prepare the sources for compilation with a compiler of your choice. For example, CMake creates Visual Studio solutions or g++ Makefiles. The recompilation process is explained in detail in the SFML tutorials, which can be found at www.sfml-dev.org/tutorials.php.

As mentioned, SFML is split into five modules. There are five headers to include a complete module (and its dependencies). To include the whole Audio module, you can write:

#include <SFML/Audio.hpp>

On the other hand, if you need a specific header file, you can find it in the directory of the corresponding module:

#include <SFML/Audio/Sound.hpp>

Each module is compiled to a separate library, which makes it possible to use only the modules you need. SFML can be built for release or debug mode, and it can be linked statically or dynamically. The resulting libraries are named according to the scheme sfml-module[-s][-d]. The -s postfix is required if you link statically; the -d postfix specifies debug mode. For example, to link the Graphics module statically in release mode, you have to specify the library sfml-graphics-s in your linker options. Depending on your compiler, a file extension (such as .lib) might be necessary. Keep in mind that some modules depend on others; therefore, you have to link the dependencies too. For example, Graphics depends on Window, which depends on System; therefore, you should link the three (in this order).

An important point to note is that if you link SFML statically, you have to define the macro SFML_STATIC in your projects, so that the linker knows what functions to resolve.

In case you do not know how linking a library works for a specific compiler, please refer to the online tutorials. They explain how to install everything correctly, and are always up-to-date.

Before you go deeper into the book and SFML itself, let's take a look at a minimal application example to show how an application that uses this library looks like, its general flow of execution, and some basic functionality.

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(640, 480), "SFML Application");
    sf::CircleShape shape;
    shape.setRadius(40.f);
    shape.setPosition(100.f, 100.f);
    shape.setFillColor(sf::Color::Cyan);
    while (window.isOpen())
    {
    sf::Event event;
    while (window.pollEvent(event))
    {
        if (event.type == sf::Event::Closed)
            window.close();
    }
    window.clear();
    window.draw(shape);
    window.display();
    }
}

All this application does is to open a window onto which we can render, with a width of 640 pixels and a height of 480 pixels. Its title says "SFML Application". Then, a cyan geometric circle is created, and while the window is open, it is drawn to the screen. Finally, for each time the circle is drawn, the program checks for user input that may have arrived from the underlying window. In our case, we only handle the sf::Event::Closed event, which arrives every time the application is requested to terminate, such as when we click on the close button, or press an application-terminating shortcut, such as Alt + F4.

If you failed to understand a part of or the whole snippet of code, don't fear. This book contains all you need to know about this and much more.

In this chapter, we implement the basis for your game that will get you going. The root for us is a class called Game; instead of doing our logic in the main() function as we did in the minimal example, we move everything into the Game class instead. This is a good starting point—it gives us a better overview of our code, as we can extract separate functionality into their own functions, and use them within the Game class. If we look at the minimal example, we had three distinct areas in the code: initialization, event processing, and rendering. Now if we continued to develop there, these three parts would grow quite a lot, and we would end up with a gigantic wall of code, which would be nearly impossible to navigate. The Game class helps us out here.

Here is the general design of the class and its intended usage:

class Game
{
    public:Game();
        void             run();

    private:
        void             processEvents();
        void             update();
        void             render();

    private:
        sf::RenderWindow mWindow;
        sf::CircleShape  mPlayer;
};

int main()
{
    Game game;
    game.run();
}

As you can clearly see, we replaced all the code in the main() function from the minimal example with just a Game object and a call to its run() function. The idea here is that we have hidden the loop we had previously in the run() function. It doesn't happen very often that we have to fiddle with it anyway. Now, we can move the actual code that updates the game to the update() function, and the code that renders it to the render() function. The method processEvents() is responsible for player input. So if we want to get something actually done, we implement it in one of the three private functions.

Let's have a look at the code now:

Game::Game()
: mWindow(sf::VideoMode(640, 480), "SFML Application")
, mPlayer()
{
    mPlayer.setRadius(40.f);
    mPlayer.setPosition(100.f, 100.f);
    mPlayer.setFillColor(sf::Color::Cyan);
}
void Game::run()
{
    while (mWindow.isOpen())
    {
        processEvents();
        update();
        render();
    }
}

The function processEvents() handles user input. It polls the application window for any input events, and will close the window if a Closed event occurs (the user clicks on the window's X button).

void Game::processEvents()
{
    sf::Event event;
    while (mWindow.pollEvent(event))
    {
        if (event.type == sf::Event::Closed)
            mWindow.close();
    }
}

The method update() updates the game logic, that is, everything that happens in the game. For the moment, we leave the implementation empty. We are going to fill it as we add functionality to the game.

void Game::update()
{
}

The render() method renders our game to the screen. It consists of three parts. First, we clear the window with a color, usually black. Therefore, the output of the last rendering is completely overridden. Then, we draw all the objects of the current frame by calling the sf::RenderWindow::draw() method. After we have drawn everything, we need to actually display it on the screen. The render() method looks as follows:

void Game::render()
{
    mWindow.clear();
    mWindow.draw(mPlayer);
    mWindow.display();
}

Later in the chapter, when we display something more interesting than a cyan circle, we are going to have a deeper look at the rendering step.

Even though this actually is more code than what we started with, it still looks like it is less, because at any given time, our eyes only have to rest on a smaller part.

And with this you should still get the same result as you would in the SFML minimal example: a cyan-colored circle in a window with a black background. Nothing fancy yet, but we are well on our way.

First we have to be able to detect that the user is pressing down a key on his keyboard. SFML provides this functionality in several ways, but for now we will settle with input detection by responding to events.

What are events? The word itself implies something that is happening with our window, emitting a notice of the happening. As soon as the user somehow interacts with our window, the operating system sends an event that we can process. For our convenience, SFML translates events from the underlying operating systems to a uniform structure that we can use with ease: sf::Event. Once the window internally detects that some kind of input has happened, it will store an sf::Event object containing information about that input. We will then poll all those events as fast as we can, in order to respond to them.

SFML supports a wide variety of events, but there are two event types that interest us here: sf::Event::KeyPressed and sf::Event::KeyReleased. They represent a key being pressed and released respectively.

So let's change our code so that it can handle this. We again poll the window for events, and have a case differentiation on the event type.

void Game::processEvents()
{
    sf::Event event;
    while (mWindow.pollEvent(event))
    {
        switch (event.type)
        {

For each time the while loop iterates, it means a new event that was registered by the window is being handled. While there can be many different events, we will only check for some types of events, which are of our interest right now.

            case sf::Event::KeyPressed:
                handlePlayerInput(event.key.code, true);
                break;
            case sf::Event::KeyReleased:
                handlePlayerInput(event.key.code, false);
                break;
            case sf::Event::Closed:
                mWindow.close();
                break;
        }
    }
}

In the handlePlayerInput() function, we check which key on the keyboard has been pressed or released. To store this information, we use four Boolean member variables: mIsMovingUp, mIsMovingDown, mIsMovingLeft, and mIsMovingRight. We set the corresponding variable depending on the key being pressed or released.

void Game::handlePlayerInput(sf::Keyboard::Key key,bool isPressed)
{  
    if (key == sf::Keyboard::W)
        mIsMovingUp = isPressed;
    else if (key == sf::Keyboard::S)
        mIsMovingDown = isPressed;
    else if (key == sf::Keyboard::A)
        mIsMovingLeft = isPressed;
    else if (key == sf::Keyboard::D)
        mIsMovingRight = isPressed;
}

In Game::handlePlayerInput()we receive the enumerator describing the key that was pressed or released. The flag describing whether a press or release occurred is passed as the second argument. So we check what key the user is manipulating, and change our state depending on that.

Now, we have a way to perceive that the user is pressing a key. We know when we want to move up, down, left, and right. We know at each iteration of the main loop exactly, what the user wants; we just have to update the circle with a new position depending on this input. This method gives us a great advantage. So finally we can write something in our update() function, namely, the movement of our player. We check which of the four Boolean member variables is true, and determine the movement accordingly. By using += (instead of =) and if (instead of else if), we implicitly handle the case where two opposite keys, such as right and left are pressed at the same time—the movement stays zero. The update() function is shown in the following code snippet:

void Game::update()
{
    sf::Vector2f movement(0.f, 0.f);
    if (mIsMovingUp)
        movement.y -= 1.f;
    if (mIsMovingDown)
        movement.y += 1.f;
    if (mIsMovingLeft)
        movement.x -= 1.f;
    if (mIsMovingRight)
        movement.x += 1.f;

    mPlayer.move(movement);
}

We introduce two new things here: a vector and the move() function on the circle shape. The move() function does what its name says, it moves the shape by the amount we provide it.

Vectors are an important part of algebraic mathematics. They imply lots of rules and definitions, which go beyond the scope of our book. However, SFML's sf::Vector2 class template is way more practical, both in concept and functionality. To be as simple as we could possibly be, we know that a coordinate in a two-dimensional Cartesian system would need two components: x and y. Because in graphics all coordinates are expressed with the decimal float data type, sf::Vector2 is instantiated as sf::Vector2<float>, which conveniently has a typedef named sf::Vector2f. Such an object is made to contain two member variables, x and y. This makes our life simpler, because now we don't need to pass two variables to functions, as we can fit both in a single sf::Vector2f object. sf::Vector2f also defines common vector operations, such as additions and subtractions with other vectors, or multiplications and divisions with scalars (single values), effectively shortening our code.

To be a little more precise in the explanation, vectors are not only used to define positions, but they also are a perfect fit to define orientations. So, a vector is great to store a two-component coordinate, be it an absolute or relative position, or even to express a direction to follow, or to shoot a bullet towards. There is a little more to know about two-dimensional vectors, especially if they are directions, such as the concept of normalization or unit vector. This operation applies only to directions, as it makes no sense in positions. We consider a vector normalized if it has length one (hence the term unit vector) and the vector still expresses the same direction as before normalization. The following figure visualizes the vector (2, 3). This vector represents a translation of 2 units to the right and 3 units down.

Please do not confuse sf::Vector2f with std::vector. While their names are similar, the first refers to the mathematical concept; the latter is simply a dynamically allocated array from the standard C++ library.

In our case, our vector called movement expresses a movement from the origin of the current coordinate system. For us, this origin is the shape's position. It might be a bit tricky getting into the whole way of thinking in different spaces if you don't like math.

Vector algebra is very interesting, and definitely something very useful if you know it. So we recommend you study it. Mathematics is your friend as soon as you stop fighting it; it really makes a lot of things easier for you in programming. It is almost safe to claim that this subsection of math is the single most important topic when we need to implement gameplay mechanics. A wide range of problems that you will face in almost any kind of game are already solved and well-studied before, so you're better off learning this subject than reinventing the wheel every time. To avoid leaving you hanging, here's an example: Let's say you have point A and point B, which represent two characters in an action game. When the enemy at point A wants to shoot our player at point B, it needs to know the direction in which to shoot the projectile. Why waste your brains thinking on how to solve this problem if this field of math defines this operation as one of its most basic rules? All you need is to find the direction vector C, which is obtained by calculating B minus A. The difference between two positions gives us the direction between the two. Yes, that easy!

If you run everything we have done so far, you will be able to move the circle, but it won't move uniformly. It will probably be very fast, because currently we have done the movement in a very naive way. Right now your computer will be running the update() function as fast as it can, which means it will probably call it a couple of hundreds of times each second, if not more. If we move the shape by one pixel for every frame, this can count up to several 100 pixels every second, making our little player fly all over the screen. You cannot just change the movement value to something lower, as it will only fix the problem for your computer. If you move to a slower or faster computer, the speed will change again.

So how do we solve this? Well, let's look at the problem we are facing. We are having a problem because our movement is frame-dependent. We want to provide the speed in a way that changes depending on the time a frame takes. There is a simple formula you should remember from your old school days. It's the formula that goes: distance = speed * time. Now why is this relevant for us? Because with this formula we can calculate a relevant speed for every frame, so that the circle always travels exactly the distance we want it to travel over one second, no matter what computer we are sitting on. So let's modify the function to what we actually need to make this work.

void Game::update(sf::Time deltaTime)
{
    sf::Vector2f movement(0.f, 0.f);
    if (mIsMovingUp)
        movement.y -= PlayerSpeed;
    if (mIsMovingDown)
        movement.y += PlayerSpeed;
    if (mIsMovingLeft)
        movement.x -= PlayerSpeed;
    if (mIsMovingRight)
        movement.x += PlayerSpeed;

    mPlayer.move(movement * deltaTime.asSeconds());
}

The major difference we have made here is that we now receive a time value every time we call the update. We calculate the distance we want to travel every frame, depending on how much time has elapsed. We call the time that has elapsed since the last frame delta time (or time step), and often abbreviate it as dt in the code. But how do we get this time? We are lucky because SFML provides the utilities for it.

In SFML, there is a class that measures the time from when it was started. What we have to do is to measure the time each frame takes. We are talking about the class sf::Clock. It has a function called restart(), which lets the clock return the elapsed time since its start, and restarts the clock from zero, making it ideal for our current situation. SFML uses the class sf::Time for all time formats; it is a convenient data type that can be converted from and to seconds, milliseconds, and microseconds. Here's the modified Game::run() member function:

void Game::run()
{
    sf::Clock clock;
    while (mWindow.isOpen())
    {
        sf::Time deltaTime = clock.restart();
        processEvents();
        update(deltaTime);
        render();
  }
}

There is no big difference; we create a clock, and in every frame we query it for its current elapsed time, restart the clock, and then pass this time to the update function.

The solution we have come up with so far is sufficient for many cases. But it is not a perfect solution, because you can have problems in certain scenarios where delta times vary strongly. The code can be quite hard to debug, because it is impossible to get 100 percent reproducible results, since every frame is unique, and you can't guarantee that the delta time remains the same.

Consider that a frame may sometimes take three times the average delta time. This can lead to severe mistakes in the game logic, for example, when a player moves three times the distance and passes through a wall he would normally collide with. This is why physics engines expect the delta time to be fixed.

The following is a figure describing the problem we are referring to:

What we will do now is use a technique called fixed time steps. We write code that guarantees that in any circumstances, we always give the same delta time to the update function, no matter what happens. If you find that sounding difficult, there is no big difference from what we already have. We just have to do some book-keeping in our code for how much time has passed since we last called the update() function.

void Game::run()
{
    sf::Clock clock;
    sf::Time timeSinceLastUpdate = sf::Time::Zero;
    while (mWindow.isOpen())
    {
        processEvents();
        timeSinceLastUpdate += clock.restart();
        while (timeSinceLastUpdate > TimePerFrame)
        {
            timeSinceLastUpdate -= TimePerFrame;
            processEvents();
            update(TimePerFrame);
        }
        render();
    }
}

The actual effect of this change is that we accumulate how much time has elapsed in a variable timeSinceLastUpdate. When we are over the required amount for one frame, we subtract the desired length of this frame (namely TimePerFrame), and update the game. We do this until we are below the required amount again. This solves the problem with variable delta times, as we are guaranteed that the same amount of frames is always run. In the application you can download, the logic frame rate will be set to 60 frames per second by having the TimePerFrame constant equal to sf::seconds(1.f / 60.f).

Eventually, we have two while loops. The outer one is the game loop as we know it, and calls the render() method. The inner one collects user input, and computes the game logic; this loop is executed at a constant rate. If rendering is slow, it may happen that processEvents() and update() are called multiple times before one render() call. As a result, the game occasionally stutters, since, not every update is rendered, but the game doesn't slow down. On the other hand, fast rendering can lead to render() being called multiple times without a logic update in between. Rendering the same state multiple times does not change anything on the screen, but it allows for techniques such as interpolations between two states to smoothen the game flow.

If you are interested in the topic, there is a famous article with detailed explanations at http://gafferongames.com/game-physics/fix-your-timestep.

SFML provides a few utilities that are worth knowing with respect to time handling and frame updates. One of them is sf::sleep(), a function that interrupts the execution for a given time, which gives the processor an opportunity to work on other tasks. Sleeping is not very accurate, so you should not use it for exact timing purposes. The method sf::RenderWindow::setFramerateLimit() tries to achieve the specified frame rate by calling sf::sleep() internally. It is a nice function for testing purposes, but it also lacks precision.

Another important technique is vertical synchronization, also known as V-Sync. Enabled V-Sync adapts the rate of graphical updates (calls of sf::RenderWindow::display()) to the refresh rate of the monitor, usually around 60Hz. This can avoid graphical artifacts such as screen tearing, where a part of your window shows the old frame, and another the new one. You can enable or disable V-Sync using the method sf::RenderWindow::setVerticalSyncEnabled().

About file paths, it would be useful to make some things clear. First, the slashes that separate directories in a path in order to locate a file will be most often forward slashes (/), especially in Unix-like operating systems. In Windows, you will occasionally see back slashes (\) used instead, but probably not everywhere. Do not let this confuse you, the only true cross-platform way to specify a file path is using forward slashes, so make sure they are always your choice, even in Windows.

Also, it is of extreme importance to note that every program being run in the operating systems that SFML supports has a working directory while being executed. Usually, when you run the program from a graphical window manager, the working directory is exactly where the executable is located; however, this is not always the case. It is possible to run a program with any working directory, and it is even possible to change the working directory programmatically from inside the program. In the context of a game, the point of understanding working directories is for loading files, which are loaded in paths relative to the executable in most cases. All paths passed on to SFML are relative to the working directory, unless you make them absolute by starting them with a slash in Unix-like operating systems, or with a drive letter in Windows.

In a game simulation, it is highly likely that there will be changes to what's drawn in every frame. Even when there is no player input, you will observe in most cases some kind of animation, which will effectively change the end result on the screen for that given frame.

Many programs use a render-on-demand approach. They will only redraw a new frame on the screen when a change actually happens, minimizing the performance costs in applications where the screen doesn't change very often. But, by the nature of gaming software, this approach would be made redundant, as we would be requesting new frames all the time. Because of this, game programmers adopted entirely the concept of real-time rendering, which ignores frame requests as they were previously known, and blindly draws to the screen as fast as possible. If while playing your favorite game you eventually noticed a usual FPS count of 30 or 60, this is due to the fact that our eyes can't perceive, in regular circumstances, more frames than that amount in a second. Because it makes virtually no difference to the end user, the programmers limit the FPS count to such a number, and save the processor power for other tasks, such as logic processing. In short, nowadays, the whole scene is rendered again and again, independently of what changed since the last frame.

To explain the notion of real-time rendering a bit further, we would like to mention the concept of double buffering that comes inherently attached to it. Double buffering is a technique that was created to negate graphical glitches derived from asynchronies in the rendering tasks. Before this technique became widely used, programmers needed to have additional concerns when drawing to the screen, to ensure that only what belongs to a frame is drawn in it, and that there are no remains of pixels from previous frames.

Double buffering defines two virtual screens to draw graphics to. The front buffer and the back buffer are the names chosen to address these render targets. The front buffer is what is currently displayed on the screen, while the back buffer is the one we are drawing to at the moment, preparing a new frame. Once our frame is fully drawn in the back buffer, we use the SFML's sf::RenderWindow::display() function to put the contents of the back buffer on the screen. The back buffer becomes the front buffer, while the front buffer that was set will now be the back buffer to draw on. This way we ensure that we always have a buffer with the previous frame unharmed, as well as a working buffer that we can safely change at any time, without affecting what is on the screen. By clearing, drawing, and then displaying these buffers in an interleaved manner, we achieve double buffering.

In our code, we replace sf::CircleShape with sf::Sprite, which only requires minor modifications. We load an image file called Eagle.png. The relative path to it is Media/Textures. Don't worry if you don't have the file; you can download it together with the whole source code.

// Game.hpp
class Game
{
    public:
                    Game();
        ...
    private:
        sf::Texture mTexture;
        sf::Sprite  mPlayer;
        ...
};

// Game.cpp
Game::Game()
: ...
, mTexture()
, mPlayer()
{
    if (!mTexture.loadFromFile("Media/Textures/Eagle.png"))
    {
        // Handle loading error
    }
    mPlayer.setTexture(mTexture);
    mPlayer.setPosition(100.f, 100.f);
}

No code changes have to be done to get our render() function to work with sprites instead of shapes. SFML is nice in that way. Everything that can be drawn to a window has to inherit from the abstract class sf::Drawable. As long as it is possible, the SFML API keeps a consistency to it. This makes it a lot easier to use, because if you have used a function on one class, you can be pretty sure there will be identical or similar functions in other classes.

Now you have achieved the results you observed in the screenshot we had in the beginning of the chapter. You are also very well on the way to making your game. With these few tools alone you would be able to make a simple game, such as Snake or Pac-Man with ease.