Hardware and execution time

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.

Note

An emulator is either software, hardware, or the combination of both, that simulates the functionality of a certain system, usually referred to as a guest, on a primary system, referred to as the host.

Every emulator used for this purpose not only has to imitate the software of a system that would be compatible with a title you're attempting to play, but also the hardware. Why is that important? Most games in the days of DOS counted on the hardware being roughly similar. In the case of Wolfenstein 3D, it assumed it was running on a 4.77 MHz system, which allowed the developers to save some clock cycles for the sake of efficiency by not writing internal timing loops. A game like Wolfenstein 3D consumed all of the processing power, which was a fine strategy for the time, until more powerful and faster processors came about. Today, the puny 4.77 MHz speed is dwarfed by comparison, even when looking at all of the cheapest consumer-grade processors, so proper emulation of a specific system also requires the reduction of CPU clock cycles, otherwise these games will run too fast, which is exactly what happens when an emulator is set up in the wrong way and doesn't throttle the speed enough.

While this is the most extreme example, speed management is an important component of any piece of software today that has to run at a constant speed. Different choices of hardware and architecture aside, your software might run faster or slower simply based on how busy your system is at the time or the different tasks your code needs to accomplish every iteration before the image is rendered. Consider the following illustration:

The changes on the left side as well as the right side both take place over a 1 second interval. The code is exactly the same in both cases. The only difference is the number of iterations the main loop manages to complete during that interval. Predictably, the slower hardware will take longer to execute your code and therefore will yield fewer iterations, resulting in the sprite being moved fewer times during our 1 second time interval and end up looking like the left side. As a game developer, it is important to ensure that your product runs the same on all systems within the designated specification guidelines. This is where SFML time management comes in.

Controlling the frame-rate

SFML provides a means of setting a frame-rate cap for your applications. It's a method in the sf::RenderWindow class, appropriately called setFramerateLimit:

m_window.setFramerateLimit(60); // 60 FPS cap.

Although this feature is not absolutely reliable, it ensures that the application's frame-rate is capped at the provided maximum value with reasonable precision, as long as the provided cap isn't too high. Keep in mind that capping the frame-rate reduces the overall CPU consumption of the program as well, since it doesn't need to update and re-draw the same scene as many times anymore. It does, however, raise a problem for slower hardware. If the frame-rate is lower than the provided value, the simulation will run slower too. Setting the limit solves only half of our problem. Let's take a look at something more practical. Enter sf::Clock!