**tutorial**

# Math for Game Programmers 05 – Vector Cheat Sheet

This is the long due fifth article in this series. If you aren’t comfortable with vectors, you might want to take a look at the first four articles in this series before: Introduction, Vectors 101, Geometrical Representation of Vectors, Operations on Vectors.

This cheat sheet will list several common geometrical problems found in games, and how to solve them with vector math.

# The guide to implementing 2D platformers

Having previously been disappointed by the information available on the topic, this is my attempt at categorizing different ways to implement 2D platform games, list their strengths and weaknesses, and discuss some implementation details.

The long-term goal is to make this an exhaustive and comprehensible guide to the implementation of 2D platform games. If you have any sort of feedback, correction, request, or addition – please leave it in the comments!

**Disclaimer**: some of the information presented here comes from reverse engineering the behavior of the game, not from its code or programmers. It’s possible that they are not ACTUALLY implemented in this way, and merely behave in an equivalent way. Also note that tile sizes are for the game logic, graphical tiles might be of a different size.

# Four Ways of Implementing

I can think of four major ways in which a platform game can be implemented. From simplest to most complicated, they are:

## Type #1: Tile-based (pure)

Character movement is limited to tiles, so you can never stand halfway between two tiles. Animations may be used to create the illusion of smooth movement, but as far as the game logic is concerned, the player is always right on top of a specific tile. This is the easiest way to implement a platform game, but it imposes heavy restrictions on the control of character, making it unsuitable for traditional action-based platformers. It is, however, popular with puzzle and “cinematographic” platformers.

*Flashback, shown with tile boundaries*

Examples: Prince of Persia, Toki Tori, Lode Runner, Flashback

**How it works**

The map is a grid of tiles, each one storing information such as whether it’s an obstacle or not, what image to use, what kind of footstep sound to use, and so on. The player and other characters are represented by a set of one or more tiles that move together. In Lode Runner, for example, the player is a single tile. In Toki Tori, the player is 2×2 tiles. In Flashback, which is unusual due to the smaller size of its tiles, the player is two tiles wide and five tiles tall (see image above) when standing, but only three tiles tall when crouching.

In this kind of game, the player will rarely – if ever – be moving diagonally, but, if he is, the movement can be decomposed in two separate steps. Likewise, he will likely only move one tile at once, but multi-tile movement can be done as multiple steps of one tile, if needed (in Flashback, you always move two tiles at once). The algorithm is then as follows:

- Create a copy of the character where he’d like to move to (e.g., if moving one tile to the right, make a copy where every tile of the character is shifted 1 tile to the right)
- Check that copy for intersection with the background and other characters.
- If an intersection is found, the character’s movement is blocked. React accordingly.
- Otherwise, the path is clear. Move character there, optionally playing an animation so the transition looks smooth.

This kind of movement is very ill-suited for traditional arc-shaped jumps – so games in this genre often have no jump at all (Toki Tori, Lode Runner), or only allow vertical or horizontal jumps (Prince of Persia, Flashback), which are nothing but special cases of linear movement.

Advantages of this system include simplicity and precision. Since the games are more deterministic, glitches are much less likely, and the gameplay experience is more controlled, with less of a need to tweak values depending on circumstances. Implementing certain mechanics (such as grabbing ledges and one-way platforms) becomes a breeze, compared to more complex movement styles – all you have to do is check whether the player tiles and the background tiles are aligned in the one specific way that allows for a given action.

In principle, this system doesn’t allow steps of less than one tile, but that can be mitigated in a few different ways. For example, the tiles can be a bit smaller than the player (say, a player is 2×6 tiles), or you can allow a visual-only movement to take place inside a given tile, without affecting the logic (which is the solution that I believe that “Lode Runner – The Legend Returns” takes).

## Type #2: Tile Based (Smooth)

Collision is still determined by a tilemap, but characters can move freely around the world (typically with 1px resolution, aligned to integers, but see the note at the end of article regarding smoothing of movement). This is the most common form of implementing platformers in 8-bit and 16-bit consoles, and remains popular today, as it is still easy to implement and makes level editing simpler than more sophisticated techniques. It also allows for slopes and smooth jump arcs.

If you’re unsure which type of platformer you want to implement, and you want to do an action game, I suggest going for this one. It’s very flexible, relatively easy to implement, and gives you the most control of all four types. It’s no wonder that the majority of the best action platformers of all time are based on this type.

*Mega Man X, shown with tile boundaries and player hitbox.*

Examples: Super Mario World, Sonic the Hedgehog, Mega Man, Super Metroid, Contra, Metal Slug, and practically every platformer of the 16-bit era

### How it works

Map information is stored in the same way as with the pure tile technique, the difference is merely in how the characters interact with the background. The character’s collision hitbox is now an Axis-Aligned Bounding Box (AABB, that is, a rectangle that cannot be rotated), and are typically still an integer multiple of tile size. Common sizes include one tile wide and one (small Mario, morph ball Samus), two (big Mario, Mega Man, crouched Samus) or three (standing Samus) tiles tall. In many cases, the character sprite itself is larger than the logical hitbox, as this makes for a more pleasant visual experience and fairer gameplay (it’s better for the player to avoid getting hit when he should have than for him to get hit when he should not have). In the image above, you can see that the sprite for X is square-ish (in fact, is two tiles wide), but his hitbox is rectangular (one tile wide).

Assuming that there are no slopes and one-way platforms, the algorithm is straightforward:

