Understanding Screen & World Space

1. Account for the different size: Scale vectors down by 50% to account for the screen space being half the size of the world space. This corresponds to moving positions 50% closer to the origin.
2. Account for the different coordinate system: Invert the y coordinates to account for the screen space’s y axis pointing in the opposite direction to the world space’s y axis.
3. Account for the the different origin: Increase y coordinates by 300 units (the height of the screen space) to account for the origin being at the top left of our screen space, rather than the bottom left. Given increasing y values corresponds to moving down in screen space, this step of our transformation will move (or "translate") our vectors down.

Let’s walk through this visually so we can better understand the logic we need to implement. First, let’s just place our characters in screen space, but using their world space coordinates without transformation. This helps us see the problem we need to solve:

The horizontal position of our dwarf has shifted slightly, whilst our dragon is not even on the screen.

Step 1: Accounting for the Different Size

Let’s apply the first step of our transformation, multiplying all of the position vectors by $0.5$. This scales them down to half of their current value, which is equivalent to moving them closer to the origin:

Step 2: Accounting for the Different Coordinate System

For step 2, we negate our objects’ vertical positions by multiplying their $y$ positions by $-1$. This moves them above the desired range and out of view, but we’ve made some progress - their positions relative to each other are now correct:

Step 3: Accounting for the Different Origin

Finally, we perform step 3 of our transformation. We increase their $y$ components by $300$ which, in the screen space coordinate system, corresponds to moving the objects down by 300 units*.* This places our objects in their final, correct position:

Implementing our transformation in code could look like this:

1Vec2 ToScreenSpace(const Vec2& Position) {
2  Vec2 ReturnValue{Position};
3  
4  // 1: Scale every component by 50%
5  ReturnValue *= 0.5;
6  
7  // 2: Invert the y component
8  ReturnValue.y *= -1;
9  
10  // 3. Increase the y component.  This corresponds to moving
11  // objects downwards in the screen space
12  ReturnValue.y += 300;
13  
14  return ReturnValue;
15}

Or, equivalently:

1Vec2 ToScreenSpace(const Vec2& Pos) {
2  return {
3    Pos.x * 0.5f,
4    (Pos.y * -0.5f) + 300
5  };
6}

Note that the ordering here is important. If we translated the vectors (step 3) before scaling and inverting the y axis (steps 1 and 2), then that translation would be done within the world space’s definition of y.

We can order it in that way if we want, but it means that our translation logic would need to be adjusted. For our example spaces, we could move objects down by equivalent amounts either by decreasing y values by 600 units in world space or by increasing y values by 300 units in screen space.

Whichever approach we use, we can transform some test points to ensure our logic is correctly mapping world space positions to equivalent screen space positions:

1#include <iostream>
2#include "Vec2.h"
3
ToScreenSpace Function (Unchanged)|Show
4 Vec2 ToScreenSpace(Vec2&) {/*...*/}
11
12int main() {
13  // A position in the center of
14  // the 1400x600 world space...
15  Vec2 P{700.0, 300.0};
16
17  // ...transformed to the center
18  // of the 700x300 screen space
19  std::cout << "[SCREEN SPACE]";
20  std::cout << "\nCenter:       "
21    << ToScreenSpace(P);
22
23  std::cout << "\nBottom Left:  "
24    << ToScreenSpace({0, 0});
25  std::cout << "\nTop Left:     "
26    << ToScreenSpace({0, 600});
27  std::cout << "\nBottom Right: "
28    << ToScreenSpace({1400, 0});
29  std::cout << "\nTop Right:    "
30    << ToScreenSpace({1400, 600});
31}

1[SCREEN SPACE]
2Center:       { x = 350, y = 150 }
3Bottom Left:  { x = 0, y = 300 }
4Top Left:     { x = 0, y = 0 }
5Bottom Right: { x = 700, y = 300 }
6Top Right:    { x = 700, y = 0 }

Advanced: Transformation Matrices

In higher budget games, these transformations tend to be implemented using transformation matrices and matrix multiplication - concepts from linear algebra. Linear algebra is the formal field of mathematics that studies vectors, spaces, and their transformations.

The linear algebra approach is more advanced, so we don’t cover it in detail in this course - we’ll continue to perform our transformations using regular C++ logic.

