To all fellow sailors out there; I hope you find good fortune and fun in the coming year. Now is the time to write our own stories and chart our own paths.

Good luck, have fun :)

#KISS - Keep It Stupid Simple

When I say keep it simple, I don’t mean endlessly remove features until you’re left with no program at all. But the goal of keeping a program, function, or line of code simple is to maintain legibility and more importantly usability. I’m willing to wager that all programmers write code they’re not going to recognize in a given period of time. Oftentimes that length of time is much shorter than you might think. Writing clear, concise statements in your program can lead to a clear trail to follow. Writing clear, concise functions can make a program easier to dissect. It’s awfully difficult to optimize or even just maintain a code base if things aren’t easily parsed by our squishy brains. This serves in the way of not over complicating your end goal as well. Do you need 16 ways to update a row in a database or just the one or two?

#Use the smallest possible data type

This isn’t necessarily the best practice to do for optimization. Rather my goal with this is about understanding the scope of the variable needed. It forces me to think about what I’m writing instead of just writing out int for every single counting number that I need. There are plenty of talks on Data Oriented Design that address this topic significantly better than I will within the scope of this list.

#Be Consistent

When you’re learning something difficult oftentimes you’ll be told,”Consistency is key”. Cliches aside, it’s an important factor in programming. Consistently writing code that is laid out similarly across the program can give you an added efficiency bonus when debugging or optimizing. By consistency I mean functionally. When I write my physics logic for games, I tend to lay it out in the same fashion where possible. If I use common functions amongst many different scopes it leaves me with a common denominator to debug at. Yes it creates a point of failure, but I also don’t like maintaining 18 versions of the same thing. Which leads me to my next guideline:

#DRY - Don’t Repeat Yourself

This is directly lifted from The Pragmatic Programmer. There are certain cutoffs to this sentiment, especially in games. But generally I stick to the goal of not repeating common functionality more than twice in separate functions. Usually this ends up being look up functionality, adding or removing something from an array that isn’t just as simple as changing the index, or context changes.

#Have a naming convention

The goal of a naming convention is to be consistent. Yes, it’s sort of a repeat of the ‘Be Consistent’ guideline, but it’s important enough to separate out. Having consistent naming means you’ll not have to rely upon recalling a function name. You can figure it out on your own. Here’s an example of my naming convention:

In my game engine, astera, I write out several different files of functionality useful for working on games. The first character of my function names signify the subsystem (rendering, audio, collision, etc). Followed by the data type/struct, then operation. So say I want to create the rendering context at startup. I start off with the subsystem r then context in my keyword list is defined as ctx so it becomes r_ctx. The operation is create so the function name is r_ctx_create. I have keywords I often repeat in places so that it’s not a guessing game as to what I should name something as well. Am I wanting to destroy/exit the render context? That’s r_ctx_destroy. What if I want to update the listener’s position for audio? a_listener_set_pos.

This is one of those rules that generally applies to bigger projects but is easily ignored by smaller ones. What do I define as a larger project? Anything greater than 50 lines of code usually.

#Use a code formatter

Yes, seriously. This is huge. Having consistently laid out files is essential for your sanity the second you have to use pull requests or merge in other people’s code. I can’t tell you how many days of my life have been lost to simply having to correct merge conflicts that were generated by whitespace. Consistent layout generally prevents most of these conflicts, and saves you time. The tool I prefer for this is clang-format. There’s a plugin for just about every editor out there I can think of. I know even Visual Studio now supports it (crazy, right?). Here’s my clang format file I use for just about everything C/C++ related.

#Backup your configuration files

Shit happens. Your computer’s current state is not guaranteed. There are plenty of tools out there to backup your configuration files, generally called dot file managers. I’ve seen people write their own scripts that just make symlinks to a central folder that they have as a repository on their github to automatically backup their files. There are programs as well. Or you can just drop the updated files into a repository you backup inconsistently to tell yourself you’re responsible. Either way, having a solid point to recover from reduces the time you’re having to spend setting up your development environment again.

#Test your work

There might come a day where you think you know everything you need to in relation to a certain project. But the simple fact of the matter is that we are not computers. Static analysis, unit tests, whatever version of testing you want to do, you should have at least something. No, you don’t need a whole suite to perform regression testing and spit out fancy graphs showing you how shit one of your updates was. But when left in the darkness, you simply cannot know exactly what is happening. Clang has one built in, there are plenty of others like Cppcheck out there. I recommend you get comfortable using one. As well, use an AddressSanitizer. Modern compilers have native support built in, oftentimes are just a few optional package installs away at most.

#Low Config

I find that a lot of the time I don’t configure my editors a lot. I will go out of way to make some obvious quality of life changes. For example, adding fzf to vim. Do I need it? No. Can I operate without it? Yeah. But the primary idea of this preference is that I can sit down at any computer, if it has it installed already just out of the box, I can get to working right away.

