Clark Kromenaker

For years, I’ve developed G-Engine and have paid zero attention to text encoding. When I’d store text in a C++ std::string or in a char array, it would just work. It turns out I was just lucky - I was writing text in English, and the default encoding just happened to work fine with English.

However, my luck ran out when I started dealing with Russian localized text and text input. Suddenly my text was garbled and illegible. Time to face the music and deal with the intricacies of text encoding!

This post dives into the history of text encodings and how you can write a program that has broad Unicode support (via UTF-8).

The texture loading code for G-Engine was written early in development, when I was eager to see some on-screen graphics to demonstrate tangible progress on the project. And then that code stayed relatively untouched for years. However, a recent GitHub issue highlighted a bottleneck - installing a mod containing very large textures caused scene load times to skyrocket!

In this post, I’ll explain how this problem was investigated and fixed. It may be a helpful read if you want to learn more about loading image data to be used by a graphics API such as OpenGL, or if you want to see how naive texture loading code can be improved.

About three years ago, I wrote a post about wrangling dynamic libraries for Mac applications. I recently faced the same challenge on Linux, so I figured I’d write a follow up.

If you’re new to dealing with dynamic libraries, I’d recommend reviewing the previous post first - it covers some fundamentals that I won’t rehash here. Linux and Mac handle dynamic libraries in similar ways - but as you might guess, the tools used and some details vary.

Website development is not exactly my forte. Though I’ve dabbled over the years, I spend most of my time in C++, C#, and Java. Despite this, it’s fun and helpful to run a blog and portfolio site (the very one you’re reading), so I need to know a little bit about websites!

Over the years, I’ve tried a few different approaches to building and hosting this website before landing on what you see before you. This site is simple, easy to maintain, fast to load, secure, and (importantly) inexpensive to host.

In this post, I’ll explain the approaches I’ve tried in the past and how this site is currently built.

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 paralyzing. Do you pass the manager as a function parameter? Use a global variable? Make a bunch of static functions or a namespace? Devise 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 on this subject. I don’t think there’s a “best” or “right” way to do this, but there are a few ways to consider that might be useful in varying contexts.

Below, I’ll review several access options along with some pros/cons of each.

G-Engine uses various third-party libraries: ffmpeg for video playback, fmod for audio playback, zlib for decompression, etc. In all these cases, the library is included as a “dynamic library” (as opposed to a “static library”).

On Windows, when an executable needs a dynamic library, it searches for it in a few predefined locations, such as “the same directory as the executable”. On Mac and Linux, however, the situation is different and requires some consideration and explanation.

I was recently learning how macOS loads dynamic libraries, and it is not as intuitive or well documented as you might hope. This post attempts to lay things out in a clear and easy to digest way.

Way back in G-Engine Basic 3D Rendering, 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 apparent 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.