However, we’ll briefly introduce the alternative approach in this section, and we’ll also provide an additional, optional, lesson at the end of the chapter that goes a little deeper. That additional lesson will also implement these concepts using help from GLM, a popular library that provides math utilities for working with computer graphics.

The objectives and underlying theory of why we’re performing the transformations remain the same whichever approach we use - they key difference is the low-level mechanics of how the transformation is performed. Rather than creating a function to define the transformation, we can instead define a matrix - a two-dimensional grid of numbers that represents the transformation mathematically.

For example, we created a ToScreenSpace() function in the previous section, which defines a 2D transformation. It also provides the mechanism to perform that transformation - by calling the function with a position vector:

1// Define the transformation
2Vec2 ToScreenSpace(const Vec2& Pos) {
3  return {
4    Pos.x * 0.5f,
5    (Pos.y * -0.5f) + 300
6  };
7}
8
9// Perform the transformation
10ToScreenSpace({700.0, 300.0});

That same transformation can be defined using a matrix as follows:

We typically use a math library that help with this, ensuring the desired transformation is correctly represented by positioning appropriate values in appropriate positions within the matrix. We’ll cover this in more detail in our later lesson.

We can use this matrix to transform individual vectors, or we can arrange many vectors into a single matrix, where each vector is a column.

To make our vectors compatible with the transformation process, we need to add an additional component to them. So, for a 2D vector, we’d add a third component. This component has a value of $1$ if the vector represents a position and $0$ otherwise.

The five vectors we transformed in our previous example could be arranged in the following matrix:

Performing the transformation is then done by a matrix multiplication, a process that we again typically enlist the help of 3rd party library to implement, and we’ll cover in more detail later.

Matrix transformation involves multiplying our transformation matrix by the matrix of column vectors we want to transform:

The result of this multiplication is a matrix where each of our column vectors has been transformed:

Comparing this to our earlier program using the ToScreenSpace() function, we should see both approaches have the same effect:

1Positions   World Space -> Screen Space
2Center:      (700, 300) -> (350, 150)
3Bottom Left:     (0, 0) -> (0, 300)
4Top Left:      (0, 600) -> (0, 0)
5Bottom Right: (1400, 0) -> (700, 300)
6Top Right:  (1400, 600) -> (700, 0)

The matrix approach has a few advantages:

• We don’t need to write functions for our transformations, which saves time. Whilst our function was quite simple, transformations can get a lot more complex, especially when working with 3D spaces. Matrix techniques provide a general way to quickly create and represent transformations, including those that have rotations, scalings, shearings, and more.
• Much like vector math, the rules of matrix math have useful properties that can help us solve complex problems. For example, if we have multiple transformations represented as matrices, we can combine their effects to a single transformation by multiplying those matrices together.
• Computer hardware, especially the graphics processing unit (GPU), is highly optimized for performing matrix multiplication operations. This means that these approaches are typically more performant than providing our transformations as regular C++ functions.

Discrete and Continuous Spaces

When we write code that positions and moves objects through spaces using floating point numbers, we have to consider the fact that, unlike discrete integers, floating point numbers are continuous.

• Discrete numbers, such as those represented by an int, can only take one of a specific set of values. For example, there are only two possible integers between $2$ and $5$ - the integers $3$ and $4$
• Continuous numbers, such as those represented by a float, can potentially take any value. For example, there are conceptually endless floating point numbers between $2$ and $5$, with values such as $2.4$, $2.41$, and $2.40000001$.

These concepts extend to spaces too. For example:

• An SDL_Surface is a discrete space, as there are a limited number of possible positions within the space. Each possible position is represented by an x and y integer and corresponds to a pixel on the surface.
• World space is typically set up as continuous, where we use floating-point numbers to represent a conceptually endless range of possible positions in the space. This gives us, or the simulations we create, the ability to control objects’ positions and movements much more accurately.

One implication of working with continuous spaces is that we need to become accustomed to working with approximations. Even though we tend to think of floating point numbers as having simple values like $2.4$, we shouldn’t expect to be handling such well-rounded numbers in a continuous space. A value in such a space is just as likely to be $2.400000317$ as it is to be exactly $2.4$.

Floating Point Comparisons

The main scenario in which we need to be aware of the inherent approximations of continuous values and work around them is when we’re trying to do equality comparisons.