- Decompose movement into X and Y axes, step one at a time. If you’re planning on implementing slopes afterwards, step X first, then Y. Otherwise, the order shouldn’t matter much. Then, for each axis:
- Get the coordinate of the forward-facing edge, e.g. : If walking left, the x coordinate of left of bounding box. If walking right, x coordinate of right side. If up, y coordinate of top, etc.
- Figure which lines of tiles the bounding box intersects with – this will give you a minimum and maximum tile value on the OPPOSITE axis. For example, if we’re walking left, perhaps the player intersects with horizontal rows 32, 33 and 34 (that is, tiles with y = 32 * TS, y = 33 * TS, and y = 34 * TS, where TS = tile size).
- Scan along those lines of tiles and towards the direction of movement until you find the closest static obstacle. Then loop through every moving obstacle, and determine which is the closest obstacle that is actually on your path.
- The total movement of the player along that direction is then the minimum between the distance to closest obstacle, and the amount that you wanted to move in the first place.
- Move player to the new position. With this new position, step the other coordinate, if still not done.

### Slopes

Slopes (the tiles pointed by green arrows on the image above) can be very tricky, because they are obstacles, and yet still allow the character to move into their tile. They also cause movement along the X axis to adjust position on the Y axis. One way to deal with them is to have the tile store the “floor y” of either side. Assuming a coordinate system where (0, 0) is at top-left, then the tile just left of X (first slope tile) is {0, 3} (left, right), then the one he stands on is {4, 7}, then {8, 11}, then {12, 15}. After that, the tiles repeat, with another {0, 3}, etc, and then we have a steeper slope, composed of two tiles: {0, 7} and {8, 15}.

The system that I’m going to describe allows arbitrary slopes, though for visual reasons, those two slopes are the most common, and result in a total of 12 tiles (the 6 described previously, and their mirrorings). The collision algorithm changes as follows for horizontal movement:

- Make sure that you step X position before Y position.
- During collision detection (4 above), the slope only counts as a collision if its closest edge is the taller (smaller y coordinate) one. This will prevent characters from “popping” through the slope from the opposite side.
- You might want to forbid slopes to stop “halfway through” (e.g. on a {4, 7} tile). This restriction is adopted by Mega Man X and many other games. If you don’t, you have to deal with the more complicated case of the player attempting to climb from the lower side of the slope tile – one way to deal with this is to pre-process the level, and flag all such offending tiles. Then, on collision detection, also count it as a collision from the lower side if the player’s lowest y coordinate is greater (that is, below) the tile’s offset edge (tile coord * tile size + floor y).
- A full obstacle tile adjacent to the slope the character is currently on should not be considered for collision if it connects to the slope, that is, if the character (that is, his bottom-center pixel) is on a {0, *} slope, ignore left tile, and, if on a {*, 0} slope, ignore the right tile. You may have to do this for more tiles if your character is wider than two tiles – you might simply skip checking on the entire row if the player is moving towards the upper side of slope. The reason for this is to prevent the character from getting stuck at those tiles (highlighted yellow above) while still climbing the slope, as his foot will still be below the “surface level” by the time he comes into contact with the otherwise solid tile.

And for vertical movement:

- If you’re letting gravity do its job for downhill movement, make sure that the minimum gravity displacement is compatible with slope and horizontal velocity. For example, on a 4:1 slope (as {4, 7} above), the gravity displacement must be at least 1/4 of the horizontal velocity, rounded up. On a 2:1 slope (such as {0, 7}), at least 1/2. If you don’t ensure this, the player will move horizontally right off the ramp for a while, until gravity catches up and drags him down, making him bounce on the ramp, instead of smoothly descending it.
- An alternative to using gravity is to compute how many pixels above floor the player was before movement, and how many it is afterwards (using the formula below), and adjust his position so they’re the same.
- When moving down, instead of considering a slope tile’s top edge as its collision boundary, instead, compute its floor coordinate at the current vertical line, and use that. To do that, find the [0, 1] value which represents the player’s x position on tile (0 = left, 1 = right) and use it to linearly interpolate the floorY values. The code will look something like:
float t = float(centerX - tileX) / tileSize; float floorY = (1-t) * leftFloorY + t * rightFloorY;

- When moving down, if multiple tiles on the same Y coordinate are obstacle candidates, and the one on the X coordinate of the player’s center is a slope tile, use that one, and ignore the rest – even though the others are technically closer. This ensures proper behaviour around the edges of slopes, with the character actually “sinking” on a completely solid tile because of the adjacent slope.

### One-way platforms

*Super Mario World, showing Mario falling through (left) and standing on (right) the same one-way platform*

One-way platforms are platforms that you can step on, but you can also jump through them. In other words, they count as an obstacle if you’re already on top of them, but are otherwise traversable. That sentence is the key to understanding their behavior. The algorithm changes as follows:

- On the x axis, the tile is never an obstacle
- On the y axis, the tile is only an obstacle if, prior to the movement, the player was entirely above it (that is, bottom-most coordinate of player was at least one pixel above top-most coordinate of one-way platform). To check for this, you will probably want to store the original player position before doing any stepping.

It might be tempting to have it act as an obstacle if the player’s y speed is positive (that is, if the player is falling), but this behavior is wrong: it’s possible for the player to jump so he overlaps the platform, but then falls down again without having his feet reach the platform. In that case, he should still fall through.

Some games allow the player to “jump down” from such platforms. There are a few ways to do this, but they are all relatively simple. You could, for example, disable one-way platforms for a single frame and ensure that y speed is at least one (so he’ll be clear of the initial collision condition on the next frame), or you could check if he’s standing exclusively on one-way platforms, and, if so, manually move the player one pixel to the bottom.

### Ladders

*Mega Man 7, with tile boundaries, highlighted ladder tiles, and player ladder hitbox.*

Ladders might seem complicated to implement, but they are simply an alternate state – when you’re in a ladder, you ignore most of the standard collision system, and replace it with a new set of rules. Ladders are typically one tile wide.