#Keeping it Lean

This is where things really are circumstantial. I’m fortunate that most of the projects that I work with are relatively straightforward in a lot of aspects. The fun thing about large projects is that everything focuses on efficiency and quality within a span of time usually. Even as Astera approached 16,000 lines of code (in itself) I’m starting to notice a good bit of my workflow slow down. Things like clang-format on save are starting to add artificial delays. I often ask myself the following questions: Do I need all of the tools I’m using? Are any of my tools causing me to stop and break flow to accomplish something? Is my code arbitrarily verbose? Is there a simpler and more straightforward way to accomplish this?

#5 9s Theory

This might be something older (than I am) developers already know. But for some reason it’s fallen out of common lingo in programming lately. 5 9s refers to uptime of a given service (99.999%). Some might know it as six sigma. I was exposed to this when working as a pseudo sysadmin which really gave me a respect for the other side of programming. Those that have to live with our code. Many times you’ll be tasked with maintaining code within a company. The main sticking point is that if something were to happen, be it a career change or getting hit by a bus, there is a distinct possibility that production code you write can and will live on somewhere, maintained by someone who doesn’t have perfect context or history behind the reasoning of the code.

My point being, write good tools that work and document them properly. To refer back to Keeping It Simple, use what you need, and don’t settle for “just alright” if you can afford to not. I’ve found that taking the time to set myself up with stable and reliable tools (and auditing them) be it once a year or every few months is infinitely more fruitful than jumping ship to whatever bleeding edge (it’s called bleeding edge for a reason) tech there is.

#Give yourself space

This is one of those things that requires constant maintenance. It’s in part brought to the forefront of my observation due to me reading Deep Work by Cal Newport. I’d sort of tried to do this prior but didn’t have a lot of the words Cal had put into writing. I find I both get into flow faster and stay in it longer if I chunk out my schedule to ignore email, discord, social media etc. Just me, some music, and the code (or whatever I’m working on). This can be a difficult one to put into practice especially if your habits conflict with it. It’s been I get some of my best work done in these times. There is the common sentiment of a “10x engineer” that many often wager as a goal. I don’t think that such exists, just a true fully realized 1x engineer.

#In Conclusion

One of the common themes here is that less can be more in a lot of situations. Where is it really possible for us to improve not only as professionals but as individuals by making otherwise minor changes? If you actually read this far, I hope you take the time to try some of these ideas out for yourself. I don’t think my words do it complete justice, and am interested in your interpretations of this.

#Buffers

Buffers are a relatively straightforward concept, right? Think big array with only a set number of indexes immediately stored. You can fetch more, continue down the buffer, or just straight up modify the data going in for effects. You see this data, is the audio that’s getting played back. Beware tho, modifying this data directly can lead to funky outcomes when combined with other layers of the audio system. Generally we try to limit modifying the buffers to just simple filters (I’ll explain filters more later, just think of it like cutting out certain bits). With these buffers, you pass them to sources that read them and play them back! Note: Generally the data in these buffers is called PCM. PCM stands for Pulse Code Modulation (Amplitude, Frequency, and Phase). This data tells your speakers what to play.

1
2
3
4
5
6

void create_buffer(unsigned char* file_data, int file_size) {
  // OpenAL: alGenBuffers(1, &buffer_id)
  int buffer_id = buffer_create();
  // OpenAL: alBufferData(buffer, format, data, size, freq)
  buffer_data(buffer_id, file_data, file_size); 
}

#Sources

While a source could mean a few different things in the programming context, think of it as a floating speaker at a given point in space. Whether 2D or 3D, doesn’t make too much of a difference except what you hear. With these sources, like mentioned earlier, you can attach a buffer to play back. You can also generally attach filters and effects (think reverb, chorus, etc, I’ll explain this more too). The source is meant to be the place where you dial in what you want to come out of that speaker if you were directly in front of it. Do you want that monster hit to sound super echo-y without making all sounds echo? You should probably attach the reverb effect to the source then.

1
2
3
4
5
6

void create_source(vec3 position) {
  // OpenAL: alGenSources(1, &source_id)
  int source_id = source_create(); 
  // OpenAL: alSource3f(source_id, AL_POSITION, x, y, z)
  source_set_position(source_id, position); 
}

#Listener

The listener is one of the more straightforward concepts in game audio. Think of it as your ears. Some people consider it a microphone so it doesn’t have to be tied to a specific entity. Either works. At the listener stage is generally where you want to mix the audio in what is being heard. Keep in mind you can also attach global effects and filters to the listener for when you sounds to be modified uniformly.

1
2
3
4
5
6
7
8

// NOTE: Most audio frameworks assume there's always 
//       a listener so you shouldn't need to initialize it
void update_listener(vec3 position, float gain) {
  // OpenAL: alListener3f(AL_POSITION, x, y, z);
  listener_set_position(position); 
  // OpenAL: alListenerf(AL_GAIN, gain);
  listener_set_gain(gain); 
}

#Mixing

Mixing can be a whole host of things. Like DJing at a live show, mixing in game audio is generally dynamic. Having a good mix can having a game sound great or like complete garbage with no regard for the listener. There’s a few steps to mixing in itself but by far the most important is loudness. Keep in mind there’s a difference between loudness and volume. Volume is generally at what decibel is something being played. Loudness is how loud something is generally perceived. There’s a few categories to it but the one I find most important is the delta of volume. Something that has high volume suddenly can appear louder than something winding up over time. The best example is boiling a frog, where volume is the heat. As well it also includes the range of that sound. Is it too high pitched? Might want to eq (equalize) the high range down so it’s not so annoying. Does the sound just need some high frequencies taken out, not muffled? Add a low pass filter to it and tweak the values to match. A useful topic on loudness is, LUFS (Loudness Units relative to Full Scale).

Mixing, I think, is generally the art of layering things together well and with proper focus. What is relevant in a song that is crazy memorable on a journey thru an environment is very different from a background song that’s just meant to set the mood while you’re fighting enemies creating tons of sounds. In combat it’s a good idea to prioritize important sounds that might be cues to the player as to exactly what is going on. Another important thing is culling out too many sounds. If you have 600 enemies making the exact same sound in a given period of time, hearing it 600 times can be a little crazy. There’s a limit to how much we naturally perceive relative to how loud something already is. So when something is loud and near you, you won’t necessarily be able to hear the leafs falling 50 meters away.

#Effects

Effects can be thought of as mathematical formulas for modifying data. All the effects generally do is take some inputs and create an output. I like to think of them as small black boxes I hook all my guitar pedals up to to make it sound different. Reverb is perhaps one of the more prevalent effects used. Reverb has a few inputs to it generally: room size, wet/dry, damp, gain, etc. There’s a large amount of possibility when it comes to effects but generally there’s a set of effects used: reverb, chorus, distortion, echo, flanger, and equalizers.

#Filters

Filters are more like, well, filters. Think about audio this way: there’s 3 main frequency bands we tend to consider: low, mid, and high. Think of low pretty much as bass/booming sounds, mid is roughly where some lower sounding instruments are and much of human talking, while high is all the higher pitched ends of talking, instruments, metal sounds, etc. These categories directly correlate to the frequency of the sound being percieved. For helping cull out some of these bands, we generally use what are aptly named: lowpass filter, highpass filters, and bandpass filters. You can think of them as pretty direct implications of their names. Low pass lets thru low end noises, high pass higher end, and band pass both low and high. Filters like these might be important if you have a sound effect you know occupies a certain frequency, and you want to give it the ability to stand out in the playback. To do that, you can just add a filters to filter around where the sound occupies, giving it a sort of solo effect. If you’re interested in learning more about filters, I’d recommend this article. TL;DR Low pass lets low frequencies thru, high pass lets high frequencies thru.

1
2
3
4
5

void filter_out_annoying_sounds(song annoying_song) {
  // Create a lowpass filter that lets all frequencies under 22khz thru
  lowpass_filter = lowpass_filter_create(22000.0f);
  song_add_filter(annoying_song, lowpass_filter);
}

#Keyframes + Events

Effects and filters are important. What is also important is that you can update the parameters of each over time following key frames/events. There might be specific bits of songs that need a low pass filter during combat but not the rest of the song or when there is no longer other sounds in that frequency range playing. I strongly encourage you to not go too over board with this. But it is important to understand that there are many possible layers of complexity when it comes to playing with the sound you’re receiving. Keyframes and Events should be able to trigger different things with regards to your sound, dynamic sound modulation can have really cool effects!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

void enemy_attacks_us() {
  // ... update collision, game status, etc
  start_combat_effects();
}

// Filter out most the upper end noises so combat sound effects are heard clearly
void start_combat_effects() {
  // let everything below 1600 hz thru
  filter = lowpass_filter_create(1600.0f); 
  for(song current_song : songs_playing) {
    song_add_filter(current_song, filter);
    // Maybe lower the gain as well, unless we're playing an intense song!
  }
}

#Audio Codecs

Audio can be a lot of data if it goes on for long enough. The way we store and transmit audio is generally compressed so that most audio that wouldn’t be human perceivable is cut out. The point of the codec is to help compress and cut out unnecessary (open to interpretation) data in audio files. In game development I’ve generally run across two main formats for audio, and I’ll explain them as such. Note: Codec stands for coder/decoder.

WAV / Wave Format: Wave Format is one of the most straightforward formats you can use. It’s good for short sounds that generally don’t need compression and thus you can afford to let them be closer to original size. Wave is generally uncompressed meaning the format dictates you store the raw audio data in the file. The file is pretty much just a header on at the start with the data following. That makes loading and streaming it from disk relatively straightforward. Keep track of where you were and you can know where you should go next.

OGG / Vorbis: OGG Vorbis is an open source audio format/container. .ogg files can be deceptively small, as the algorithm is super efficient at cutting out imperceptible noise and saving frames of what will need to be played back. It has quite a bit of configurability, but the main benefit of the system is the almost mind boggling level of compression you can get out of it. Here’s some real world stats. My prized possession of a file: Rebecca Black - Friday.mp3 is roughly 5.3 mb. Well, that’s pretty good if you ask me for a 3 minute 47 second absolute banger of a song. Well when I hook that up to ffmpeg and convert it to WAV File, it’s now 39.1 mb. Man, mp3 must be insane… Run it thru ffmpeg again converting that WAV file to OGG yields a file of 2.8 mb. Almost half the size of the mp3 we started with. With that level of compression in mind there are some drawbacks to implementing it. The way the format is laid out means there’s almost always a need to use a library that has implemented decoding it (stb, libvorbis) which has inherit overheads in itself. The main tradeoff here is disk space for CPU cycles. Vorbis is primarily used in my projects for music files exclusively. The compression is so great and the streaming implementation, when done correctly, can be almost no cost on modern machines. Keep in mind that wave files are generally advisable for sound effects, because now you’re not having to decode 60 smaller files, just a few big ones over time.

After these two examples you might be wondering, why not just use MP3? It’s a good middle ground, it’s almost the defacto standard for compressed audio these days. You can download them pretty easily. Well, historically, mp3 is a licensed technology. Meaning you should probably acquire a license (acquire as in pay for) to use the technology/standard in your software. Software patents are evil, and make it complicated and mundane enough that it’s straight up just not worth it. If you’re concerned about accessibility to getting files to WAV/OGG, I strongly encourage downloading ffmpeg and using it to convert your audio if your creation software doesn’t export to it immediately (most do).

1
2
3
4
5

void decode_ogg_file(unsigned char* file_data, int file_length) {
 usable_audio_data = vorbis_decoder_decode(file_data, file_length);
 
 // then buffer the data into a buffer for use or just print it for funsies
}

#Tips

• Don’t master your sounds to 0 db being the ceiling, there is data loss after you cross 0 db, so amplifying it leads to lower quality
• A good atmosphere sound is better than an alright song, don’t be afraid to not be playing music constantly
• Making music is hard, but it’s not the most important audio of your game. Sound effects alone can make a game sound good, bad music can tank it. Add good music and it can be a masterpiece. Find your capabilities and stretch them a little but be realistic when it comes to standards
• Listen to your audio in different places. Headphones are always ideal, but not everyone will play every game with great headphones on. Not everyone will play your game inside. Listen to your creations in the car, in your bathroom on a speaker, on your TV, and with quiet headphones. Note: some games offer EQ options based on where you’re listen to it, not all these environments are made equal
• Good audio doesn’t have to be loud to be heard correctly. Well balanced audio shouldn’t need to have your headphones maxed out at 100% to listen to the beautiful noises you’ve spent so much time making.

#Tools

Some of these tools are DAWs (Digital Audio Workstations). Think, Game Engine for creating music/sound. Many of them are so advanced now you can get by without outside equipment. VSTs (Virtual Studio Technology, think, synths/instruments) as generally plugins for helping create sounds. If you’re interested in working in DAWs I strongly recommend starting small. You don’t need to go and buy a midi keyboard (piano kind) to start making music. You can get by making some pretty good stuff with just your computer keyboard, mouse, and decent headphones. Remember, a bad carpenter with a $5000 tool is still bad. Grow out of your tools first.

rxi/aq, audio framework in C - Audio framework that has many of the concepts discussed!

sfxia (windows, linux) - Generate sounds/sound effects

sfrx - The OG sound generator for game jams

ableton live - This is my preferred DAW, it’s not open source but it works damn well

fl studio - Also known as fruity loops, this also a super capable DAW with tons of documentation/videos on using it

reaper - a cross platform tracker style DAW (linux, mac, windows). Seems very capable, and I’ll be trying it more on linunx!

freesound - This is a giant repository of open source / creative commons sounds, I highly recommend contributing and using it!

fmod - If at the end of the day, you just want a tool that will solve most of your problems for integrating / implementing good sounding audio, there are many worse choices than FMod.

and most importantly, patience. Patience will be your greatest tool when working with this kind of tech.

Many times I find myself gawking at new hardware releases, with awe and wonder around the new “efficiencies” they offer. It’s as such that at any time of year I can probably quote a relatively accurate number of the average percentage improvement over the previous generation the latest has brought about. This isn’t an all bad thing for me, I lead a life where I work many different specific disciplines in the Information Technology world such that possibly I’ll need to bring about newer hardware for clients. Tho, that reality is diminishing rapidly with cost-effectiveness improving within cloud hosting services. With minor exceptions I find a lot of focus has been put on consistent upgrading of hardware. The interval seems to have shrunk down to around 2 years or roughly 2 cycles of hardware releases. While this isn’t nearly as bad as related technology, like smartphones, it is becoming eerily similar. The improvements each release are often touted as “revolutionary” or “game changing”, yet in real world usage, are often just iterative improvements. I often find myself thinking,”well, it would make this thing faster” or might save me time in that area. Though, the cost to time benefit is almost never as great as the monkey side of my brain makes it out to be.

A lot of this only works up to a certain extent, right? There’s always exceptions to most things in life, the main point here is more of “if it ain’t broke, don’t replace it” sort of thing. Another thing to consider, especially if you’re still new to programming, is that worse hardware can force you to be more responsible with what you write. I remember the nights spent frustrated with my code because it was “slow”, on my dual core Phenom II 955 with 2GB ram and integrated Radeon HD 4250 Onboard GPU, that took a sizable chunk of that ram as well. Back then I didn’t write in C, or any relatively plain languages either. I was focused on learning Java and using the good ol’ IDE, Eclipse. Neither of these lend themselves to super fast usage, even with somewhat older versions. I’m not claiming to be a great programmer because once upon a time I had bad hardware. Although, I do believe the experience has an inherent value to it for future endeavours.

To sum it all up with a nice little bow tie, think about what hardware you have now, what software you pair it with, and how you can squeeze more juice out of it? I have a few examples of friends running 9 year old CPUs and still keeping pace with development. Future generations might be revolutionary, but for now, can you get by with what you already have, or the cheaper/maybe used version? I know for myself, after having done some very rough and inaccurate tests, I use on average 5-10% of my CPU, and less of my GPU from day to day.

I think it’s fair to say that the idea of being a “digital nomad” nowadays is easier accomplished given the ever growing black hole that is cloud based platforms. There are all sorts of free things available on the internet for the low low cost of your data and information. I get how it might be displeasing to think about the idea that even free services will profit off of you some way or another. But, I do prefer the inherent reliability of that option to having my laptop stolen and losing everything I’m working on. Personally I prefer to self host the bulk of everything and have a background backup task to backblaze.

If there’s nothing else you take away from this article, at least take this: offsite backups are your best friend, even if they’re an annoying one.

#the code itself

Code is an interesting thing when it comes to backups. I’m hyper aware of if my code is complete or not, and I generally try to not push incomplete things into a backup or commit. However there is the sad truth that partial code / implemenation completions still are wanted. For this reason I tend to play with multiple git remotes. There’s always the public facing remote, which I use as the sort of psuedo-release candidate for commits. Then the backup remote where the code can be stashed without judgement, generally this is a private repository. In terms of hosting I tend to just use a self hosted Forgejo instance at the time being, I’ve used GitLab and other personal Gitea instances before.

In addition to forgejo, I have a nightly cron job that syncs my forgejo repositories to backblaze. And every once in awhile when I remember to, I’ll grab a snapshot and put it on an external hard drive so I have a somewhat recent copy for if the internet goes down.

#physical

Physical security can be a relatively sensitive subject. I generally operate under the assumption that I’m not some ultimate badass that’s going to defend myself from the vast majority of mankind itself. For this reason I think the alternate of software / hardware aided security sort of steps in. For my laptop, if it’s windows it’s BitLocker, if it’s Linux it’s LUKS.

On top of this, a few years ago I invested in a YubiKey and set it up with all of my machines for unlock/decryption usage. If you wanted to take this a step further, having a self destruct or “kill switch” would be a good idea.

#software

I remember very clearly when I had discovered portable software. I was in the 7th grade and playing around with running things that weren’t allowed, on my Middle School’s computers. I’m sorry to my technology teacher, but it was me, that got that one program running that you hated. It wasn’t anything malicious, I hadn’t discovered malware/virus creation yet. But this transitions nicely into the idea of having a portable OS on a flash drive. It’s by far not the most elegant of solutions, but having a portable distro on a flash drive with your persistent memory is perhaps one of the more reliable alternatives to downloading software you absolutely need every time. It comes with the caveat of being able to make the computer boot from USB, if a machine is properly secured, you shouldn’t be able to get into the BIOS.

#conclusion

This is just a write up of what I’ve been thinking about the last few weeks. It’s a contingency plan that has sort of spinning the background these last few months. If you have any ideas / questions, definitely let me know!

A lot of this information exists online, but this post is meant to be a sort of introduction & combination of a few different sources. Just as a preface, this is meant for code hardening with clang & gcc. The two have many of the same features, tho some are not interchangable. As I’m making a cross platform game library/framework/thing, I test everything I can on whichever popular compilers I can get my hands on. The windows process for this is something that is tailored to that as well as MSVC’s respective flags.

Also please keep in mind that these are all tools I use in my own workflow. As I work primarily in C99 and more towards Linux / Unix environment. Thus they’ll tend to reflect that as well. However, most of these concepts / tools have direct analogs to Windows as well.

#ASAN

ASAN is the shorter form of saying, “AdressSanitizer”. It’s an open source tool created by Google that helps detect memory leaks, overflows, and various other memory issues. If you’re working on something and it seems like you have a memory bug, you’re gonna want this in your toolkit. Keep in mind, when using the tool, it’ll increase the memory footprint of the program overall substantially. You’ll want to make sure you have plenty of overhead. valgrind –tool=toolname program Installation

Depending on your operating system, you might have to install AddressSanitizer or asan of some sort. Since I’m on Void Linux I had to install libsanitizer (and the -devel package, just to be safe) in order for it to work with GCC correctly. Clang seems to sometimes bundle it on it’s own as well, if it doesn’t appear to work for you try making sure you have llvm installed. On Arch it seemed to not install the library for me. Otherwise without the package it’ll appear to give incomplete or ambiguous output!

Other than that, you’re pretty much good to go. Any updated / modern (ish) compiler should have support for asan.

Usage

Configuration for this tool is surprisingly simple for what it provides. For my specific configuration I added these compilation options (flags):

1

-fsanitize=address -fno-omit-frame-pointer -O2 -g

If you’re using cmake, you’ll want to make sure you add -fsanitize=address to your link options as well.

in CMake this looks a little like the following:

1
2
3
4
5
6

target_compile_options(${PROJECT_NAME}
  PUBLIC
  -fsanitize=address -fno-omit-frame-pointer -O2 -g)
target_link_options(${PROJECT_NAME}
  PUBLIC
  -fsanitize=address)

Now let’s break down each of the flags, a good reference for these is GCC’s page on Instrumentation Options.

From the documentation you can see that -fsanitize=address is what’s enabling the memory error detector, it’s the primary flag of the list. On top of this, -fno-omit-frame-pointer ensures that the stack frame pointer isn’t omitted for functions that require it. -O2 enables all optimizations, which is ultimately what you want to debug memory leaks with since they’ll start appearing with more optimizations and less leniant standards of compilation / language usage.

Side tip: If you really want to have fun and harden functionality of the code, enable -fsanitize=undefined. This enables the UndefinedBehaviorSanitizer which, really, really goes into detail about precision of your program. You can find more info on different sanitizers at the link for Instrumentation Options.

#Valgrind

Checking for memory leaks is often one half of the equation that is memory optimization. Profiling it can prove to be a mysterious and somewhat magical thing for programmers that haven’t used tools for it before. You might have heard of Valgrind before, it’s a relatively popular tool. If you haven’t used it before it’s relatively straighforward to use.

Installation

Many operating systems don’t come with it installed, so definitely make sure you have it installed.

apt installation would be something like:

1
2
3
4
5
6
7
8

# debian / ubuntu / apt
sudo apt install valgrind

# arch
sudo pacman -S valgrind

# void linux
sudo xbps-install valgrind

Usage

The general usage is pretty easy to grasp, it’s usually as follows:

1

valgrind --tool=toolname program

There are a few different tools valgrind has, such as memcheck (for memory profiling), massif (heap profiler), or cachegrind (cache & branch prediction profiler).

For more in depth on how to use these tools, check out the valgrind manual.

#Other useful flags

Many of these flags are gathered from Red Hat’s page on Recommended compiler and linker flags for GCC. I’ll just go over a few of them which you might really benefit from.

-D_FORTIFY_SOURCE=2 - Fortify Source enables some lightweight checks to be used on various string & memory manipulation functions. Some of these checks are run at compile time which will manifest as compiler warnings, others are runtime. The 2 Option just means to use more / most checks.

-Wall -pedantic -Wextra - This is maybe the most insanity condusive of them all. I try to only do this to myself once or twice a week at most. It enables all recommended compiler warnings (-Wall)

-fplugin=annobin - annobin is meant to be a binary tool which helps generate data about the binary, how it was made, what was used to make it, stuff like that. Red Hat has a good post that goes into detail on the usage of it.

-fstack-protector-all / -fstack-protector - This causes more code to be emitted to check for buffer overflows. It does some fun stuff with adding guard variables and more checks, if one of the checks fails, it’ll print an error and exit the program.

-O2 - I referenced this earlier, but it enables the compiler’s recommended optimizations. Definitely make sure you have this enabled for anything you’re trying to ship.

-g - I’m pretty sure a lot, if not most, of us have heard / used this flag before. It causes the compiler to generate debugging information. Inverse to the O2 flag, maybe don’t have this enabled when you’re compiling something to ship!

There’s a whole playlist, but I won’t really bother putting it in here. I feel it’s probably pretty visible in the video description & ending.

Either way, let me know what you think about the editing! It’s been a few years since I’ve edited down a video of this size, usually I just make shorter meme videos. I’ve been playing around with the psuedo documentary style for the last few months recording events / trips I go on. So maybe expect more of that style in the near future.

Anyways, I’m off to rob a wombat of his rhombus somewhere in the ether and write more code. This video thing isn’t terribly productive for game development.

• Make peace with my depression
• Build my own house
• Fall in love
• Make a game completely on my own
• Host a game jam
• Make games full time
• Build an affordable open source game console
• Take up drawing (again)
• Release my game written in my game engine
• Create a full experience game release
• Start an independent game studio
• Paint a mural
• Travel to Scotland
• Live in another country for more than 3 months
• Trace my ancestry
• Write a book
• Go sky diving
• Read 100 books
• Roadtrip across the US
• Take up boxing
• Help someone else achieve a dream
• Mentor someone

The above picture is the Raspberry Pi Zero W (Same size as the non-wireless) next to a standard US Quarter.

The following has been a side project of mine for a few months now. Mostly sitting idle while I do research on breaks.

Often times when people are told that someone is making a raspberry pi game console they think one of two things: Someone is building an emulation / retropie machine, or they don’t know what they’re talking about. While I like to think that I might have some idea of what I’m talking about, the latter might be true here as well.

For the last little bit I’ve been poking around the internet looking at different options of raspberry pi operating systems. The idea was to have something suitable to simply host a game binary on for play with little-no overhead. My Google-Foo might not be once it once was, but I couldn’t find anything that was easily accessible for the Raspberry Pi Zero. It seems that this little brother has been left in the dark by most people thinking of using it for anything but automation.

If you actually look at the specs of the machine they’re halfway decent as well. Especially considering the non-wireless option is $5. That’s less than the SD Card I use for terrible storage speeds. If you’re unfamiliar with the exact specifications of the Pi Zero, here they are:

• Single Core 1GHz Broadcom BCM2835 (ARM11 Core using ARMv6 Arch)
• VideoCore 4 GPU (Reference, Page 12 has all the good stuff) 250MHz, OpenGL-ES 1.x & 2.0 Support
• 512MB LPDDR2 SDRAM
• USB On-The-Go Port (Breakout for Standard USB Female Header needed)
• Mini HDMI (You’re usually going to need an adapter for this)
• 40 Pin GPIO Identical to RPi A+/B+/2B
• CSI Camera Header
• Single Green LED

The whole system generally runs on the USB Supported 5v. Under load, the Pi Zero and W pull on average less than 1 Watt. Keep in mind this is a little computer that can push 1080p. I’ll be targeting 720p at either 30 or 60 Hz though.

Ok, this is all nice, but what’s the ultimate goal you might ask? To be clear, my goal isn’t to sell you anything. I’m making a bare minimum operating system & tools to bake games into a distro for play on the Pi Zero and Zero W. There isn’t a traditional Desktop Environment or internet browser, literally just what you need to play the game on disk. The goal is that this hardware is cheap enough that it is easily accessible to people.

For all intents and purposes, this project is already closing in on being out of the conceptual phase. I’ve got a decent linux install running with support for OpenGL ES and hardware acceleration. Now it’s just onto making the tooling. The tooling part will take significantly longer than just creating the proof-of-concept. For the start of things I will be releasing a demo game (made using my game engine astera).

I’ll be posting all of the things I have on my GitHub in due time. For now I’m not going to release anything until it is at least functional.

I’m intending on keeping this a side project for now, I’ve been tinkering maybe once or twice a week with it while I take a break from Lost Souls development. If you’re interested in the current progress at any point feel free to message me on the discord

Beyond the Void is a dungeon crawler. It has randomly generated dungeons. You can play solo or online. In multiplayer you have 2 main options: You can crawl the dungeon with friends, or control the dungeon to stop them.

I’ve been working on the game in conceptual form for over 3 1/2 years now. There have been numerous iterations of the actual implementation of the game. Leading up to this point, there have been about 4 working prototypes. I live streamed 2 of the iterations, a few might remember.

#The Start

It started out as a way for me to pass time. Really something to make that included what I was interested in, Procedural Generation & Doom. Initially it was an FPS, paying homage to the likes of quake in terms of style. I soon realized, I can’t make 3D Models. So, being the John Carmack fanboy I am, I chose to keep it in the same vein and make the style more towards Wolfenstein 3D. Partially because I grew up playing it with my grandpa without my parents really knowing. It was an amazing thrill for a 4 year old me. Still a really large problem remained. I barely knew OpenGL.

A few months passed and I got the first versions of a “game” working. Note, I say “game” because initially it was just a renderer with some distance calculations for interaction. I posted a question on a forum I used to frequent often, Tek Syndicate. Fortunately I was friends with the host of the channel. This lead to the first public appearance of the game:

The thumbnail is the second ever screenshot I had taken of the implementation. Logan had been gracious enough to promote me. It was just unfortunate that following the few weeks I became ill. I had sort of missed the bus in terms of hype. I sort of fed off of the community hype around the game. Although it was fast fading, I still felt motivation from it for the year to come.

Being the sort of neat freak that I am, I spent the next few months cleaning any code I had made and rewriting what wasn’t “efficient enough”. It was sort of ironic that the game that I had started with the intention of being about my illness, was stifled by it. Nevertheless I droned on. Around December of that year I had a sort of “wholesome mess” as I will call it. To be frank, the game ran like crap. On my AMD FX 8320 it took up 30% CPU usage on idle. Among other things, it had a nice big gaping memory leak which wasn’t noticeable for the first few minutes of play. I wanted to target a reasonable market that could enjoy the game on even a low end computer. Taking up that kind of usage wasn’t particularly good for limited environments. To say the least, I was way in over my head.

#Relearning

This all gave way to the second revision of Beyond the Void. Boasting a brand new support of proper data structures, the game ran smoother. Dropping the inefficiencies of immediate mode rendering, and adopting the inherent complexities of buffer objects. I had caught up with the times of OpenGL Programming. This is also where I dropped the key points of a story idea. Connecting randomness is a sort of difficult and limiting factor. While its novel, it just added to the workload of making the game.

#Illness

I’m auto immune. I’ve spent my whole life always knowing where the closest hospital is. By the way, military hospitals don’t prove too effective for undiagnosed auto immunes. Unfortunately I was sick again. The usual sort of dying sort of not thing. For the most part I’m pretty good at dealing with being sick. But being stubborn about working on something and being sick don’t mix well. I spent a good 3 months in and out of the hospital. Usually it was that long because it was a particularly serious bout. But it wasn’t, I just didn’t focus on my health. I wasn’t productive, and I wasn’t getting better. So after way too long, I came to the decision I’d have to focus on getting better.

After that I had sort of moved on. I became interested in web technologies for awhile. I worked on a startup and then eventually found myself focusing on school after the summer passed. For the next year I focused mainly on playing League of Legends and improving my general programming. It was around this point that I became good friends with one of my teammates, Sawyer. Without him I would have just given up on the idea and moved on to some random 2D Games, or staying a web developer. It was his moral support that seemingly pushed me back into tackling this game.

#Mini Engine

Mini Engine was a sort of veil for me to work on more specialized things than just a game. It was initially just an experimental thing to see if I could play around with 3D effectively. It existed as something to do between classes in the college computer lab. Well it ended up being a pseudo version of Beyond the Void. The engine had all the components of a game, just, horribly put together. At the time my struggle was wanting to have as abstract and independent of code as possible as well as everything running as fast as possible. That doesn’t really work out too well given the circumstances. I live streamed some of it and updated the repository fairly regularly compared to past versions. If you want to see the cleaned version of the repository you can check it out here. The main problem of the engine was that there was no collision. At least, good collision. There is something about collision implementations that acts as a roadblock for me. You can only do so much before it, but there are a lot of things that work off of it. To say the least I was frustrated.

Leading up to this point I was preparing some things to show off at a Lan Syndicate. I had gotten most everything done and that included dungeon generation. I was proud of the efficiency of the map data generation. Clocked around 700ms so it wasn’t this big long load screen. Realistically it would take longer since this was a stripped version. I went to the lan with somewhat clouded expectations. I had posted on the Tek Syndicate forum prior, with almost no responses. So I figured I wouldn’t get too much interested in the game. And I didn’t.

The lan was fun, I spent a good bit of it writing code and just walking around and talking to people. I met all of these people I’d known exclusively online in person. I suppose after a few years of no updates they wouldn’t remember the game.

#Where Beyond the Void is Going

Beyond the Void as it stands is conceptually done. After the demo is out I’ll be opening up pre orders. Note: I’m putting out the demo first so people know what they’re putting their money towards. A few days prior to release I’ll be making a technical post going over some of the features in the game and how I accomplish them. Until then if you have questions, feel free to message me on discord.

Edit (July, 2022): This project is currently dead. It’s possible in the distant future I will flesh it out and make it properly. But currently I am working on bigger projects!