Recently, I decided to go through the Handmade Hero series. As I progress I’d like to use this space to serialize my mental model of concepts that are new or interesting to me.
This post is about Handmade Hero replay, and why I’m doing this in 2026. I’m sorry, it’s very noisy. I’ll get better at writing with practice.
Handmade Hero 2026
Handmade Hero came out somewhere around the time I was wrapping up WatchDogs and starting Rainbow Six: Siege. I remember I got as far as Animating The Backbuffer and then stopped. I couldn’t really tell you why, other than I was doing a lot in those days (professionally and socially). But its always sat in the back of my mind as something to return to, I just haven’t made time for that until now.
Why?
1. Professional Curiosity (A High-Level Career)
In 20 years of working in the game industry I have always worked within engines. Sometimes those were proprietary engines (THQ, Ubisoft), but I’d argue that closely resembles making a game in Unreal or Unity. The codebases are just less searchable on the web, though you might have an easier time reading/editing the source code.
While the things I’ve worked on have been complicated and interesting (Vehicle Dynamics, AR & ML, Camera Behaviors, AI Behaviors, First Person and 3rd Person Player Combat) they’re mostly abstracted from the platform and hardware.
I remember a Towers of Hanoi problem I worked on in University. The problem was to determine the minimum number of moves required to move n rings from the source peg to the destination peg using recursion. The solution had to be implemented in the assembly language for the Motorola 6800.
The first solution I came up with ran overnight. I thought, this can’t be right, that’s way too slow. I went to the student forums but the consensus among students and tutors there was that this was expected. I wasn’t happy with that.
So I kept working until I found a way to simplify the program. It involved only storing the most significant byte along with the number of trailing bytes (instead of shifting in memory, changing the storage complexity from O(n) to O(1)). Not having to hit memory so frequently, I managed to get my solution running in under 60 seconds and scored extra marks.
I told this story to one of the engine programmers at THQ when we were collaborating on a render culling feature (as I mentioned, I worked on cameras). He looked at me and said “you should be sitting over this side of the room“. That stuck with me ever since.
Hardware Adjacent Topics
At THQ I rewrote the gamepad sampling code of our engine because the designers felt the fidelity was off. They were right, the range was incorrect. We were truncating higher values in the range, and not starting at 0 when the deadzone threshold was breached. It looked like a rushed port from old generation consoles to the new generation (PS2->PS3, Xbox->Xbox360 at the time). A simple problem of re-normalizing the inputs and applying a circular dead-zone. Happy designers.
At Ubisoft I wrote touchpad sampling for the PS4 controller on Watchdogs (another generation change, PS3->PS4, Watchdogs was a PS4 launch title that was ultimately delayed). The game map behaved like google maps on your phone, drag to pan and pinch to zoom-in/out. That code was shared with other projects.
At Square Enix I wrote native code and interop bindings for Android and IOS for R&D in Augmented Reality and Machine Learning (a product that ultimately never shipped). That was to get data into Unity from platform APIs that were bleeding edge (literally, we were using pre-release versions directly from Google and Apple at the time).
In my own time, I dabbled in learning rendering with OpenGL. But here I was using SDL to create the OpenGL context and IMGUI for the UI – so again its on top of something someone else built. Still, this is where I started to learn shaders and writing code to run on the GPU.
Eventually I wrote some prototypes for the Playdate handheld in C. This was directly interfacing with the platform from scratch. I got really excited about learning the hardware inside out and began to mess around. Playdate refresh rate is limited based on how many rows you update on the screen. Full screen refresh (240 rows) you get 50FPS (more like 51-52). I figured out you can get higher framerates by updating less rows. However, it’s diminishing returns because the way the screen hardware works it can’t present changes fast enough beyond some point and it creates a sort of ghosting effect (which, depending on what you’re doing, can look like an intentional motion blur which is nice). Maybe I’ll write more about this at some point, I did a number of experiments and maybe I’m not completely done with it.
All of that to say, I really haven’t spent all that much time in low level code over the course of my career. Just a handful of stints here and there. I obviously have had to understand the implications the code I write in the engine (cache coherency and memory locality, ability to read assembly and debug registers). But I just haven’t had (or created) the opportunity (in my professional career) to write a lot of low level code.
At home, I’ve started multiple projects using SDL but that never really felt like I fully owned the stack, but I’ve wanted to. The desire to write bare metal and understand what’s going on has always been there.
2. AI Fatigue
I got pretty tired of the noise and hyperbole surrounding the use of LLMs in the programming world. Mostly, it’s the way humans in the space behave that I find off-putting.
The thing is, I worked with ML and LLMs before it was cool. I have some amazing tech demos from my time at Square Enix (under NDA). I am genuinely interested and excited by the technology. I still am.
But the vibe-coding movement has prompted me (heh) to really think about why I got into programming in the first place. It’s fueling a desire to return to first principles and grow a deeper understanding of the craft.
3. Inspiration
I covered this pretty well in my Handmade Software post. But the rise of quality software engineering content through channels like the Wookash Podcast and the Better Software Conference inspires me on a near daily basis.
My recent favorite is an interview with Mark Healey (I realize he’s mostly an artist – but my guy can code). I remember buying Ragdoll Kung-Fu off steam back in the day, and Little Big Planet was the entire reason I bought a PlayStation 3. I have really fond memories of both of those games, Little Big Planet in particular really inspired me at the time. It came out the year I interned at THQ. That was really an amazing time to be a gamer.
Mark is an artist, and some of the things he said in that interview really spoke to me (Casey has shared the exact same advice about programming).
Handmade Hero Replay
All of this culminated in me diving back into the series all these years later. All the way back to Week 0: Intro to C On Windows.
Early in the series while writing the Platform layer, Casey introduces DirectSound as the API for sound output. While measuring the latency of DirectSound, I noticed mine was the exact same as Casey’s, 12 years later.
Numbers speak louder than words:
SampleRate = 48000Hz;
BytesPerSample = 4; // 2 16-bit channels
LatencyBytes = 5760 bytes; // difference between play cursor and write cursor
LatencyMS = LatencyBytes / BytesPerSample / SampleRate * 1000;
= 5760 / 4 / 48000 * 1000;
= 30;That’s 30ms, 1 frame at 30FPS or 2 frames at 60FPS. Mine is 8 frames behind at 240FPS. This mildly annoyed me.
In search of modern alternatives to DirectSound (the answer is WASAPI on windows), I joined the Handmade Network discord, and quickly discovered a new initiative:
Talk about Serendipity! I was behind by about a week or so, but it seemed too great of an opportunity to ignore. I powered through to catch up and now I join the coffee discussion every Saturday. It’s a great place to share discoveries and ask questions. It’s a great mix of people, some very experienced programmers along with relative newcomers. BYP guides the discussions and we sometimes have Ben and other members of the community dropping in. Its been really motivating and engaging to have people to share the journey with, and it puts me a little out of my comfort zone which I think is always a good thing.
This last weekend we just covered Episodes 24-26 in which Casey has wrapped up the Prototype Platform Win32 Layer, and is moving onto Game Architecture (something I’m much more comfortable and familiar with). I think Episode 24 and 25 had some interesting things going on related to the page file system, virtual memory, and memory mapped files which I’ll cover in a separate post. I also have a lot to say about the hot reloading topic from episodes 21-23.
How?
The way I use Handmade Hero is I program along with whatever Casey is doing. I take notes about the topics I’m unfamiliar with, or programming philosophies I haven’t had exposure to.
I watch at 2x speed, but sometimes need to pause or slow playback or replay in order to write code or get a better understanding of what is being said or done.
Separately I’ve been trying to do what Mike Acton has talks about and practice the things I’m trying to get better at (e.g. I try to do all of Week 1 in under 30 minutes).
After getting through the first 28 episodes I’ve learnt so much about the windows API, and new ways to think about programming that I hadn’t really come across before. It’s seriously been so much fun and I’m just stoked to be doing it. It’s a really joyful experience.