You can usually enter the ladder state in two ways:

- Have your character hitbox overlap with the ladder, either on ground or on air, and hit up (some games also allow you to hit down)
- Have your character stand on top of a “ladder top” tile (which is often a one-way platform tile as well, so you can walk on top of it), and hit down.

This has the effect of immediately snapping the player’s x coordinate to align with the ladder tiles, and, if going down from the top of ladder, move y coordinate so player is now inside the actual ladder. At this point, some games will use a different hitbox for the purposes of determining whether the player is still on the ladder. Mega Man, for example, seems to use a single tile (equivalent to top tile of the original character, highlighted in red in the image above).

There are a few different ways of LEAVING the ladder:

- Reaching the top of the ladder. This will usually prompt an animation and move the player several pixels up in y, so he’s now standing on top of the ladder.
- Reaching the bottom of a hanging ladder. This will cause the player to simply fall, although some games won’t let the player leave the ladder in this way.
- Moving left or right. If there is no obstacle on that side, the player may be allowed to leave that way.
- Jumping. Some games allow you to release the ladder by doing this.

### Stairs

*Castlevania: Dracula X, with tile boundaries*

Stairs are a variation of ladders, seen in few games, but notably in the Castlevania series. The actual implementation is very similar to that of ladders, with a few exceptions:

- The player moves tile by tile or half-tile by half-tile (as in Dracula X)
- Each “step” causes the player to be shifted simultaneously on X and Y coordinates, by a preset amount.
- Initial overlapping detection when going up might look on the tile ahead instead of just the current overlap one.

### Moving Platforms

Moving platforms can seem a little tricky, but are actually fairly simple. Unlike normal platforms, they cannot be represented by fixed tiles (for obvious reasons), and instead should be represented by an AABB, that is, a rectangle that cannot be rotated. It is a normal obstacle for all collision purposes, and if you stop here, you’ll have very slippery moving platforms (that is, they work as intended, except that the character does not move along it on his own).

There are a few different ways to implement that. One algorithm is as follows:

- Before anything on the scene is stepped, determine whether the character is standing on a moving platform. This can be done by checking, for example, whether his center-bottom pixel is just one pixel above the surface of the platform. If it is, store a handle to the platform and its current position inside the character.
- Step all moving platforms. Make sure that this happens before you step characters.
- For every character that’s standing on a moving platform, figure the delta-position of the platform, that is, how much it has moved along each axis. Now, shift the character by the same amount.
- Step the characters as usual.

### Other Features

Other games have more complicated and exclusive features. Sonic the Hedgehog series is notable for this. Those are beyond the scope of this article (and my knowledge, for that matter!), but might be subject of a future article.

## Type #3: Bitmask

Similar to “Tile Based (Smooth)”, but instead of using large tiles, an image is used to determine collision for each pixel. This allows finer detailing, but significantly increases complexity, memory usage, and requires something akin to an image editor to create levels. It also often implies that tiles won’t be used for visuals, and may therefore require large, individual artwork for each level. Due to those issues, this is a relatively uncommon technique, but can produce higher quality results than tile-based approaches. It is also suitable for dynamic environments – such as the destructible scenarios in Worms – as you can “draw” into the bitmask to change the scenario.

*Worms World Party, featuring destructible terrain*

Examples: Worms, Talbot’s Odyssey

### How it works

The basic idea is very similar to the tile (smooth) algorithm – you can simply consider each pixel to be a tile, and implement the exact same algorithm, and everything will work, with one major exception – slopes. Since slopes are now implicitly defined by the positioning between nearby tiles, the previous technique doesn’t work, and a much more complex algorithm has to be used in its place. Other things, such as ladders, also become trickier.

### Slopes

*Talbot’s Odyssey, with the collision bitmask overlaid on top of the game.*

Slopes are the primary reason why this type of implementation is very hard to get right. Unfortunately, they are also pretty much mandatory, as it’d make no sense to use this implementation without slopes. Often, they’re the reason why you’re even using this system.

This is, roughly, the algorithm used by Talbot’s Odyssey:

- Integrate acceleration and velocity to compute the desired delta-position vector (how much to move in each axis).
- Step each axis separately, starting with the one with the largest absolute difference.
- For the horizontal movement, offset the player AABB by 3 pixels to the top, so he can climb slopes.
- Scan ahead, by checking against all valid obstacles and the bitmask itself, to determine how many pixels it is able to move before hitting an obstacle. Move to this new position.
- If this was horizontal movement, move as many pixels up as necessary (which should be up to 3) to make up for slope.
- If, at the end of the movement, any pixel of the character is overlaping with any obstacle, undo the movement on this axis.
- Regardless of result of last condition, proceed to do the same for the other axis.

## Type #4: Vectorial

This technique uses vectorial data (lines or polygons) to determine the boundaries of collision areas. Very difficult to implement properly, it is nevertheless increasingly popular due to the ubiquity of physics engines, such as Box2D, which are suitable for implementing this technique. It provides benefits similar to the bitmask technique, but without major memory overhead, and using a very different way of editing levels.

*Braid (level editor), with visible layers (top) and the collision polygons (bottom)*

Examples: Braid, Limbo

### How it works

There are two general ways of approaching this:

- Resolve movement and collisions yourself, similar to the bitmask method, but using polygon angles to compute deflection and have proper slopes.
- Use a physics engine (e.g. Box2D)

Obviously, the second is more popular (though I suspect that Braid went for the first), both because it is easier and because it allows you to do many other things with physics in the game. Unfortunately, in my opinion, one has to be very careful when going this route, to avoid making the game feel like a generic, uninteresting physics-platformer.

### Compound objects

This approach has its own unique problems. It may suddenly be difficult to tell whether the player is actually standing on the floor (due to rounding errors), or whether it’s hitting a wall or sliding down a steep incline. If using a physics engine, friction can be an issue, as you’ll want friction to be high on the foot, but low on the sides.

There are different ways to deal with those, but a popular solution is to divide the character into several different polygons, each with different roles associated: so you’d (optionally) have the main central body, then a thin rectangle for feet, and two thin rectangles for sides, and another for head or some similar combination. Sometimes they are tapered to avoid getting caught into obstacles. They can have different physics properties, and collision callbacks on those can be used to determine the status of character. For more information, sensors (non-colliding objects that are just used to check for overlap) can be used. Common cases include determinining whether we’re close enough to the floor to perform a jump, or if the character is pushing against a wall, etc.

# General Considerations

Regardless of the type of platform movement that you have chosen (except perhaps for type #1), a few general considerations apply.

## Acceleration

*Super Mario World (low acceleration), Super Metroid (mid acceleration), Mega Man 7 (high acceleration)*

One of the factors that affects the feel of a platformer the most is the acceleration of the character. Acceleration is the rate of change in speed. When it is low, the character takes a long time to reach its maximum velocity, or to come to a halt after the player lets go of controls. This makes the character feel “slippery”, and can be hard to master. This movement is most commonly associated with the Super Mario series of games. When the acceleration is high, the character takes very little (or no time) to go from zero to maximum speed and back, resulting in very fast responding, “twitchy” controls, as seen in the Mega Man series (I believe that Mega Man actually employs infinite acceleration, that is, you’re either stopped or on full speed).

Even if a game has no acceleration on its horizontal movement, it is likely to have at least some for the jump arcs – otherwise they will be shaped like triangles.

### How it works

Implementing acceleration is actually fairly simple, but there are a few traps to watch out for.

- Determine xTargetSpeed. This should be 0 if the player is not touching the controls, -maxSpeed if pressing left or +maxSpeed if pressing right.
- Determine yTargetSpeed. This should be 0 if the player is standing on a platform, +terminalSpeed otherwise.
- For each axis, accelerate the current speed towards target speed using either weighted averaging or adding acceleration.

- Weighted averaging: acceleration is a number (“a”) from 0 (no change) to 1 (instant acceleration). Use that value to linearly interpolate between target and current speed, and set the result as current speed.

vector2f curSpeed = a * targetSpeed + (1-a) * curSpeed; if (fabs(curSpeed.x) < threshold) curSpeed.x = 0; if (fabs(curSpeed.y) < threshold) curSpeed.y = 0;

- Adding acceleration: We’ll determine which direction to add the acceleration to (using the sign function, which returns 1 for numbers >0 and -1 for <0), then check if we overshot.

vector2f direction = vector2f(sign(targetSpeed.x - curSpeed.x), sign(targetSpeed.y - curSpeed.y)); curSpeed += acceleration * direction; if (sign(targetSpeed.x - curSpeed.x) != direction.x) curSpeed.x = targetSpeed.x; if (sign(targetSpeed.y - curSpeed.y) != direction.y) curSpeed.y = targetSpeed.y;

## Jump control

*Super Metroid, Samus performing the “Space Jump” (with “Screw Attack” power-up)*

Jumping in a platform game can be as simple as checking if the player is on the ground (or, often, whether he was on the ground anytime on the last n frames), and, if so, giving the character an initial negative y speed (in physical terms, an impulse) and letting gravity do the rest.

There are four general ways in which the player can control the jump:

- Impulse: seen in games such as Super Mario World and Sonic the Hedgehog, the jump preserves the momentum (that is, in implementation terms, the speed) that the character had before the jump. In some games, this is the only way to influence the arc of the jump – just like in real life. There is nothing to implement here – it will be like this unless you do something to stop it!
- Aerial acceleration: that is, retaining control of horizontal movement while in mid-air. Though this is physically implausible, it is a very popular feature, as it makes the character much more controllable. Almost every platformer game has it, with exceptions for games similar to Prince of Persia. Generally, the airborne acceleration is greatly reduced, so impulse is important, but some games (like Mega Man) give you full air control. This is generally implemented as merely tweaking the acceleration parameter while you’re airborne.
- Ascent control: another physically implausible action, but very popular, as it gives you much greater control over the character. The longer you hold the jump button, the higher the character jumps. Typically, this is implemented by continuing to add impulse to the character (though this impulse can incrementally decrease) for as long as the button is held, or alternatively by suppressing gravity while the button is held. A time limit is imposed, unless you want the character to be able to jump infinitely.
- Multiple jumps: once airborne, some games allow the player to jump again, perhaps for an unlimited number of times (as in the Space Jump in Super Metroid or the flight in Talbot’s Odyssey), or for a limited number of jumps before touching the ground (“double jump” being the most common choice). This can be accomplished by keeping a counter that increases for each jump and decreases when you’re on the ground (be careful when you update this, or you might reset it right after the first jump), and only allowing further jumps if the counter is low enough. Sometimes, the second jump is shorter than the initial one. Other restrictions may apply – the Space Jump only triggers if you’re already doing a spin jump and just began to fall.

## Animations and leading

*Black Thorne, character doing a long animation before shooting backwards (Y button)*

In many games, your character will play an animation before actually performing the action you requested. However, on a twitchy action-based game, this will frustrate players – DON’T DO THAT! You should still have leading animations for things such as jumping and running, but if you care about how the game responds, make those cosmetic only, with the action taken immediately regardless of the animation.

## Smoother movement

Using integers to represent the position of the characters is wise, as it makes it faster and stable. However, if you use integers for everything, you will end up with some jerky motion. There are multiple solutions to this. These are a few:

- Use a float for all computations and for storing position, and cast to int whenever you’re rendering or computing collisions. Fast and simple, but it starts losing precision if you move too far away from (0,0). This is probably not relevant unless you have a very large playfield, but it’s something to keep in mind. If it comes to it, you can use a double instead.
- Use a fixed point number for all computations and position, and again cast to int when you’re rendering or computing collisions. Less precise than float and with a more limited range, but the precision is uniform and can, on some hardware, be faster (notably, floating point processing is slow on many mobile phones).
- Store position as an integer, but keep a “remainder” stored in a float. When integrating position, compute the delta-movement as a float, add the remainder to the delta-movement, then add the integer part of this value to the position, and the fractional part to the “remainder” field. On the next frame, the remainder will get added back in. The advantage of this method is that you’re using an integer everywhere except for movement, ensuring that you won’t have floating point complications elsewhere, and increasing performance. This technique is also very suitable if you have some framework in which the position of the object has to be an integer, or where it is a float, but that same position is used directly by the rendering system – in that case, you can use the framework-provided float position to store integer values only, to make sure that the rendering is always aligned to pixels.

# Multi-thread OpenGL texture loading

Those who have used OpenGL are probably aware that you can only invoke OpenGL procedures for a given context on the thread that currently owns it – usually, the main thread. This leads many programmers to assume that OpenGL is strictly single-threaded, and that no loading can be done on the background, inside some loader thread. This is not the actual case, and it’s actually fairly simple to work around this.

The key to multi-threaded OpenGL is in creating multiple contexts that share data between them. On Windows, it is done with the wglShareLists() procedure. On X and Apple APIs, it can be done during context creation (glXCreateContext() and aglCreateContext(), respectively). It boils down to creating a second context for the loader thread, and setting it to share data with the main context. This way, all data loaded on the second context will be available on the main one – you can just create a texture normally on the loader thread, and then glBindTexture() it on the main thread, for example.

On Windows/C++0x, the code looks like this:

void startLoader(HWND hwnd) { // Assuming that this is the main thread HDC hdc = GetDC(hwnd); HGLRC mainContext = wglGetCurrentContext(); HGLRC loaderContext = wglCreateContext(hdc); wglShareLists(loaderContext, mainContext); // Order matters boost::thread([=] () { wglMakeCurrent(hdc, loaderContext); runLoader(); // Your method for loading textures wglMakeCurrent(nullptr, nullptr); wglDeleteContext(loaderContext); }); }

Most APIs (such as Allegro, SDL, wxWidgets, etc) will provide you with a simple method of retrieving the window handle, which is all that you require to call the above procedure.

Note that you could create the context and share the lists inside the loader thread, but wglShareLists() must be called BEFORE anything is done on the main context, so the safest way is to do it on the main thread (otherwise, the new thread could take a while to run and be too late to do it).

**IMPORTANT**! I have observed that, on some cases (Windows 7 64, NVIDIA 320M), attempting to use a texture after it has been created (via glGenTextures()) but before its data finished uploaded (in this case, via glTexSubImage2D()) resulted in the texture being corrupted, and remaining corrupted even after it was uploaded. This will happen even if you wait for glTexSubImage2D() to return before using it on the main thread, since OpenGL is asynchronous. To avoid this problem, make sure that you glFinish() the loader thread before you attempt to use any textures initialized there.

# Understanding the Game Main Loop

Video games are simply ordinary software – there’s nothing intrinsically special about them. However, they SEEM to behave in a very different way from your ordinary everyday applications – so much that many experienced programmers are at a complete loss when faced with the task of developing a game from scratch. This difference is mostly caused by game’s close ties to their main loop. In this article, we’ll examine what is the main loop, how it works, and why it’s important.

**A simple model**

How simply could we model a computer game? Let’s start by separating the game in two parts: the data inside the computer, and everything outside the computer. This might seem like a strange thing to say, but remember that games are, first and foremost, interactive software. So, outside the computer, we have (at the very least) the *player*. Inside the computer we have all sorts of data, but the most important is what we call the *game state*: it contains all the dynamic information of the game: the position of the player, monsters and camera; the current time; the score – in essence, everything that changes with time.

A computer game can then be understood as a system in which those two entities – *player* and *game state* – interact with each other according to a specific pattern of rules. The player *inputs *data into the system, and the system uses the game state to generate *output *to display to the player. This is not very different from ordinary applications, in which e.g. a click (input) might cause a dialog to show up (output). The difference is how that behaves in respect with time.

**The Game Loop**

Most applications are developed in a reactive way – your program just sits around waiting for the user to click something, and then it does something in response. There is a main loop behind your application as well, but it’s not important – it’s abstracted away. With games, your code is constantly being invoked, even in the absence of user input.

The pseudo-code for a video game will often look like this:

void GameClass::main() { init(); runMainLoop(); deInit(); }

The main loop looks something like this:

while (running) { processInput(); updateGameState(); drawScreen(); }

First, it reads input from the user and stores it somewhere. Here, it will check the keyboard, gamepad, plastic guitar and network message queues – basically, it will collect all information from the outside world.

After that, it will use that information to update the game state – depending on what conditions we have, they will have different results. For example, on the menu screen, detecting that the “down” arrow got pressed might increment the “currently selected menu item” variable, but the same input while on the game might instead trigger the “set player as moving down” flag. Note that the world update is invoked even if the user didn’t perform any input. This is a very important property of most video games.

Lastly, it will collect the current game state data to generate the output – it will figure out where the player and camera and everything else are, and generate an image to display on the screen. A more complicated game will also have to deal with other forms of output – audio and network, for example.

**A More Sophisticated Main Loop**

The loop pseudo-code above suffers from a major flaw: it will run at unpredictable speeds – on fast machines it might run thousands of times per second (which would be a waste), and on slow machines it might run on unacceptably slow speeds – perhaps only five updates per second or so. Besides the obvious issues, this makes the game much harder to program – it’s much easier to write your game logic when you know that you’ll have a *fixed number of steps per second*.

Consider this: the player presses the right arrow, and you store a flag containing that information. Now, on every step, regardless of any player action, you’ll move the player to the right by 1 unit in the game state (which, let’s say, corresponds to 1 pixel on the screen). If the game runs at 5 Hz (that is, 5 updates per second), the player will move VERY slowly. If it runs at 5000 Hz, he’ll be out of the screen before you can even see it!

A possible solution to this is to calculate the real time elapsed between two steps and use this information during the step. In practice, however, this makes the game development much harder and error prone. It will also make networking a true nightmare, and will essentially make reliable behavior (e.g. replays) impossible.

A much better solution is to fix the rate at which your game performs its updates. Most modern games use an internal clock of 60 Hz or 30 Hz. Let’s assume 60 Hz for our example. This means that, 60 times per second, your game will check the input from the player, update the game state, and try to display something on the screen. But how do we control that?

First, let’s consider the case of a very fast computer. In this case, before each iteration of the main loop, we’ll check if it’s time for the update. If it isn’t, we’ll simply wait (preferably yielding the time slice back to the operating system), without doing any processing.

In the case of a slower computer, things are trickier – we can’t skip on updating the game state, or the game will run in slow motion, so we must sacrifice the output – the screen rendering. On most games, screen rendering is the slowest part of the pipeline, meaning that most games WILL be able to run at 60 Hz given enough sacrifice on graphics. If not, then the game will be way too slow, and we have no choice but ask the player to get a better computer.

In pseudo-code, our new algorithm now looks somewhat like this:

while (running) { if (isTimeToUpdate()) { processInput(); updateGameState(); if (hasTimeToDraw()) drawScreen(); } else { waitUntilItsTime(); } }

It’s simple, but it’s very similar to real game loops found in real games.

**The Foundation**

At this point, it should be clear that the vast majority of the game code will run inside the main loop – in a simple game, everything except for initialization and deinitialization. Also, that code is now separated in three functions: processing input, updating the game state, and rendering the screen. Since all three of them are controlled by the loop, it’s the foundation block of every game.

Having this foundation, your task of implementing a game has been reduced into three simpler and relatively independent tasks. The input you collect will be used on the state updating stage, and the state created by that step will be used to generate the output to the user, but they are each their own logically distinct operations, and how they interact with each other is now clear.

If you understand the topic discussed in this article, then all you have to figure out in order to make a (very) simple game is “how to read user input?”, “how to draw stuff on the screen?” and “how to keep track of my state and update it?”. None of those are, at a basic level, difficult, but they might be different from what programmers are used to coding.

On the next article, we’ll try to figure those things out and write an extremely simple real-time game using those concepts.

# Math for Game Programmers 04 – Operations on vectors

Last time, we introduced vectors, and hopefully that introduction alone would be compelling reason to use vectors where it makes sense to. This time, we’ll discuss common operations associated with vectors, and their many uses. All of these operations are commonly found in vector operation libraries.

**Length**

Like we’ve discussed on the previous post, the length (or magnitude) of a vector is the square root of the sum of the squares of its components. So, if you have a 3D vector, its length is sqrt(x²+y²+z²). It is often represented by writing the vector inside ||s, that is, the length of vector v is said to be |v|.

For example, if we have the vector (4,2,4), we have:

length((4,2,4)) = |(4,2,4)| = sqrt(4²+2²+4²) = sqrt(36) = 6

*Application example*: If you have two points, you can find the vector between them and take its length to find the distance between the points.

**Multiplication by scalar**

You can multiply a vector by a scalar number (that is, a real number), which results in multiplying each component of the vector by that number. For example:

(0,-2,5) * 2 = (0,-4,10)

When you multiply a vector by a scalar, its direction is unchanged, but its length is multiplied by the scalar – for that reason, this operation is also called “scaling” the vector.

*Application **example*: If you have an object moving with a vector representing its speed, you can adjust the speed without adjusting the direction by scaling the vector.

**Normalization**

By combining the two previous operations, we can “normalize” a vector. A vector is said to be normalized when its length is equal to 1. Since we can multiply any vector (except for (0,0,0)) by a scalar and therefore change its length to anything we want, we can normalize any vector by multiplying it by the inverse of its length.

In other words:

n = v * (1/|v|)

For convenience, many classes implementing vectors will define a “division by scalar” operator, so you could often just do this:

n = v/|v|

*Application **example*: If you want a vector that represents a direction without a length, you usually want to use normalized vectors. It turns out, this is extremely common, and you will encounter normalized vectors very often.

**Dot Product**

Possibly the single most interesting operation on vectors, the dot product is very simple and versatile. It takes two vectors and returns a scalar number as the result, according to the following formula:

(a,b,c) . (d,e,f) = a*d + b*e + c*f

So, for example:

(2,-6,-10) . (1, 0, -1) = 2*1 + (-6)*0 + (-10)*(-1) = 2 + 10 = 12

It also has a different interpretation. Given two vectors v1 and v2, and let α be the angle between the two vectors, the dot product can be defined as:

v1 . v2 = |v1| * |v2| * cos(α)

This means that the angle between the two vectors can be determined like this:

α = arc cos( (v1 . v2) / (|v1| * |v2|) )

The formula above can easily be derived by isolating α on the previous equation. If the two vectors are normalized, then their lengths are one, and the dot product is simply the cosine of the angle between them.

One consequence of the cosine relationship is that the dot product can be used to determine the relative facing of two vectors. Let d be the dot product between two NORMALIZED vectors. Then:

v = 1: the two vectors face the exact same direction

0 < v < 1: the two vectors face roughly the same direction

v = 0: the two vectors are perpendicular

-1 < v < 0: the two vectors face roughly opposite directions

v = -1: the two vectors face exactly opposite directions

If you’re not interested in v=1 and v=-1 cases, then there is no need for the vectors to be normalized.

*Applications*: finding angles between vectors, projecting vectors into specific axes, determining whether a vector is facing the right direction, neutralizing a vector along a given axis, etc

**Cross product**

Similar to the dot product, but instead of taking two vectors and producing a scalar, the vector product takes two vectors and produces a third vector. It is defined as follows:

(a,b,c) x (d,e,f) = (b*f-c*e, c*d-a*f, a*e-b*d)

Similar to the dot product, the cross product also has an angular relationship,

|v1 x v2| = |v1| * |v2| * sin(α)

It’s important to note that while the dot product is also defined for 2D vectors, the cross product is only defined for 3D vectors. However, since it has useful properties even for 2D, a pseudo vector product can be defined for 2D vectors as follows:

(a,b) x’ (c,d) = a*d-b*c

This results in a scalar that is identical to what the “z” component of the result of extending the multiplication to 3D: (a,b,0) x (c,d,0) = (0,0,z)

A very important property of the cross product is that the cross between two vectors ALWAYS results in a vector that is perpendicular to the two original vectors (unless one of them was null). This makes the vector product extremely useful for calculating surface normal vectors – assuming that you can find three points on the surface, you can create the vectors v1 = (A-B) and v2 = (A-C), then n = v1 x v2, n’ = n/|n|.

An interesting use for the cross product (in particular, the 2D version) is that it indicates which direction a vector must rotate in order to face the same direction as the other vector, by taking the shortest path. Simply take the cross product between “current facing” and “desired facing” vectors, and the sign of the number (i.e. whether it’s negative or positive) will tell you which way to turn.

*Applications*: Finding normal vectors, finding turn directions, calculating torque, etc

These operations are some of the most basic things you can do with vectors. They will allow you to perform more complicated and interesting computations using vectors, so *make sure* that you understand them. We will use them very often in following lessons.

The fifth article in this series is now available here.

# Math for game programmers 03 – Geometrical representation of vectors

In the previous post, we introduced vectors, and showed some very elementary uses for them. We presented them as a simple and convenient way to pack a number (3, in our case) of scalar values into a single object. Now, we’ll consider their geometrical representation, which will help you grasp them more intuitively. For simplification’s sake, we’ll use two-dimensional vectors for all our examples, but the same extends to 3D vectors.

**Points**

First, consider two points, A and B. A is located at (1, 2), and B is located at (4, 3) (If you are unfamiliar with the cartesian plane, points are represented as coordinate pairs in the form (x,y), so (1, 2) means that A is at x=1 and y=2), as shown in the following picture:

As we’ve mentioned in the previous post, positions in space can be represented as vectors. So we would have a vector A and a vector B, each representing one of the points in the figure. But points are not the SAME as vectors! A vector should always be thought of as a “delta”, it’s merely an increment. Without a reference, it’s meaningless as a position. For points, we adopt the point (0,0) as our *origin* (represented by the letter O), so all points can be represented as a vector from the origin. Drawing our vectors as arrows, we get this:

Consider it for a moment. If we have O=(0,0), and we add a vector A=(1,2) to it, you’ll get the point (0+1, 0+2) = (1,2), which is exactly our original point A. However, vector A by itself is merely an increment of 1 in x and an increment of 2 in y… As such, we could also represent it as:

This might all sound confusing, but don’t worry, it’ll eventually “click” into place! If you don’t fully understand the concept now, don’t worry about it.

**Addition and Subtraction**

What if you took vector B and subtracted A from it? From our previous lesson, we know that B – A is simply (B.x – A.x, B.y – A.y), so, given that B = (4, 3) and A = (1, 2), B-A = (3, 1). Let’s call that vector “C”. If we do A + C, we should naturally get B back: (1, 2) + (3, 1) = (4, 3). If you remember that we said that vectors are merely offsets, then this means that we can represent C as the vector that takes “A” and turns it into “B”, as in the following picture:

If you look to the axes, you’ll see that vector C (the orange vector) spans x from 1 to 4, meaning that its x component is 3 (4-1), and y from 2 to 3, meaning that its y component is 1 (3-2).

**Length and Distances**

The geometrical representation of vectors leads to a very intuitive way to understand one of their most important operations, length. The length of a vector (or magnitude) is simply its geometrical length! Take vector B, for example. It has a x component of 4, and a y component of 3. How can we get its length? The pythagorean theorem solves that for us: we simply take the square root of the sum of its squared components. For a 2D vector, length = sqrt(x²+y²). For a 3D vector, length = sqrt(x²+y²+z²), and so forth.

For example, the length of vector B is sqrt(3²+4²) = sqrt(25) = 5.

One immediate use for the length operation is to find distances. Say that you want to find the distance between points A and B. You subtract one from the other (order doesn’t matter), and take its length. In C++, that would look as simple as:

float distance = (a-b).length();

The reason why the order of the subtraction doesn’t matter is that (A-B) results in the opposite vector of (B-A), that is, a vector with the same length, but opposite direction. A-B results in (-3,-1), and B-A in (3,1). Both have a length of sqrt(10).

# Math for game programmers 02 – Vectors 101

If you don’t already use vectors (and I mean vectors in the MATHEMATICAL sense, not in the “dynamic array” sense that languages like C++ or Java use), this is probably going to be the single most useful piece of math you can learn for writing games. It’s easy, efficient, and makes your code much shorter. In fact, provided that you’re using a language that supports definition of operators for user-defined types (like, say, C++ or Haskell), using vectors is going to be extremely intuitive and simple.

**Motivation: The Ugly Code
**

Consider that you want to simulate some simple physics, such as an object accelerating in 3D space. We’re going to use the formulas Δs = v₀t + ½·a·t² and Δv = a·t (where s is the position, v₀ is the speed at the start, a is the acceleration, and t is the elapsed time). You might declare the object as something like this:

class PhysicsObject { public: float pos_x, pos_y, pos_z; // Position float vel_x, vel_y, vel_z; // Velocity float imass; // The inverse of the mass (1/m) void addImpulse(float force_x, float force_y, float force_z, float t) // t is time, in seconds { float halft2 = 0.5f * t * t; float accel_x = force_x * imass; float accel_y = force_y * imass; float accel_z = force_z * imass; pos_x += vel_x * t + accel_x * halft2; pos_x += vel_y * t + accel_y * halft2; pos_x += vel_z * t + accel_z * halft2; vel_x += accel_x * t; vel_y += accel_y * t; vel_z += accel_z * t; } };

Not very pretty – there’s a lot of redundancy – whatever you do for one axis, you do for the other two. If only there was a way to do that all at once…

**Enter vectors: The Pretty Code
**

Here’s the same code, but this time using a hypothetical 3d vector class:

class PhysicsObject { public: vector3f pos; // Position vector3f vel; // Velocity float imass; // The inverse of the mass (1/m) void addImpulse(vector3f force, float t) // t is time, in seconds { vector3f accel = force * imass; pos += vel * t + accel * (0.5f * t * t); vel += accel * t; } };

Much shorter, isn’t it? You now have half as many lines to write, test and debug. Not only that, but they’re also simpler, and you avoid a whole class of “copy-paste but oops forgot to change a letter in one place” bugs. So, after all, what ARE these vectors? How do they work?

P.S.: If you’re using a language which does not allow you to define your own operators, the code above will get quite uglier… Java, I’m looking at you.

**Defining vectors**

If you go check Euclidean Vector at Wikipedia, you’ll see that it’s defined as a geometric object that has magnitude (length) and direction. For our purposes, while important to remember that definition, we’ll think of vectors as an n-tuple of a given type. In the example about, we have a 3-tuple (“a triple”) of floats. In other words, our definition would be something like this:

class vector3 { public: float x, y, z; inline vector3 operator + (const vector3 &param) const { return vector3(x + param.x, y + param.y, z + param.z); } inline vector3& operator += (const vector3 &param) { x += param.x; y += param.y; z += param.z; return *this; } inline vector3 operator * (float param) const { return vector3(x * param, y * param, z * param); } // Lots of other methods here };

Basically, all it does (so far) is take basic arithmetic operators and apply them to 3 values, instead of just one. When you add two vectors, it adds each component – x to x, y to y and z to z. There’s also the “scale” operator, which is the multiplication by a scalar (a scalar is a non-vectorial number, like a float). When you multiply a vector by a scalar, you simply multiply all components by it. So, if you want to make your vector twice as big, just multiply it by 2.

That’s it! That’s the basic idea! Whenever you have two or more points and always want to perform the same set of operations on them, use a vector! In fact, most properties that apply to scalar numbers will also work here… If you happen to know that you need to multiply velocity by time to get a change in position, you can do that with vectors in just the same way you would with scalars.

When should you use vectors like this? *Whenever it makes sense*. If you’re passing along two or three values which all represent the same point, do yourself a favor and pack them in a vector. Not only will it be much harder to accidentally mix up stuff, your code will be shorter. Even if they aren’t a POSITION, they might still be represented by a vector – for example, the size of a rectangle is a vector where x is the width and y is the height. That way, if you have a vector representing the starting position of the rectangle, and a vector representing its size, you can easily find its ending position by adding them up.

But vectors are far more powerful than this. On the next article, we’ll explore other common operations done on them, such as length, normalization, dot product and cross product. You wouldn’t believe me if I told you just how damn useful those can be.

# Math for game programmers 01 – Introduction

Here comes a harsh fact of life: game programming requires mathematics. One could say that programming IS, in a way, math, but you don’t really need to know math to write the vast majority of programs. Most of the time, you don’t need it to write parsers, to interact with databases, to validate data. Games, however, very often rely on mathematics. If you want objects to move across your world realistically, or if you want to draw things on the screen following certain geometric patterns, or if you want to check for collision between certain shapes, you need math.

But don’t despair! Even though I say “math”, what you ACTUALLY need is geometry. Luckily for us, geometry is probably the easiest part of mathematics! Now, I’m not saying that discrete mathematics, algebra and calculus are useless for writing games (or other sorts of programs), but geometry is the bread and butter of video game programmers.

An interesting thing that I did notice is that, despite my previous assertion, many game programmers do not actually know much geometry! This means that they’ll often do things in extremely laborious, buggy and verbose ways, when it could very easily be done with some basic grasp of geometry. For example, if you want to place several objects along an arc of circle, you COULD do it through trial and error, or place it in an image editing program (like Photoshop) and copying the coordinates, but it will be much easier if you simply use a parametric equation.

So I intend to write a few posts to explain, as clearly as I can, some topics that are important to game programming. These are the topics that I intend to cover:

- Vectors
- Parametric Equations
- Vector bases
- Basic Trigonometry
- Matrices
- Complex Numbers
- Quaternions

While there are many basic and in-depth tutorials of all of the above topics on the Internet, explanations as to why the matter to game programmers and how to use them seem to be scarce, or left as an exercise to the reader. My goal is to make those topics easy to understand and put into use.