SFML Game Development By Example: Create and develop exciting games from start to finish using SFML

Let's start small. Every game needs to have a window, and as you already know from Chapter 1, It's Alive! It's Alive! – Setup and First Program, it needs to be created, destroyed, and its events need to be processed. It also needs to be able to clear the screen and update itself to show anything drawn after the screen was cleared. Additionally, keeping track of whether the window is being closed and if it's in full-screen mode, as well as having a method to toggle the latter would be quite useful. Lastly, we will, of course, need to draw to the window. Knowing all of that, the header of our window class will predictably look something like this:

class Window{
public:
    Window();
    Window(const std::string& l_title,const sf::Vector2u& l_size);
    ~Window();

    void BeginDraw(); // Clear the window.
    void EndDraw(); // Display the changes.

    void Update();

    bool IsDone();
    bool IsFullscreen();
    sf::Vector2u GetWindowSize();

    void ToggleFullscreen...

Now that we have our blueprint, let's begin actually building our window class. The entry and exit points seem as good a place as any to start with:

Window::Window(){ Setup("Window", sf::Vector2u(640,480)); }

Window::Window(const std::string& l_title, const sf::Vector2u& l_size)
{
    Setup(l_title,l_size);
}

Window::~Window(){ Destroy(); }

Both implementations of the constructor and destructor simply utilize the helper methods which we'll be implementing shortly. There's also a default constructor that takes no arguments and initializes some pre-set default values, which is not necessary, but it's convenient. With that said, let's take a look at the setup method:

void Window::Setup(const std::string l_title, const sf::Vector2u& l_size)
{
    m_windowTitle = l_title;
    m_windowSize = l_size;
    m_isFullscreen = false;
    m_isDone = false;
    Create();
}

Once again, this is quite simple. As mentioned before, it initializes and keeps track of some...

We've done a good job at wrapping up the basic functionality of our window class, but that's not the only chunk of code in need of refactoring. In Chapter 1, It's Alive! It's Alive! – Setup and First Program, we've discussed the main game loop and its contents, mainly processing input, updating the game world and the player, and finally, rendering everything on screen. Cramming all of that functionality into the game loop alone is generally known to produce spaghetti code, and since we want to move away from that, let's consider a better structure that would allow this kind of behavior:

#include "Game.h"

void main(int argc, void** argv[]){
    // Program entry point.
    Game game; // Creating our game object.
    while(!game.GetWindow()->IsDone()){
        // Game loop.
        game.HandleInput();
        game.Update();
        game.Render();
    }
}

The code above represents the entire content of our main.cpp file and perfectly illustrates the use of a properly...

Let's travel back in time to May 5, 1992. Apogee Software begins publishing the now known cult classic Wolfenstein 3D developed by id Software:

The man with the vision, John Carmack, took massive strides forward and not only popularized, but also revolutionized the first person shooter genre on the PC. Its massive success cannot be overstated, as even now it's difficult to accurately predict how many times it has been downloaded. Having grown up at right around that time, one can't help but feel nostalgic sometimes and attempt to play this game again. Ever since its original release for the DOS operating system on the PC, it has been ported to many other operating systems and consoles. While it's still possible to play it, we've come a long way since the days of using DOS. The environment our software runs in has fundamentally changed, ergo the software from the past is no longer compatible, hence the need for emulation.

The sf::Clock class is very simple and lightweight, so it has only two methods: getElapsedTime() and restart(). Its sole purpose is to measure elapsed time since the last instance of the clock being restarted, or since its creation, in the most precise manner the operating system can provide. When retrieving the elapsed time using the getElapsedTime method, it returns a type sf::Time. The main reasoning behind that is an additional layer of abstraction to provide flexibility and avoid imposing any fixed data types. The sf::Time class is also lightweight and provides three useful methods for conversion of elapsed time to seconds which returns a floating point value, milliseconds, which returns a 32-bit integer value and microseconds, which returns a 64-bit integer value, as represented here:

sf::Clock clock;
...
sf::Time time = clock.getElapsedTime();

float seconds = time.asSeconds();
sf::Int32 milliseconds = time.asMilliseconds();
sf::Int64 microseconds = time.asMicroseconds...

In some cases, the code for time management that we've written doesn't really apply correctly. Let's say we only want to call certain methods at a fixed rate of 60 times per second. It could be a physics system that requires updating only a certain amount of times, or it can be useful if the game is grid-based. Whatever the case is, when an update rate is really important, a fixed time-step is your friend. Unlike the variable time-step, where the next update and draw happens as soon as the previous one is done, the fixed time-step approach will ensure that certain game logic is only happening at a provided rate. It's fairly simple to implement a fixed time-step. First, we must make sure that instead of overwriting the elapsed time value of the previous iteration, we add to it like so:

void Game::RestartClock(){
    m_elapsed += m_clock.restart();
}

The basic expression for calculating the amount of time for an individual update throughout a 1 second interval is illustrated...

Often, when using clocks, newbies to SFML tend to stick them in the wrong places and restart them at the wrong times. Things like that can result in "funky" behavior at best.

Things like updating all of the game entities in the world, performing calculations, and rendering are fairly computationally expensive, so make sure to not somehow exclude these calls from the span of your time measurement. Always make sure that restarting the clock and grabbing the elapsed time is the last thing you're doing before the main game loop ends.

Another mistake is having your clock object within the wrong scope. Consider this example:

void Game::SomeMethod(){
    sf::Clock clock;
    ...
    sf::Time time = clock.getElapsedTime();
}

Assuming...

Congratulations on finishing the second chapter of this book! As mentioned previously, it is imperative that you understand everything covered in this chapter, since everything that follows will rely heavily on what we covered here.

Smooth and consistent results on different platforms and under different conditions are just as important as a good structure of an application, which is yet another layer of lasagna, if you will. Upon successful completion of this chapter, you are left yet again with sufficient knowledge to produce applications that can utilize both fixed and variable time-steps in order to create simulations that run identically and independently of the underlying architecture.

Finally, we will leave you with a piece of good advice. The first few chapters are something most readers follow relatively closely and literally. While that's an acceptable way of doing things, we'd prefer you to use this more like a guide instead of a recipe. The most amazing thing about human...