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:

In this lesson, we’ll discuss some ways we can improve upon the Image class created in the previous lesson. We’ll cover three topics:

• Techniques for dealing with errors and unexpected situations
• Adding flexibility to our class, and working around some common problems that can occur when implementing a versatile API
• Using comments to document how our API works

The examples we use here are based on the Image class we created previously:

In this lesson, we’ll update our game to detect and react to the player winning or losing.

• To win, the player must clear all the cells that do not have bombs
• If the player clears a cell that has a bomb, they lose

Let’s get this working!

In this lesson, we’ll start using the SDL_Image extension we installed earlier. We’ll cover 3 main topics:

• Initializing and closing SDL_Image
• Using the IMG_Load() function to load and render a wide variety of image types, rather than being restricted to the basic bitmap (.bmp) format.
• Using surface blending modes to use transparency and other techniques when blitting
• Creating image files from our surfaces using IMG_SaveJPG() and IMG_SavePNG()

We’ll be building upon the basic application loop and surface-blitting concepts we covered earlier in the course:

In this lesson, we’ll see how we can render text within our programs. We’ll use the official SDL_ttf extension we installed earlier in the course.

We’ll build upon the concepts we introduced in the previous chapters. Our main.cpp looks like below.

The key thing to note is that we have created a Text class, and instantiated an object from it called TextExample. This object is being asked to Render() onto the window surface every frame:

In this lesson, we’ll build on our text rendering capabilities with some new tools:

• The ability to adjust the rasterizing process to optimize performance when appropriate
• Dynamically choosing a font size to fit a target pixel size for our rasterized surface
• Calculating how much text we can fit within a designated space
• Rendering multi-line text areas using word wrapping, and controlling the alignment of the lines

Our main.cpp is below. Compared to the last lesson, we’ve added a GetWidth() method to the Window class.