The SDL Library and Cross-Platform Development

Welcome to the course! Before we get started, it's worth taking a moment to understand what SDL is, and the problems it solves.

This lesson will set the stage for everything that follows. We'll explore the complexities of talking directly to your computer's hardware, see how libraries like SDL can help, and discuss why building things from the ground up is such a valuable learning experience, even in a world of pre-built game engines.

At its core, a computer program is a set of instructions that tells the hardware what to do. If you want to create a graphical application - like a game - you need to tell the computer to do things like create a window, draw shapes and images to the screen, listen for mouse clicks and keyboard presses, and play sounds.

The challenge is that different operating systems (like Windows, macOS, and Linux) have completely different ways of handling these tasks. They provide programmers with an Application Programming Interface, or API, which is a set of functions and protocols for building software.

To create a simple, empty window on Microsoft Windows, you need to use its native API, often called the Win32 API. It's a C-based framework that gives you direct access to the operating system's features.

Here's what a minimal program to create a window using the Win32 API looks like. Don't worry about not understanding this code. It's included only to demonstrate how complex this task can be, and how much it relies on obtuse, platform-specific knowledge of poorly-named functions and types:

1#pragma comment(linker, "/SUBSYSTEM:WINDOWS")
2#include <windows.h> // Using the Windows API
3
4// Forward declaration of the window procedure
5LRESULT CALLBACK WindowProc(
6  HWND hwnd, UINT uMsg,
7  WPARAM wParam, LPARAM lParam
8);
9
10int WINAPI wWinMain(
11  HINSTANCE hInstance,
12  HINSTANCE hPrevInstance,
13  PWSTR lpCmdLine,
14  int nCmdShow
15) {
16  static const wchar_t CLASS_NAME[]{
17    L"Sample Window Class"
18  };
19
20  WNDCLASSW wc{};
21  wc.lpfnWndProc = WindowProc;
22  wc.hInstance = hInstance;
23  wc.lpszClassName = CLASS_NAME;
24  RegisterClassW(&wc);
25
26  HWND hwnd{
27    CreateWindowExW(
28      0,
29      CLASS_NAME,
30      L"My Awesome Game",
31      WS_OVERLAPPEDWINDOW,
32      CW_USEDEFAULT, CW_USEDEFAULT,
33      800, 600,
34      nullptr, nullptr,
35      hInstance,
36      nullptr
37    )};
38
39  if (!hwnd) return 0;
40
41  ShowWindow(hwnd, nCmdShow);
42
43  MSG msg{};
44  while (GetMessageW(&msg, nullptr, 0, 0) > 0) {
45    TranslateMessage(&msg);
46    DispatchMessageW(&msg);
47  }
48  return 0;
49}
50
51// Handles messages sent to the window
52LRESULT CALLBACK WindowProc(
53  HWND hwnd, UINT uMsg,
54  WPARAM wParam, LPARAM lParam
55) {
56  switch (uMsg) {
57  case WM_DESTROY:
58    PostQuitMessage(0);
59    return 0;
60
61  case WM_PAINT: {
62    PAINTSTRUCT ps;
63    HDC hdc{BeginPaint(hwnd, &ps)};
64    FillRect(
65      hdc, &ps.rcPaint,
66      (HBRUSH)(COLOR_WINDOW + 1)
67    );
68    EndPaint(hwnd, &ps);
69    return 0;
70  }
71  }
72
73  return DefWindowProcW(
74    hwnd, uMsg, wParam, lParam
75  );
76}

Beyond the volume of code and platform-specific knowledge required, there's a much bigger problem: all this code and knowledge is specific to Windows.

If you wanted to run this program on a Mac, you'd have to throw it all away and start again, learning and writing code for Apple's proprietary and similarly obtuse APIs. If you wanted to support Linux, Android, and iOS, you'd have to do it a third, fourth, and fifth time.

This is the fundamental problem of cross-platform development. The more your code relies on the specific details of one platform, the more work it is to port it to another.

This problem is solved by using some library that serves as a layer of indirection between our project-specfic code and the platform's native API. Instead of our code calling Windows, macOS, or Linux functions directly, it calls functions in this library. This library then translates our generic requests into the specific calls required by whatever platform it's currently running on.

This abstraction layer's job is to hide the platform-specific complexities from us. We can just say "create a window 800 pixels wide and 600 pixels tall", and it's the layer's responsibility to figure out how to do that.

Our code might be as simple as this:

1// This hypothetical library includes
2// a CreateWindow() function
3#include <SomeLibrary>
4
5int main() {
6  SomeLibrary::CreateWindow(800, 600);
7}

Behind the scenes, SomeLibrary::CreateWindow() would implement all the complexities we saw in our earlier example to translate this request into what the Windows API requires, or the macOS API, or what ever other platform we might be running on and which the library supports.

We could write this abstraction layer ourselves, but that's a huge task. Luckily, many brilliant people have already done the hard work for us. Many such libraries exist, and for this course, we'll be using one of the most popular and well-regarded: Simple DirectMedia Layer, or SDL.

SDL is a free, open-source, cross-platform development library that provides low-level access to audio, keyboard, mouse, joystick, and graphics hardware. It's written in C, works seamlessly with C++, and supports over 20 platforms at the time of writing.

This includes desktop platforms like Windows, macOS and Linux, mobile platforms like iOS and Android, and games consoles like PlayStation, Xbox and Nintendo Switch.

Whilst SDL can be used for creating a huge range of programs, it has seen huge adoption in the games industry in particular. At the time of writing, over 6,000 games on PC alone are using SDL.

At this point, you might be asking a very reasonable question: "If the goal is to make a game, why not just use a game engine like Unreal Engine or Godot?"

Modern game engines have already implemented all the core systems we need, they're often free, and can help you create visually impressive games much faster than you could from scratch. In an engine, you can often have a fully animated 3D character running around in a complex world in a matter of hours.

Building a game from scratch is a much slower, more methodical process. In this course, it can take a few hours just to learn how to draw a basic rectangle and render some text to the screen.

So why would you want to take the slow road? There are a few key advantages to learning the fundamentals before jumping into a high-level engine.

Learning C++

Working with a lower-level library like SDL forces you to engage directly with the C++ language. You'll have to manage memory, design your own data structures, and think carefully about how your objects interact.

When you use an engine, it provides its own way of doing things - its own classes, its own memory management model, and its own scripting languages (like Blueprints in Unreal). This hides the underlying C++ principles from you.

By building from the ground up, you'll gain a much deeper and more transferable understanding of C++.

Learning Low-Level Concepts

Game engines are massive abstractions. They hide almost all the low-level details of how a computer actually works. You don't need to know how a window is created, how input events are processed, or how to save and load data.

Learning from scratch exposes you to these concepts. You'll get a feel for how the different pieces of a game - the event loop, the renderer, the game state - fit together. This knowledge helps you understand why engines are designed the way they are, and it equips you to debug problems at a much deeper level.

Extending and Modifying Engines

For many small games, an off-the-shelf engine has almost everything the project needs and, when it doesn't, the project plan will be adjusted to fit within those constraints.

But for larger, more ambitious projects, it's very common for development teams to enhance the engine with new features or supporting tools, and to modify parts of the engine to work better for their specific needs.

By learning from the fundamentals, you're not just learning how to use a game engine; you're learning the skills and techniques that will let you extend or modify engines to your project's requirements.

Our goal in this course isn't just to teach you the SDL API. It's to use SDL as a vehicle to teach you C++ and the core principles of game architecture. The skills you learn here will be directly applicable whether you continue to build your own tools or transition to working entirely within the constraints of a prebuilt engine.

This lesson introduced the core problem that libraries like SDL are designed to solve. We saw how creating even a simple window requires writing complex, platform-specific code, making it difficult to write software that runs on multiple operating systems.

SDL provides a simple, cross-platform API that acts as an abstraction layer over the native operating system's functions. By writing our code to the SDL API, we can create applications that run on Windows, macOS, Linux, and many other platforms without changing our source code.

While game engines exist, learning to build games from scratch with a lower-level library like SDL provides a deeper understanding of both C++ and fundamental game development concepts.

Key takeaways from this lesson include:

• The Portability Problem: Writing code that directly uses a platform's native API (like the Win32 API) makes it non-portable to other platforms like macOS or Linux.
• Abstraction Layers: We can solve the portability problem by using an abstraction layer - a library that provides a common API and translates our requests into platform-specific calls.
• What SDL is: Simple DirectMedia Layer (SDL) is a popular, free, and open-source library that provides low-level, cross-platform access to graphics, sound, and input hardware.
• Why Learn Low-Level: Building from scratch with a library like SDL, rather than starting with a high-level game engine, provides a deeper understanding of C++ and the fundamental principles of game architecture, which are highly valuable and transferable skills.