In the previous lesson, we introduced the concept of ticking and tick functions, which allow our game objects to update on every iteration of our application loop.

However, we should note that when we’re implementing logic in a Tick() function, we don’t know how quickly our objects will tick. That is, we do not know how much time has passed since the previous invocation of that object’s Tick() function.

1// Goblin.h
2#pragma once
3#include "GameObject.h"
4
5class Goblin : public GameObject {
6 public:
7  int xPosition;
8
9  void Tick() override {
10    // This object moves by one pixel per
11    // invocation of Tick(), but how frequently
12    // is Tick() invoked?
13    xPosition += 1;
14  }
15};

As we add more complexity to our tick functions or more ticking objects, our game will need to perform more work on each iteration of our application loop. As such, it will iterate less frequently, meaning Tick() is invoked less frequently, meaning our object will move slower.

On the other hand, if we perform optimizations or our user has a more powerful computer, our loop can iterate faster, causing our objects to move faster.

To address this inconsistency, we typically want to define properties like movement speed in terms of real-world units of time, such as seconds or milliseconds. Let’s learn how to do this.

Previously, we introduced the SDL_GetTicks64() function, which returns the number of milliseconds that have passed since SDL was initialized.

However, in some situations, milliseconds are not granular enough. We need to use timers that use smaller units, such as microseconds and nanoseconds.

Timers that use these smaller units are typically called high-resolution timers. How they work and how we access them is something that varies from platform to platform, but SDL provides some utilities that can help us.

At this point, we’re familiar with the many ways we store and transfer objects around our program. We can pass them as arguments to functions, return them from functions, and store them as variables.

1// Passing an int to a function
2SetNumber(42);
3
4// Returning an int from a function
5int GetNumber() {
6  return 42;
7}
8
9// Storing an int to a member variable
10SomeObject.SomeMember = 42;

What might be less familiar is that we can do all of these things with functions, too:

1void SomeFunction() {
2  // ...
3];
4
5// Passing a function to a function
6SetFunction(MyFunction);
7
8// Returning a function from a function
9auto GetFunction() {
10  return MyFunction;
11}
12
13// Storing a function as a member variable
14SomeObject.SomeFunction = MyFunction;

This capability gives us a huge amount of flexibility in how we design our program and when used well, it helps us keep our code simple even as our behaviors get more and more complex.

A language that allows functions to be treated like any other data type is said to support first-class functions. C++ supports this concept in a few different ways. In the rest of this chapter, we’ll focus on one of them - function pointers.

Previously, we’ve seen how we can create pointers to free functions:

1#include <functional>
2
3void FreeFunction() {/*...*/}
4
5int main() {
6  std::function FunctionPtr{FreeFunction};
7}

In large projects, it’s more common that we’ll be working with member functions - that is, functions that are defined as part of a class or struct:

1class SomeClass {
2  void MemberFunction() {/*...*/}
3};

In this lesson, we’ll learn how to work with pointers to these types of functions, and manage the additional complexity that is involved.

In our previous projects, we’ve updated the state of our objects based on events detected in our application loop:

1// Application Loop
2while (shouldContinue) {
3  // Handle Events
4  while (SDL_PollEvent(&Event)) {
5    if (Event.type == SDL_QUIT) {
6      shouldContinue = false;
7    }
8    GameObject.HandleEvent(Event);
9  }
10    
11  // Render Objects
12  GameWindow.Render();
13  GameObject.Render(GameWindow.GetSurface());
14    
15  // Update Frame
16  GameWindow.Update();
17}

However, in more complex projects, most objects may need to update their state consistently, even when they’re not receiving any events. For example, characters not controlled by our player may need to continue to act and move, and animation, and visual effects should continue to update.

In this lesson, we’ll introduce how to write data from our program to external sources. We’ll focus on writing to files for now, but the techniques we cover lay the foundations for working with other data streams, such as network traffic.

As we might expect, SDL’s mechanism for writing data shares much in common with their API for reading data. We’ll rely on SDL_RWops objects, and the functions we use will be familiar to what we learned in the previous lesson.

Like before, we’ll start with a basic main function that initializes SDL, and calls Write() and Read() functions within an included File namespace.

1// main.cpp
2#include <SDL.h>
3#include "File.h"
4
5int main(int argc, char** argv) {
6  SDL_Init(0);
7  File::Write("output.txt");
8  File::Read("output.txt");
9  return 0;
10}

Our Read() function logs out the file’s contents, using techniques we covered in the previous lesson. In this lesson, we’ll work on the Write() function, which is currently empty:

1// File.h
2#pragma once
3#include <iostream>
4#include <SDL.h>
5
6namespace File {
7  void Read(const std::string& Path) {
8    char* Content{static_cast<char*>(
9      SDL_LoadFile(Path.c_str(), nullptr)
10    )};
11    
12    if (Content) {
13      std::cout << "Content: " << Content;
14    } else {
15      std::cout << "Error loading file: "
16        << SDL_GetError();
17    }
18    
19    SDL_free(Content);
20  }
21  
22  void Write(const std::string& Path) {
23    // ...
24  }
25
26}

Running our program, we should see an error output from our Read() function, as it’s trying to read a file that we haven’t created yet:

1Error loading file: Parameter 'src' is invalid

