C++

Here’s a simple programming task: read everything from a file into memory. To do this, you need to open the file, read the data, and stop reading when you reach the end of the file (abbreviated “EOF”).

But how do you KNOW you’ve reached the end of a file? That’s a simple question with a slightly complex/misleading answer.

Strings in C are simply arrays of char values - or in other words, a contiguous block of memory containing chars. C++ inherits that representation, but also provides a safer and easier-to-use option called std::string. In C++, the old C-style strings are often called C-Strings.

Most C++ gurus would advise you to avoid C-Strings and just use std::string. And it is true that std::string is safer and easier to use than C-Strings. Whereas std::string manages memory for you and has a ton of built-in functionality, C-Strings are essentially just blocks of char memory that you must manipulate with error-prone and inconsistent functions.

However, avoiding C-Strings entirely is difficult - sometimes you inherit code that’s using them, sometimes SDKs or libraries require you to use them, sometimes they are the most efficient option.

C-Strings can be confusing to work with. There are a variety of functions used to manipulate C-Strings, but some are deprecated or insecure, some are only available in certain compilers, and some have intricate ins and outs for using them properly.

So, my goal with this post is to catalogue some common operations you’d want to perform on C-Strings and identify the best options available, what to avoid, and what pitfalls exist.

Every game or game engine has at least a few managers under the hood. A manager is a collection of functions and data whose purpose is to “manage” something. You may send HTTP requests through an HttpManager. You may track the player’s inventory with an InventoryManager. You may play audio through an AudioManager. And so on.

How you access a manager is a seemingly mundane decision that can be surprisingly complex and paralysing. Do you pass the manager as a function parameter? Use a global variable? Make a bunch of static functions or a namespace? More elaborate mechanisms? Each option has pros and cons, and personal preference comes into play as well. Changing your mind later can incur significant refactoring overhead.

I’ve been coding games for about a decade now, so I’ve developed some opinions and ideas. I don’t think there’s a “best” or “right” way to do this, but I do currently have a “favorite” method. Below, I’ll review several access options, some pros/cons of each, and finally explain which one I’m liking the most lately.

Way back in G-Engine #4, we rendered a triangle, and there was much rejoicing. Since then, the posts in this series have primarily focused on implementing mathematical constructs in code. This point is the final math pre-requisite before we can move on to more interesting things.

Think of a game engine as its own little universe: at first, there is nothing - the void. Concepts such as time, position, and orientation don’t exist yet. Suddenly, the game loop and delta time introduces the concept of time. With vectors, we can convey positions, directions, and distances. Slowly, our universe takes shape and we can convey important concepts in code.

But what about rotations? Vectors can store position, direction, and scale data, but they are not effective structures for 3D rotations. We need some other option to convey rotations in code.

One structure that is very effective for 3D rotations is the Quaternion. Much-maligned for their apparant complexity, Quaternions allow us to efficiently store and use 3D rotation data. In this post, we’ll explore why we use quaternions, what they are, how to perform common operations with them, and finally I’ll provide some tips for writing your own Quaternion class.

Matrices are vital tools for 3D rendering. Graphics libraries expect you to use matrices to represent positions, rotations, and scales of 3D objects. Furthermore, matrices provide a convenient/effective mechanism for representing hierarchies of 3D objects and coordinate systems.

This post will briefly explain what matrices are, explain commonly used operations for 3D game development, and provide tips for writing matrix classes for your game engine.

We have added a basic math library to the 3D engine, but we’re still missing several fundamental mathematical building blocks to move forward and build full-fledged 3D environments. In particular, I want to implement Vectors, Matrices, and Quaternions. This post will cover Vectors, which enable the engine to represent important spacial concepts such as “position” and “direction”.

After my post about rendering basics, I had a fairly underwhelming final result: a single triangle being rendered in 3D. But it’s progress! My next goals are to do two seemingly simple things: move the virtual “camera” around my 3D environment to view the triangle from different perspectives, and move the triangle itself to different locations in 3D space.

If we were just writing some graphics library sample code, achieving those two goals would not be too tricky. However, I want to avoid using too many graphics library convenience methods (to avoid “lock in” to a particular graphics library) and I want to be laying the groundwork for 3D world features I’ll want in the future like translation/rotation/scale of objects and parenting.

One of the first things I need to address is my lack of math library. This post will explore a basic useful math library for a 3D game engine. Future posts will build upon this math library core to add support for 3D vector math, matrices, quaternions, and more!

Previous posts in this series have focused on the technical aspects of getting the G-Engine up and running. For this post, I’m going to take a short break from writing engine code to instead analyze how GK3 is built. It’ll be important to understand this as I move forward and try to recreate it.

As a data-driven game, GK3 makes heavy use of various custom data and file formats. I’ll refer to each piece of data as an asset.

A key challenge in this project is understanding what the different asset types are, how they relate to one another, how to parse and load them into memory, and how to make use of them at runtime in a meaningful way. The developers would have documented all this, but much of that is unavailable to me - time for some detective work!

This post focuses on those first two questions: what are the different asset types, and how do they relate to one another? We’ll take a look at the various assets, what they do, and the web of relationships between them.

In the last G-Engine post, we got the game loop and frame “delta time” calculations working. We’ve now got a blank, empty game window - yay? Despite the unimpressive result, we’ve got a beating heart under the hood: an update loop being called at roughly 60 frames per second.

Empty windows are no fun, so my next goal is to get something - anything - rendering in the game window. Graphics are a vital and exciting part of any game, and rendering can give us vital visual feedback as we move on to implementing and debugging 3D object placement, cameras, rotations, and data loading for 3D meshes and animations.

This post will focus on rendering a single triangle on screen. Though the result is simple, we’ll cover a lot of ground towards building a 3D rendering system that will be extended and enhanced as we move forward.

In my last G-Engine post, I did some setup work and finally got a basic OS window appearing that could be moved around, minimized/maximized, and closed. Good start!

In this post, we’ll do a bit more planning, and then we’ll structure our code into a high-level class (GEngine) that’ll be more conducive to building an engine than just shoving everything into the main function. We’ll also implement our “delta time” calculations, which will be critical for updating the state of our game as we move forward.