For example, our gameplay logic might need to determine whether two objects are in the same position, so it might seem reasonable to write a check like this:

1struct Object{
2  Vec2 Position;
3}
4
5bool IsInSamePosition(Object& A, Object& B) {
6  return A.Position.x == B.Position.x
7    && A.Position.y == B.Position.y; 
8}

However, when our objects are being simulated in a continuous space using floating point numbers, it’s very unlikely that their positions would be exactly equal. As such, an equality comparison using == will almost always return false, even if the object positions are so similar we would want to consider them as being equal for our simulation or gameplay needs.

For example, the numbers 2.39999958 and 2.40000031 are not entirely equal. However in most contexts, including computer graphics, we’d consider them close enough to be treated as equal. Therefore, we need to create alternatives to the == and != operators that check if objects are "close enough".

The common way of doing this is creating a function that accepts our two objects, and returns true if the difference between them is sufficiently small. This "sufficiently small" tolerance level is sometimes offered as a third argument with a default value, allowing users of the function to specify how small the difference between the values must be for them to be considered equal.

The following is an example of such a function that compares float objects, and an overload that uses similar concepts for comparing Vec2 objects. If it’s unclear why we’re using std::abs() here, we cover that in the next section:

1#include <cmath> // For std::abs
2
3// For Float Comparison
4bool NearlyEqual(float A, float B,
5                 float Tolerance = 0.00001) {
6  return std::abs(A - B) < Tolerance;
7}
8
9// For Vec2 Comparison
10bool NearlyEqual(const Vec2& A, const Vec2& B,
11                 float Tolerance = 0.00001) {
12  return std::abs(A.x - B.x) < Tolerance
13    && std::abs(A.y - B.y) < Tolerance;
14}

Our NearlyEqual() function would replace the == and != operators as follows:

1if (A == B) {/*...*/} 
2if (NearlyEqual(A, B)) {/*...*/} 
3
4if (A != B) {/*...*/} 
5if (!NearlyEqual(A, B)) {/*...*/}

A similar rationale applies to other comparisons, such as <= and <. For example, if A and B are approximately equal, we may not want to consider A to be meaningfully smaller than B even if A < B is technically true.

As such, we may also need to implement alternatives to these operators that make this distinction, should we ever need such logic. However, in practice, this is much less important than the == and != alternatives.

1#include <iostream>
2
3int main() {
4  if (0.1 + 0.2 == 0.3) {
5    std::cout << "Obviously equal";
6  } else {
7    std::cout << "Somehow not equal";
8  }
9}

1Somehow not equal

1#include <iostream>
2
NearlyEqual Function (Unchanged)|Show
3bool NearlyEqual(float, float){/*...*/}
8
9int main() {
10  if (NearlyEqual(0.1 + 0.2, 0.3)) {
11    std::cout << "Obviously equal";
12  } else {
13    std::cout << "Somehow not equal";
14  }
15}

1Obviously equal

Vectors and Absolute Values

This previous code is an example where we use the concept of an absolute value, which we can revisit briefly here as it has some renewed meaning in the context of vectors.

As a reminder, we can consider taking the absolute value of a number to be removing that number’s negative component, if it has one.

For example, the absolute value of $-3$ is $3$. If a number is not negative, the absolute value is the same as the number itself, so the absolute value of $3$ is $3$.

To get the absolute value of an expression in C++, we can use std::abs() within the <cmath> standard library or, alternatively, SDL_abs() if we’re using SDL:

1#include <iostream>
2#include <cmath> // For std::abs
3#include <SDL.h> // For SDL_abs
4
5int main() {
6  float A{3};
7  float B{-3};
8
9  std::cout << "A: " << A;
10  std::cout << ", abs(A): " << std::abs(A);
11
12  std::cout << "\nB: " << B;
13  std::cout << ", abs(B): " << SDL_abs(B);
14}

1A: 3, abs(A): 3
2B: -3, abs(B): 3

In our NearlyEqual() function, we’re using the absolute value to make the argument order of $A$ and $B$ unimportant. $A - B$ is not necessarily the same as $B - A$, but the absolute values of $A - B$ and $B - A$ will be the same:

1#include <iostream>
2#include <cmath> // For std::abs
3
4int main() {
5  float A{1.001};
6  float B{0.999};
7
8  using std::abs;
9  std::cout << "A - B:    " << A - B;
10  std::cout << "\nB - A:    " << B - A;
11  std::cout << "\nabs(A-B): " << abs(A - B);
12  std::cout << "\nabs(B-A): " << abs(B - A);
13}

1A - B:    0.00200003
2B - A:    -0.00200003
3abs(A-B): 0.00200003
4abs(B-A): 0.00200003

Conceptually, we can imagine an expression like abs(A - B) calculating the distance between A and B, without caring about the direction. In mathematical notation, the absolute value of a number is represented by vertical bars, for example:

This vertical bar notation is the same one we use when referencing the magnitude of a vector, as in $\lvert V \rvert$, because they’re fundamentally the same idea. The absolute value of some number, $\lvert x \rvert$, is how far away that number is from $0$, whilst the magnitude of some two-dimensional vector, $\lvert (x, y) \rvert$, is how far away that vector is from $(0, 0)$ - the origin.

We can even consider a number like $-3$ to be a one-dimensional vector in a one-dimensional space, which makes the similarity even more obvious. A one-dimensional space is simply a number line:

Continuous to Discrete Conversions

After we’ve run our simulation and calculated the position of all the objects in our continuous world space, we’ll often need to transform these vectors to equivalent positions in a discrete space. For example, the screen space representation using SDL_Surface is discrete - there is a fixed quantity of pixels on our surface, represented by integers.

We cover how to implement this full world space to screen space pipeline in the next chapter, but for now, we should note that converting a floating point number directly to an integer would remove the floating point component. This is generally less accurate than we’d like - for example, it results in $3.8$ being converted to $3$, even though it’s closer to $4$:

1#include <iostream>
2
3int main() {
4  std::cout << "Converting 3.8 to int: "
5    << static_cast<int>(3.8);
6}

1Converting 3.8 to int: 3

To fix this, we can explicitly round our floating point numbers to the nearest integer. We can do this using std::round() from <cmath>, or SDL_round() if we’re using SDL:

1#include <iostream>
2
3#include <cmath> // For std::round
4#include <SDL.h> // For SDL_round
5
6int main() {
7  std::cout << "Rounding 3.8 to int: "
8    << std::round(3.8);
9  std::cout << "\nRounding 3.8 to int: "
10    << SDL_round(3.8);
11}

1Rounding 3.8 to int: 4
2Rounding 3.8 to int: 4

In the following example, we incorporate this rounding into our transformation function from world space to screen space. This ensures our Vec2 components are integer values:

1#include <cmath> // For std::round
2
3Vec2 ToScreenSpace(const Vec2& Pos) {
4  return {
5    std::round(Pos.x * 0.5f),
6    std::round((Pos.y * -0.5f) + 300)
7  };
8}

Even though these values are now integers, they are being stored in float containers - the x and y variables of our Vec2 type. This is not necessarily a problem as almost every implementation of the float type uses the IEEE 754 standard, which can accurately represent integer values without any loss of precision.

Preserving the floating point type in screen space is also useful if we need to perform further transformations within that space, and having access to floating-point accuracy would be helpful in that work.

In such cases, we’d also want to hold off on rounding our values to integers until we complete those transformations. We don’t want to round our values multiple times, as each rounding has a performance cost and may also represent a loss of data/accuracy.

Summary

In more complex games, objects are typically simulated in the world space, which has different properties to the screen space. To render our object, we need to derive their screen space position based on their world space position. The key takeaways from this lesson are:

• Screen space uses pixel coordinates with the origin at the top-left corner, while world space typically uses floating-point coordinates with various possible origins.
• When transforming between spaces, we must account for differences in scale, coordinate system orientation, and origin position.
• Transformations can be implemented as direct functions or using transformation matrices for more complex operations.
• Floating-point numbers require special considerations when comparing values or converting to integer pixels.
• We should be extremely cautious with using the == and != operators with floating point numbers. It’s usually the case that we should consider floating point values to be equivalent if their difference is very small, but not necessarily $0$.
• Converting floating point numbers to integers directly often results in loss of accuracy, as that action just discards the floating point component, effectively always rounding down. We typically want to round them to the nearest integer instead.