Throughout this chapter, we’ve started to take more proactive control over the memory used in our programs, and controlling the lifecycle of objects (when they’re created, and when they’re destroyed)

We’ve used standard library utilities like std::unique_ptr and std::vector to help with this. In this lesson, we’ll learn how to take full control by manually managing our object lifecycles.

We’ll also see how this can be difficult, dangerous, and something to avoid where possible.

However, avoiding it is not always an option. In larger projects, we’ll interact with libraries or other systems that implement manual memory management, and understanding the techniques involved and problems to avoid will be extremely useful.

In this lesson, we’ll explore how objects are copied in more depth. There are two scenarios where our objects get copied. The first is when a new object is created by passing an existing object of the same type to the constructor:

1struct Weapon{/*...*/};
2
3int main() {
4  Weapon SwordA;
5  
6  // Create SwordB by copying SwordA
7  Weapon SwordB{SwordA};
8}

This copying process also happens when we pass an argument by value to a function. The function parameter is created by copying the object provided as the corresponding argument:

1struct Weapon{/*...*/};
2
3void SomeFunction(Weapon W) {/*...*/}
4
5int main() {
6  Weapon Sword;
7  
8  // Create the W parameter by copying Sword
9  SomeFunction(Sword);
10}

The second scenario is when an existing object is provided as the right operand to the = operator. In the following example, we’re expecting an existing PlayerTwo to be updated by copying values from PlayerOne:

1struct Weapon{/*...*/};
2
3int main() {
4  Weapon SwordA;
5  Weapon SwordB;
6  
7  // Update SwordA by copying values from SwordB
8  SwordA = SwordB;
9}

As we’ve likely noticed, C++ supports these behaviors by default, even when the objects we’re copying use our custom types. In this lesson, we’ll explore what that default behavior does, and learn how to override it when our classes and structs have more complex requirements.

Inevitably, we will want to store a group of related objects. That might be a collection of characters in a party, a collection of buttons on a UI, or countless other use cases.

Let's imagine we have these objects, which we want to store and manage as a single collection:

1class Character {};
2Character Frodo;
3Character Gandalf;
4Character Gimli;
5Character Legolas;
6Character Aragorn;

Programmers have invented a huge range of options for storing collections of objects. These containers are broadly called data structures, and which data structure we should use depends on our specific requirements. We’ll cover a much wider range of data structures in the next course. Here, we’ll introduce the most common choice - the dynamic array.

Under the hood, arrays are contiguous blocks of memory, big enough to store multiple objects in sequence.

In this chapter, we’ll introduce read/write operations, specifically using SDL_RWops. This is the API that SDL provides for reading from and writing to files on our players’ hard drives.

Many of the topics covered here additionally lay the foundation for more advanced capabilities. Streaming data to and from files has much in common with streaming data over a network, for example, which is fundamental for creating multiplayer games.

In this lesson, we’ll create a basic SDL application that calls Write() and then Read() within a File namespace we’ll create. The file I/O system is initialized by default, so we can simply pass 0 as the initialization flag to SDL_Init():

1#include <SDL.h>
2#include "File.h"
3
4int main(int argc, char** argv) {
5  SDL_Init(0);
6  File::Write("data.txt");
7  File::Read("data.txt");
8  return 0;
9}

The following code example shows the content of our File namespace.

We’ll focus on the Read() function in this lesson and will cover writing in the next lesson. For now, we can just note that Write() creates a file on our hard drive containing the text "Hello World", so we have something to test our Read() function with:

1// File.h
2#pragma once
3#include <iostream>
4#include <SDL.h>
5
6namespace File{
7  void Read(const std::string& Path) {}
8  
9  void Write(const std::string& Path) {
10    SDL_RWops* Context{
11      SDL_RWFromFile(Path.c_str(), "wb")};
12    const char* Content{"Hello World"};
13    SDL_RWwrite(Context, Content, sizeof(char),
14                strlen(Content));
15    SDL_RWclose(Context);
16  }
17}

In this final part of our Minesweeper series, we'll add the ability for players to place flags on suspected mine locations.

We'll update our game logic to handle flag placement and removal, create a visual representation for flags, and implement a counter to track the number of flags placed.

By the end of this lesson, you'll have a fully functional Minesweeper game with all the classic features players expect!

In this series, we'll build a fully functional Minesweeper game from scratch, giving you hands-on experience with game development concepts and C++ programming.

We'll separate our project into two main parts:

1. An "Engine" module containing components that are generally useful across a wide range of projects, not specific to Minesweeper.
2. A Minesweeper-specific module that builds upon our engine to create the actual game.

For example, we'll create a general Button class in our engine that can be used across various projects. The cells of our Minesweeper grid will then inherit from this Button class, expanding it with Minesweeper-specific logic such as whether the cell contains a bomb and counting the number of bombs in adjacent cells.

In this lesson, we’ll combine the techniques we’ve covered so far in this chapter into a cohesive Image class. We’ll focus on creating a friendly API so external code can easily control how images are rendered onto their surfaces We’ll cover:

• Creating a flexible API for image handling
• Implementing file loading and error checking
• Setting up source and destination rectangles
• Adding different scaling modes for rendering
• Optimizing performance for game loops

As a starting point, we’ll be building upon a basic Window and application loop, built using topics we covered earlier in the course: