When developing games, we need a way to represent our virtual world and then transform it to display on a screen

In this lesson, we'll create a complete scene system that lets us position game objects using world coordinates, and then automatically converts those positions to screen coordinates when rendering.

We'll be using the Vec2 struct we created in the previous chapter, as well as Window and Image classes using techniques we covered earlier in the course. A complete version of these are available below:

Scenes

Let's create a class that we can use to represent scenes defined in world space. We'll first create a class for objects that can exist in our scene. As usual, we'll provide it with HandleEvent(), Tick() and Render() methods so it can interact with the rest of our game:

1// GameObject.h
2#pragma once
3#include <SDL.h>
4
5class GameObject {
6 public:
7  void HandleEvent(SDL_Event& E) {}
8  void Tick() {}
9  void Render(SDL_Surface* Surface) {}
10};

We'll give them an Image which they can render to our window surface, and a Vec2 to store their position:

1// GameObject.h
2#pragma once
3#include <SDL.h>
4#include "Vec2.h"
5#include "Image.h"
6
7class GameObject {
8 public:
9  GameObject(const std::string& ImagePath,
10    const Vec2& InitialPosition)
11  : Image{ImagePath},
12    Position{InitialPosition}{}
13    
14  void HandleEvent(SDL_Event& E) {}
15  void Tick() {}
16  void Render(SDL_Surface* Surface) {
17    Image.Render(Surface, Position);
18  }
19
20 private:
21  Vec2 Position;
22  Image Image;
23};

Conceptually, we can create a scene representation in much the same way we've created any other manager-style class. The basic foundations involve storing the collection of the objects it manages, typically in an array such as a std::vector.

1#pragma once
2#include <vector>
3#include "GameObject.h"
4
5class Scene {
6private:
7  std::vector<GameObject> Objects;
8};

We then notify those objects of events and instruct them to tick and render at the appropriate times:

1#pragma once
2#include <SDL.h>
3#include <vector>
4#include "GameObject.h"
5
6class Scene {
7public:
8  void HandleEvent(SDL_Event& E) {
9    for (GameObject& Object : Objects) {
10      Object.HandleEvent(E);
11    }
12  }
13
14  void Tick() {
15    for (GameObject& Object : Objects) {
16      Object.Tick();
17    }
18  }
19
20  void Render(SDL_Surface* Surface) {
21    for (GameObject& Object : Objects) {
22      Object.Render(Surface);
23    }
24  }
25
26private:
27  std::vector<GameObject> Objects;
28};

In our main function, we'll construct our Window and Scene, and connect everything together in an application loop:

1#include <SDL.h>
2#include "Window.h"
3#include "Scene.h"
4
5int main(int argc, char** argv) {
6  SDL_Init(SDL_INIT_VIDEO);
7  Window GameWindow;
8  Scene GameScene;
9
10  SDL_Event Event;
11  while (true) {
12    while (SDL_PollEvent(&Event)) {
13      GameScene.HandleEvent(Event);
14      if (Event.type == SDL_QUIT) {
15        SDL_Quit();
16        return 0;
17      }
18    }
19
20    // Tick
21    GameScene.Tick();
22
23    // Render
24    GameWindow.Render();
25    GameScene.Render(GameWindow.GetSurface());
26
27    // Swap
28    GameWindow.Update();
29  }
30
31  return 0;
32}

Rendering Scenes

In the previous lesson, we worked with the example scene illustrated below. The top shows the positions in world space, with the bottom showing the corresponding positions in screen space:

Diagram showing our characters in world space and screen space

Let's add the two objects to our scene. As a quick test, we'll initially set their positions directly in screen space to confirm everything we've done so far works:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  Scene() {
7    Objects.emplace_back("dwarf.png", Vec2{50, 200});
8    Objects.emplace_back("dragon.png", Vec2{400, 50}); 
9  }
10  
11  // ...
12};

Drawing Debug Helpers

When we're working on a more complex project that will take longer to build, it is usually worthwhile to invest some upfront effort creating utilities that will help us build and debug.

Something that's often useful is to have our objects render additional information to the screen so we can quickly understand what is going on behind the scenes.

This content is only rendered when developers need to see it, so it is typically turned on or off based on a preprocessor definition. For example, we could selectively define a DRAW_DEBUG_HELPERS directive in some location that is accessible to all of our files:

1// Config.h
2#define DRAW_DEBUG_HELPERS

We could then have our objects draw additional information when this directive is defined. In this example, we update our GameObject instances to render a small rectangle centered at their Position:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void Render(SDL_Surface* Surface) {
8    Image.Render(Surface, Position);
9#ifdef DRAW_DEBUG_HELPERS
10    SDL_Rect PositionIndicator{
11      int(Position.x) - 10,
12      int(Position.y) - 10,
13      20, 20};
14    SDL_FillRect(
15      Surface, &PositionIndicator,
16      SDL_MapRGB(Surface->format, 220, 0, 0)
17    );
18#endif
19  }
20  // ...
21};

If we were planning on working on this project for a longer time, it could be warranted to expand this even more. For example, we might want to upgrade this to render the exact position of our objects as text using SDL_ttf.

Working in World Space

This looks good, however, we want to work in world space, not screen space. Let's update the positions of the objects in our scene to their world space coordinates:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  Scene() {
7    Objects.emplace_back("dwarf.png", Vec2{100, 200});
8    Objects.emplace_back("dragon.png", Vec2{800, 500});
9  }
10  
11  // ...
12};

Screenshot showing our rendered scene with using world space coordinates in screen space

This looks less good, so we need to implement the world space to screen space transformation we designed in the previous lesson.

In our simple 2D games, the process for doing this will be quite easy. Later in the course, we'll demonstrate a more elaborate pipeline that outlines what this process looks like in a complex, 3D game.

As with anything in programming, there are countless ways we can set this up. We can scale our implementation up as our needs get more complex, but it's best to keep things as simple as possible for as long as possible.

A simple implementation might involve adding the transformation logic to our Scene object. For now, we'll assume our screen space and world space are the same as the example we worked through in the previous lesson. As such, we'll use the same transformation function we created in that lesson:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  Vec2 ToScreenSpace(const Vec2& Pos) const {
7    return {
8      Pos.x * 0.5f,
9      (Pos.y * -0.5f) + 300
10    };
11  }
12  // ...
13};

For our objects to access this function, we need to provide them with a reference to the Scene they're part of. We can do that through the constructor and save it as a member variable, or pass it to each Render() invocation. We'll go with the constructor approach and have our Scene pass a reference to itself using the this pointer:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  Scene() {
7    Objects.emplace_back("dwarf.png", Vec2{100, 200}, *this);  
8    Objects.emplace_back("dragon.png", Vec2{800, 500}, *this);
9  }
10  // ...
11};

Let's update our GameObject constructor to accept this Scene reference. However, because our Scene.h header is already including GameObject.h, we should be cautious with having GameObject.h also include Scene.h. This would result in a circular dependency.

Instead, within GameObject.h, we can forward-declare the Scene class:

1// GameObject.h
2// ...
3
4class Scene;
5
6class GameObject {
7// ...
8 private:
9   // ...
10  const Scene& Scene;
11};

Finally, let's update our Render() function to ensure our world space Position variable is converted to screen space for rendering. Given we've only forward-declared the Scene type rather than including the header, Scene will be an incomplete type in this file. That means we can't access the ToScreenSpace() function.

To solve this, we can move our Render() definition to a standalone implementation file. That .cpp file can #include the full declaration of both Scene and GameObject, meaning we can send our Position vector through the Scene.ToSceenSpace() transformation function:

1// GameObject.cpp
2#include "GameObject.h"
3#include "Scene.h"
4
5void GameObject::Render(SDL_Surface* Surface) {
6  Image.Render(Surface, Scene.ToScreenSpace(Position));
7}

We can now remove the definition of GameObject::Render() from the header file, and leave just the declaration:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  // Before - Full Definition:
8  void Render(SDL_Surface* Surface) {
9    Image.Render(Surface, Position);
10  }
11  
12  // After - Just the Declaration:
13  void Render(SDL_Surface* Surface);
14  
15  // ...
16};

Running our game, we should see the viewport transformation rendering objects in the correct position:

We now have an entirely different world space to work with in our scene, without the limitations of always needing to work in screen space.

Viewports and Clip Rectangles

So far, our program's rendering pipeline has assumed its output is covering the entire area of our window, but that's not necessarily the case. In a more complicated application, our rendering pipeline may only have access to a small portion of the available area. Other parts of the screen, such as UI elements, may be controlled by other parts of our program.

Diagram showing the design of an example program with a top menu and left sidebar

From the perspective of a renderer, the area of the screen it is rendering to is typically called it's viewport. For a renderer to transform its content correctly, it needs to be aware of this viewport's size, and where it is positioned on the screen.

In our examples, our rendering has involved performing blitting operations onto an SDL_Surface, typically the SDL_Surface associated with an SDL_Window. The area of an SDL surface that is available for blitting is called the clipping rectangle.

`SDL_GetClipRect()`

To get the clip rectangle of a surface, we create an SDL_Rect to receive that data. We then call SDL_GetClipRect(), passing a pointer to the surface we want to query, and a pointer to the SDL_Rect that the function will update:

1SDL_Rect ClipRect;
2
3SDL_GetClipRect(
4  SomeSurfacePointer,
5  &ClipRect
6);

By default, the clipping rectangle is the entire surface. Let's find out what the clipping rectangle is of our window's surface:

1#pragma once
2#include <iostream>
3#include <SDL.h>
4
5class Window {
6public:
7  Window() {
8    SDLWindow = SDL_CreateWindow(
9      "Scene",
10      SDL_WINDOWPOS_UNDEFINED,
11      SDL_WINDOWPOS_UNDEFINED,
12      700, 300, 0
13    );
14    
15    SDL_Rect ClipRect;
16    SDL_GetClipRect(
17      SDL_GetWindowSurface(SDLWindow),
18      &ClipRect
19    );
20
21    std::cout << "x = " << ClipRect.x
22      << ", y = " << ClipRect.y
23      << ", w = " << ClipRect.w
24      << ", h = " << ClipRect.h;
25  }
26  
27  // ...
28};

1x = 0, y = 0, w = 700, h = 300

This is perhaps not surprising, as we've likely noticed that our objects can render their content to any part of the window's surface. But, this is not true in general. The clipping rectangle can be changed to only cover a part of the surface.

`SDL_SetClipRect()`

To change a surface's clipping rectangle, we call SDL_SetClipRect(), passing a pointer to the SDL_Surface, and a pointer to an SDL_Rect representing what we want the new rectangle to be.

Below, we update the clipping rectangle so only the bottom-right of our window is available to our renderer:

1#pragma once
2#include <iostream>
3#include <SDL.h>
4
5class Window {
6public:
7  Window() {
8    SDLWindow = SDL_CreateWindow(
9      "Scene",
10      SDL_WINDOWPOS_UNDEFINED,
11      SDL_WINDOWPOS_UNDEFINED,
12      700, 300, 0
13    );
14    
15    SDL_Rect ClipRect{100, 30, 600, 270};
16    SDL_SetClipRect(
17      SDL_GetWindowSurface(Window),
18      &ClipRect
19    );
20  }
21    
22  // ...
23};

This means that future blitting operations cannot overwrite the left 100 columns of pixels, and the top 30 rows:

Screenshot showing our scene with the top and left excluded from the clip rectangle

If we want to set the clip rectangle back to the full area of the surface, we can pass a nullptr to SDL_SetClipRect():

1SDL_GetClipRect(
2  SDL_GetWindowSurface(Window),
3  nullptr
4);

Note that the SDL_Surface associated with an SDL_Window is destroyed and recreated when the window is resized. As such, if our program is applying a clip rectangle to that surface, we need to listen for window resize events and recalculate and reapply our clip rectangle when they happen.

Dynamic Transformations

It is rarely the case that our transformations are fully known at the time we write our code. They are usually include variables that are not known at compile time. In the next lesson, we'll implement the most obvious example of this - we'll add a player-controllable camera, which determines which part of our world gets displayed on the screen on any given frame.

Even now, our simple transformation is a little more static than we'd like. It assumes the size of our viewport is exactly 700x300. If we wanted to let the user resize our window, or if we wanted our window to go full screen, we need to make our transformation function a little smarter by supporting dynamic viewport sizes.

Each invocation of our Render() function is being provided with the pointer to the SDL_Surface. We can retrieve the clip rectangle associated with that surface, and use it to update a member variable in our Scene:

1// Scene.h
2// ...
3
4class Scene {
5// ...
6private:
7  // ...
8  SDL_Rect Viewport;
9};

Note that, because this Viewport value is eventually going to control how objects in our scene are to be transformed to view space, it's important that we update it before we render those objects:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  // ...
7  void Render(SDL_Surface* Surface) {
8    SDL_GetClipRect(Surface, &Viewport);
9    for (GameObject& Object : Objects) {
10      Object.Render(Surface);
11    }
12  }
13  // ...
14};

We'll now update our ToScreenSpace() transformation to no longer assume we need to transform positions to a 700x300 space. Instead, we'll calculate the values dynamically based on our viewport size:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  // Before:
7  Vec2 ToScreenSpace(const Vec2& Pos) {
8    return {
9      Pos.x * 0.5f,
10      (Pos.y * -0.5f) + 300
11    };
12  }
13  
14  // After:
15  Vec2 ToScreenSpace(const Vec2& Pos) {
16    auto[vx, vy, vw, vh]{Viewport};
17    float HorizontalScaling{vw / WorldSpaceWidth};
18    float VerticalScaling{vh / WorldSpaceHeight};
19    
20    return {
21      vx + Pos.x * HorizontalScaling,
22      vy + (WorldSpaceHeight - Pos.y) * VerticalScaling
23    };
24  }
25  
26private:
27  float WorldSpaceWidth{1400};
28  float WorldSpaceHeight{600};
29  // ...
30};

Now, our transformation only assumes that our world space spans from (0, 0) to (1400, 600) and that, compared screen space, the $y$ axis is inverted. These are valid assumptions, as these characteristics are known at compile-time, and they do not change at run-time.

To test our new transformation function, we can make our window resizable using the SDL_WINDOW_RESIZABLE flag, or the SDL_SetWindowResizable() function:

1// Create a resizable window
2SDL_Window* Window{SDL_CreateWindow(
3  "My Game",
4  SDL_WINDOWPOS_UNDEFINED,
5  SDL_WINDOWPOS_UNDEFINED,
6  700, 300,
7  SDL_WINDOW_RESIZABLE 
8)};
9
10// Update an existing window to be resizable
11SDL_SetWindowResizable(Window, SDL_TRUE);

If we did everything correctly, our objects should now render in the correct position whilst respecting both the window size and the clip rectangle of the surface they're rendering to:

Screenshot showing our scene compensating for the reduced clip rectangle

Transformations in Complex Games

In the basic objects we're managing in this chapter, the transformation from world space to screen space is only being applied to a single vector - the Position variable of our GameObject class. This variable defines where the top-left corner of where our Image will be rendered.

In this course, those images are stored as SDL_Surface objects. Those image surfaces already use the same coordinate system as the SDL_Window surface representing our screen space, so their individual pixels do not need to be transformed.

If we wish, we could expand our GameObject class with additional position data - for example, the location of the bottom-right corner of the image. We could then send this variable through our transformation function, and use the result to control the scaling of our image.

In a more complex games, particularly 3D games, an object can have thousands or even millions of positions defined in world space. Most notably, those are the positions of the vertices used to represent the three-dimensional shape of that object:

Image Credit: ACM SIGARCH

As such, there are significantly more transformations required in a typical 3D game, but the logic is fundamentally the same. We just have many more points to transform and, in the case of a 3D game, each point has a third component to represent its position in that third dimension.

We introduce the 3D transformation pipeline in a bit more detail later in the course.

Serializing and Deserializing Scenes

A large number of tools are typically involved in creating complex games. For example, part of a scene might be created in a 3D modeling program, imported into a different tool for painting, a third tool for animation, and a fourth tool (the game engine) for rendering.

As such, interopability between these tools is an important feature, and relies on the serialization and deserialization techniques we covered earlier. One program outputs its representation of the scene as a file, and then the other program reads, understands, and deserializes that data into it's representation.

One of the challenges involved is the huge range of ways scenes can be represented, with each program using their own format rather than conforming to a standard convention. Efforts are in progress to create and drive adoption of more standardised ways to representing scenes, similar to how jpeg and png are standard and widely adopted ways of representing images.

The Universal Scene Description (USD) format has seen the most success, and is becoming increasingly available across our tools.

Complete Code

Complete versions of our Scene and GameObject classes are below:

Summary

In this lesson, we've implemented a scene management system that bridges the gap between world space (where our game logic lives) and screen space (where rendering happens).

Our system automatically transforms coordinates between these spaces and adapts to changing viewport dimensions. Key takeaways:

Separating world space from screen space creates more flexible, maintainable game code
Scene classes provide organization and management for collections of game objects
Transformation functions convert world coordinates to screen space for rendering
Dynamic viewport handling ensures our scene renders correctly at any window size
Forward declarations help avoid circular dependencies in our class design
Clip rectangles control which parts of the window surface are available for rendering
Debug visualization tools make it easier to understand complex coordinate transformations

Scene Rendering