I am currently planning to using supabase for storage. Unsurprisingly, it does not have a zig sdk. It does, however, have a javascript sdk.

If I can write basic CRUD operations in javascript and call that from zig through webassembly, that could make that integration a lot easier.

Goals

There are a few ideal restrictions for me - mainly because writing javascript is not fun for me.

• Use the Supabase js/ts library through zig
• Use TypeScript as much as possible. (I don’t love TypeScript, but at least it’s not javascript)
• Keep as much of the supabase related code in the web part so that deno and lume can handle any heavy lifting.

Options

I can’t use FFI(Foreign Function Interface):

because imgui pulls in emscripten, which means we don’t have the ability to call instantiateStreaming.

With emscripten, declaring an external function is easy enough.

There are a couple of options to wire them up to the javascript:

library.js / mergeInto

This option requires javascript files on the zig side. If you want to start with typescript, you’ll need to integrate a transpiler into the build chain as well.

First, you want a javascript file - let’s call it libshine.js, and pop it into a js dir.

The project would do well to be multiplatform - mobile and web. The obvious choice was flutter and I have enjoyed working with it before.

However, as I’m currently in love with zig, I wanted to work with that instead.

Libraries

Graphics

I’ve been playing with raylib and that was my initial instinct. However, raylib does not support iOs and has issues with wasm

I considered a few options, including

• sdl, which looked great but was perhaps a little too low level for me.
• jok - does not support mobile and possibly has a little more than I needed.

In the end, I decided to go with sokol and sokol-zig.

While a little more lower level than raylib, it has:

• a modern clean api
• first class mobile support
• first class wasm support

UI

I’ve been working with dvui a lot recently. Unfortunately, it doesn’t support sokol. imgui is a better option.

There is even a template project that I could start from.

WASM first

To keep things straightforward, I decided to start with wasm. If I make the site mobile friendly, I could see how it goes and see if it needs a mobile version.

I will need some shared data storage and have been considering supabase, which has javascript libs. By using wasm, I can effectively shim in js functions to handle that instead of having to write bare rest calls from zig.

Structuring the project

Is this a zig project with a web component, vice versa or indeed two independent parts that work together.

I did a fair amount of web searching to see if there was some guidance I could I find for a good way to structure a relatively straightforward zig+js project.

I could not find one. In the end, I decided to keep it fairly straightforward.

Frontend

After a bit of research, and realising that I will probably need a little bit of supporting content around shine, I decided to go with lume

I used the simple-blog theme as a template to start from. I could have just pulled the template in but I wanted a custom homepage.

When I tried to add an index.md, it complained about two files wanting to write index.html. From what I could find, the easiest way to override the homepage was to just pick up the theme and edit it - which was easy enough.

WASM => frontend

I didn’t want to copy over the wasm and the js file every time, so I added a couple of steps to build.zig right after the link_step (also included below)

These steps will copy across the wasm and the js file across to static/shine. I wanted to put the js in src/js and the wasm in the static dir. However, the js file expects the wasm in the same dir. I tried overriding locateFile but it didn’t work.(you can use a different location by overriding locateFile)

I was able to get lume to process the javascript file by adding it.

Conclusion

With all of these set up, I was able to run:

in one window. This command will rebuild wasm and provide it to lume whenever the zig code changes.

Running this in another window will mean that lume will rebuild on any changes, including a new wasm file and redeploy. The redeploy will trigger an auto-reload of the page as well if I have it in a browser.

I now effectively have automated reload with changes if I make changes in either zig or the frontend.

I don’t have hot reload - but this is pretty good for now.

1. The score font is too small
2. The ball can get stuck inside a paddle
3. Trigger score on edge (not the middle) of the ball going past.

We’ll also refactor score tracking to better match game logic structure.

🖋️ Make the Score Font More Readable

The score text was a little too small. If you’re using dvui, here’s how to adjust it:

Thanks to code sample from milogreg

You may also need to adjust the width and height of the container if the larger font gets clipped. In our case, font size of 64 felt about right.

🧱 Fix the Ball Getting Stuck in the Paddle

When the ball moves too far in one frame, it can land inside the paddle and bounce back and forth infinitely.

This trap happens because we just multiply the x-velocity with -1 to reverse direction.

One way to fix this is to only trigger the bounce if the ball is moving toward the paddle. For example:

Thanks again to code sample from milogreg

This ensures we don’t apply the bounce logic when the ball is already inside the paddle.

Another (potential) way to fix this would be to change the collision logic to fix the x direction based on whether it’s the left or right paddle.

🧮 Trigger a Score When the Ball’s Edge Crosses the Screen

Previously, we checked whether the ball’s center (ball.x) crossed the screen edge. Particularly with the ball being bigger than the paddle, this caused issues when the top/bottom of the paddle hit the ball.

Game.zig

This triggers the score as soon as the edge of the ball crosses the screen bounds.

🔄 Refactor: Move Scores Out of the Paddle Struct

Storing the score inside the Paddle struct is convenient but semantically odd

• paddles shouldn’t own scores. Instead, let’s move them into your Game struct:

Then, pass the score explicitly to the rendering function.

You can find the updated code in Game.zig.

✅ Bonus Fix: Make Score Display Use Paddle Play Area

We now compute each paddle’s play area (a dvui.Rect) and use it to position the score label, keeping layout logic more re-usable.

We add a play_area field or method to our Paddle struct that returns its side of the screen. This makes the rendering logic clearer and more flexible.

⏭️ What’s Next?

Next episode: adding a pause menu to Pong, based on what I just built for my other game, triangle. We’ll add basic Resume/Quit options and freeze game state mid-play.

Links

• Watch Video
• Source Code (at this point)
• Prev: Smarter Collisions & Cleaner Code
• Next: Pause Menu

Extract out Game struct

One of the structural changes I wanted to make to tidy up the code was to pull out the game logic into its own struct. This change helps to declutter the main.zig file, leading the way to add in the dvui scaffolding.

This refactor pulls the update and render logic into a Game struct, which helps declutter main.zig and sets up a better foundation for UI work.

Game.zig

Add dvui dependency

Let’s fetch the dependency, adding it to build.zig.zon:

zig fetch --save git+https://github.com/david-vanderson/dvui.git

Then, in build.zig, we also need to declare it:

and then add it as a dependency:

Add dvui to game loop

We also need to initialise dvui in the main loop.

main.zig

Import

Initialise

Pre-render

Post-render

Show Score

We can now show the score using dvui.label with positioning hardcoded to about 25% and 75% across the screen. There may be a better way to position it but it works well enough for now.

I had to generate an id for the label so that they were unique. I generated it the x-position using @intFromFloat().

Game.zig

Closing

As always, things took a bit longer than expected, but by the end:

• The game’s structure is cleaner
• DVUI is wired up properly
• Scores now show up on screen

Shoutout to milo_greg on ziggit.dev for loads of really valuable feedback and tips. That kind of thoughtful review really helps.

Links

• Watch Video
• Source Code (at this point)
• Prev: Smarter Collisions & Cleaner Code
• Next: Font Size, Collision Bugs, and Refactors

I was going to dive into menus and UI, but after sharing the early version of Pong on ziggit.dev, I got a bunch of helpful feedback. The feedback was the kind that makes you stop and think, ah, right… I should probably fix that before carrying on.

So that’s what this episode became: a collection of fixes, tweaks, and small refactors that clean up the code and align things more closely with how things should be done in Zig (or at least, better than I had them before).

🧼 Naming Matters

I’d originally named my files paddle.zig and ball.zig - lowercase, snake-case. I had tried to find the guidelines around this, but turns out I only got half the story. If a file implicitly defines a struct via top-level fields, it should be named in PascalCase. So, Paddle.zig, not paddle.zig.

It’s a small thing, but one that helps be a bit more idiomatic - and avoids confusion when others are reading it.

(now to make the same change across many more files in triangle)

🛠️ Default Field Initializers (and When Not to Use Them)

Another thing I learned: structs that aren’t used as config objects shouldn’t use default field values. Instead, they should have an init constant that represents their starting state.

I’d missed this distinction, and both of my types were using default values incorrectly. So I cleaned that up and added the values into the init method. It’s a subtle change, but it keeps config objects and plain data objects conceptually separate - and makes it clearer which parts of a struct are supposed to be overridden.

✨ RLS, Please

One of the comments suggested I lean more into Zig’s Result Location Syntax - where you define the type on the left-hand side and let Zig figure out the rest.

I’d been using a mix of styles. Nothing broke, but consistency helps. So I swept through the code and updated those as well.

🎯 Fixing Paddle Collisions on the Y Axis

Now for something more visible: my collision detection logic only checked the center point of the ball along the y-axis. That meant if the ball clipped the paddle at the edge, it was sneaking through.

The fix was simple: add/subtract the ball’s radius in the y-axis check. Much better.

You can actually see the difference in-game - that satisfying little thock now triggers when it should, even on corner hits.

(now I just need add some sounds - I’d forgotten about that)

🧽 isColliding Should Only Collide

Previously, isColliding also handled coloring the paddle red when it detected a hit - a debug leftover that had no place in the final function.

I stripped that out and left isColliding to do just one thing: return whether there was a collision. If I want debug visuals again later, I’ll wrap this in another function.

🔀 Movement Logic Encapsulation

Paddle movement was scattered, and the logic for moving up/down lived inside main.zig. I pulled that out into proper moveUp and moveDown methods on Paddle.

It reads cleaner now:

…and it keeps the input logic in main, but the movement logic in the paddle - where it belongs.

📐 Resolution Independence

Some values were hardcoded (like setting y = 200 for paddle start position), while others used getScreenHeight() and getScreenWidth(). I refactored to make everything use actual screen dimensions, converting i32 screen height values to f32 where needed.

It was a bit fiddly, but worth it. Now Pong should behave properly regardless of window size.

Closing

So, yeah - not the flashiest episode, but a satisfying one. Lots of small things that feel better now that they’re fixed. And it’s a reminder that sharing early (even rough work) is usually a good idea. You never know what you’ll learn.

Next time, we will get into UI. I’m planning to bring in DVUI and show a basic score display, a pause menu, and maybe some options for reset and quit.

Until then, thanks for reading (and watching) - see you in the next one.

Links

• Watch Video
• Source Code (at this point)
• Prev: Ball Movement & Paddle Collisions
• Next: Integrate DVUI & Show Score

🧱 Edge Collisions

We already had paddle collision working, but we needed the ball to bounce off the top and bottom edges of the screen. That meant checking if the ball’s y-position was outside the visible range and inverting its vertical velocity accordingly:

There was a small detour where I realised screen_height wasn’t giving the expected value - using GetScreenHeight() directly from raylib helped resolve that.

🏁 Scoring System

Once edge collisions were in place, it was time to detect goals. If the ball passed the left or right edge of the screen, the opposing player got a point. We also need a reset() method to the Ball struct to return it to the centre after each goal.

For now, let’s print the scores via std.debug.print, but this sets the stage for UI integration.

⌨️ Player Input

Finally, we wired up keyboard input to allow paddle movement. We used IsKeyDown from raylib, and made sure movement was frame-rate independent by scaling it with dt:

Left paddle uses W/S, right paddle uses E/D. Simple and responsive.

✅ What’s Working

By the end of this episode, we’ve got:

• Ball bounces off top and bottom edges
• Scoring when the ball passes a paddle
• Ball reset after each goal
• Both paddles are fully controllable

All that’s missing now is a visible score, a win condition, and maybe a simple menu.

Links

• Watch Video
• Source Code (at this point)
• Prev: Ball Movement & Paddle Collisions
• Next: Code Improvements from Review

Ball Movement

The first step was to give the ball some velocity and update its position every frame.

We also fixed a small oversight: the ball and paddles were being recreated every frame inside the game loop. Moving their initialization outside meant we could actually observe state changes between frames.

Frame-Rate Independence

Raylib provides GetFrameTime() which returns the time in seconds since the last frame. Multiplying the velocity by this dt value ensures that the ball movement stays consistent across different frame rates:

With that, the ball now moves at a steady speed, no matter the frame rate.

Paddle Collision (X-Axis)

Next up: detecting collisions between the ball and paddles. I considered writing a standalone collision checker, but ended up keeping the logic within the Paddle struct itself.

To simplify which edge to check (left or right), I added a which field to paddles - an enum with values left and right. That made the conditional logic much cleaner.

To debug collisions, I added color switching: when a paddle detects a collision on the x-axis, it flashes red.

Paddle Collision (Y-Axis)

After confirming horizontal collision detection, I added vertical bounds checking. This just involved verifying the ball’s y-position is within the paddle’s vertical range.

Bounce Logic

With detection in place, we added bounce logic to the ball. If a collision with a paddle is detected, we flip the x-component of the velocity vector:

What’s Next

That wraps up part 2. In the next episode, we’ll handle edge collisions (top and bottom), scoring, and input management.

Thanks for following along!

Links

• Watch Video
• Source Code (at this point)
• Prev: Place Paddles & Ball
• Next: Edge Collisions, Scoring & Inputs

This post goes alongside my video on YouTube, and walks through the early steps of the project: setting up the game, getting something on screen, and implementing the paddles and the ball.

Why Pong?

Sometimes, before getting deeper into a project, it helps to do something simple just to get your hands moving again. I hadn’t written Zig in a couple of weeks, and wanted a fast feedback loop to:

• Get back into using raylib-zig
• Have a bit of fun
• Remind myself why I made certain decisions in the first place

Project Setup

I’m using raylib-zig for this. You can scaffold a new project with:

For the broader story behind the project - what Triangle is, where it’s going, and why I’m making it - check out the triangle endeavour or the devlog archive. This post is about the how.

🧩 Core Systems So Far

At this stage, Triangle supports:

• Basic player movement and shooting (Asteroids-style).
• Procedurally generated asteroid fields per sector.
• Material drops (iron ore) from destroyed asteroids.
• Automatic recipe unlocking when new items are picked up.
• Smelting system that converts ore to ingots.
• Unlocking and queuing up constructors using the crafting menu.
• A basic UI for crafting and inventory.
• Configurable keyboard mappings using TOML.

That’s the visible layer. Below the surface, the codebase has carved out some space for more ambitious systems.

🗂️ Code Structure Overview

Here’s a quick tour of the key directories and their purpose:

blit/

Handles all the 2D rendering abstractions - bounding boxes, shapes (including triangle fans 😉 and circles), and canvas drawing. Wraps raylib for better namespacing and type control.

phys/

Physics system. body.zig implements basic movement, collisions, and inertia. Still minimal, but usable.

combat/

Still early - only bullet is implemented, and is used to destroy asteroids. Placeholder for upcoming systems like health, damage, and targeting.

items/

This module forms the backbone of the crafting system. Items are tied to recipes, and recipes are triggered via pickups or crafting actions. There’s a lot more to unpack here - likely its own devlog soon.

notifier/

Manages in-game UI feedback. When you pick something up or unlock a new recipe, this is what shows it. Notifiers are scoped - one for inventory, one for crafting - and show up on either side of the screen.

ship/

This module contains the ship related logic, including movement, and the logic for constructing smelters and other buildables. Eventually this will handle assembly chains.

asteroid

These files should be refactored into its own module, and should contain the asteroid itself, as well as sector, a chunk of space - asteroids, entities, bullets, etc. This is the closest thing to a “level” in Triangle. It’s procedurally generated, and you can eventually travel from one sector to the next.

diag/

Code to support diagnostics & logging

game/

This module should get a bit of refactoring as well, moving some of the files from the root into its own module

• config: Takes care of user control bindings and input overrides via a TOML config file.
• notifier: supports collecting notifications across multiple channels.
• save: Just scaffolding for now - no save/load logic yet, but it’s a placeholder to group serializable components together.
• context: container struct to support dependency injection.

ui/

Holds in-game panels like crafting and inventory. Needs cleanup and consolidation.

🧪 What’s Missing

A lot of the systems are stubbed out, but not yet wired in. For instance:

• power is empty (future energy system)
• The canvas currently wraps raylib without adding much - that will likely change as UI complexity grows.

🧶 Threads I’ll Pull Next

These are the next things I’ll either build or record:

• Improving the coding structure. I’d like to improve organisation and am considering extracting a re-usable library out of it, mainly so I can tinker with other smaller game projects.
• A rudimentary menu system
• A build+deploy system to generate early test builds
• Possibly a contact/feedback form directly in-game or on the site

I’ll be releasing this in what I’m calling a “Sprout” build - a playable seed, a form of extremely early access. Feedback and collaboration is really important to me and I want to get this out there as soon as there is the tiniest spark of “life.”

If you’d like to follow the journey, you can watch the video devlog

As a starting point, my keyboard layout is colemak, and I doubt that the controls I use would suit the majority of players.

I am putting off a UI based config management option down the road (did I mention that I do not enjoy GUI work?). As such I’ve been pondering alternative configuration options.

Platform independence

Before I even get to that, the first problem I need to solve is a way to determine the location for the config files independent of the platform.

Fortunately, known-folders came to the rescue and provided an easy to use framework that can be used to determine the various relevant locations for multiple platforms.

Locations

There are three real locations of relevance for triangle

• The binary / package
• Config, technically, split into two
  • user (or in Windows parlance, the remote dir, and can be shared across computers)
  • system (in windows parlance, local, and is specific to that system)
• Save Data

User & Game Config Files

With that sorted out, the next bit is to identify the relevant config files. I expect that triangle will continue to use these, and will eventually just get a UI config option as well.

User Config

There are two main bits of user configuration

• Preference like controls
• System details like resolution

I am currently unsure when it’ll support system config.

Game Config

There are two bits of config that the game will store. One set of config is to remember game choices the user has made.

Remember Player Actions

For example, it will be useful to show the user details of changes to the game since they last played. To do this, we need to track the last set of changes that the user saw.

The game will show a notice on startup about its extremely early access status, and provide an option for the user to hide that in the future. We need to save that somewhere too.

Telemetry

The second bit of config is metrics. While a lot of games will simply send telemetry information directly to the developer, player privacy is really important to me. I recognise that I will get far less data because of this, and that there will be a bit of survivorship bias with the data - but I feel that privacy is more important.

The way I want telemetry to work is that it will all be saved in a human readable telemetry file in the config file location.

The data is stored only locally, and is never automatically sent. The player is welcome to use this data for themselves if they wish and also share at their discretion. The information will be stored in a human readable format that should be as easy to understand as possible - no data dumps.

The location will also store logs (if enabled).

Setting Config

In terms of allowing the player to manage config, there are a couple of challenges:

• Providing enough documentation that it is easy to do
• Allowing for updates, particularly to the addition of new keys

To tackle this, I am going to provide an annotated template file with all the config options. The user can create a separate file based on this with only the config they wish to override.

It will be tricky to change how particular parameters are configured. E.g. If a single value key needs to switch to an array. I’d be loathe to sprinkle the code with checks for legacy keys/formats. We’ll play it by ear.

I considered updating the config file automatically, but this would discard any comments the user had added. While I could offer an option to merge changes in, it’s not straightforward enough to implement just yet.

Format

I’ve been considering toml and yaml for this, with zig-toml and zig-yaml respectively.

zig-yaml seems to be more active (more stars, forks, issues and pr’s and currently also the more recent commit).

I am also more familiar with and prefer yaml.

However, it does not currently support default values. I would like the user to have to specify only the config they’d like to override. zig-yaml currently expects all the keys to be defined if you want to parse it into a struct.

#85 should bring it in, but I could not get it to work

So, I tried out zig-toml and the test worked the first time.

src/toml_with_defaults.zig

Using the config

The final part is to use the config.

Loading config

All config is loaded at startup and attached to a Config struct, which is in turn part of a Context struct that is passed around.

src/load_save_config.zig

User config (controls)

This one involves a little translation as we need to know the rl.KeyboardKey for each mapping to be able to detect it.

I use a std.StringArrayHashMapUnmanaged(rl.KeyboardKey) to map the string to each key

src/load_save_config.zig

Game Config

As a starting point, we’ll probably only have one config entry here - the last time the news was marked as read by the player.

We’ll store this as an i64 and loading it is exactly the same as above.

The main difference with the Game config class is that on writing any value, it will also save it to disk.

I ran into a bug where the api for serialization was broken. There is (currently) a pending pr #33 to resolve it

One of the challenges of using emerging language and ecosystem is that you’re more likely to run into bugs. One of the great joys of working with such ecosystem is the greater opportunity to contribute and get involved!

Links

• YouTube Devlog
• Prev: Crafting Machines

The Ship

Spawning the ship itself was relatively straightforward. I only needed three points and drawTriangle from raylib.

In the coding challenge, the ship was rotated with the keyboard, but I wanted the ship to point to the mouse so that aiming was straightforward. Rotating to the mouse was trickier — it involved atan2 and ChatGPT got me started.

The coding challenge video did not worry about time lapsed between each frame, but I wanted triangle to be framerate independent. That involved a bit of jiggery pokery to get working, including determining how much the ship can move within a time frame.

Moving the ship was a bit easier, but based on the many videos of the Coding Train that implemented force, velocity and dampening, it was pretty straightforward. Dampening took a bit of trial and error. ChatGPT sent me down the garden path initially with an over-complicated formula, but I was able to simplify it later.

Integrating the physics for linear momentum with the one for rotational momentum was also quite nice — it meant that the ship could overshoot the aim when rotating and will correct back.

The Asteroids

The coding challenge worked with a fixed number of on screen asteroids and they wrapped around. I needed to expand this to:

• A potentially infinite vertical scroller.
• Collisions between the asteroids (currently the same as from the challenge, only checks full circle collision)
• Figure out how to handle asteroids moving out of the screen

The above will be covered in a bit more depth in the next devlog.

The Camera

I also needed a follow camera. Unlike the original asteroids, the ship can move up/down and the camera should follow it.

The current code looks something like this:

It predicts the position of the ship, based on its y velocity. If that’s outside the middle zone, it’ll move the camera at up to the maximum speed. There is some clamping to prevent things flying off at high speeds. It also prevents the camera from overtaking the ship.

This code is mostly hacked together with some help from ChatGPT. It’ll be cleaned up later, once I have a better indication of possible ship speeds, and how/if we’ll zoom in and out as well.

Another important facet to consider with the camera was what to do with the edges. Out of the four edges, only one is infinite.

The current solution is that the camera stops tracking when it gets to the “bottom.” It also does not move to the left or right. The ship, on the other hand is free to move out of the range of the camera. Currently, nothing changes except that the camera does not follow.

Since the thrust works in the direction of the mouse, it’s pretty easy to bring the ship back on to the screen. This feels like the world is big and still out there, we just don’t track what happens out there.

I considered wrapping around on the left and right, but that felt more like the ship was trapped in that zone. I want the feeling of being trapped in vengeance to be more subtle ;)

Combat

Combat is pretty much a mirror image of what happens in the coding challenge, though I didn’t have some of the helper functions. I learned some math :)

Initially, the update loop only handled asteroid collisions. I added bullets as a separate field in the update loop. It then checks each bullet with every asteroid in the active chunks (covered in devlog #2).

If there is collision, the asteroid is split into two, moved apart a bit, and given opposite linear momentum. The bullet also takes “damage” at this point, and can be removed. The damage system is designed to support penetration, which is currently not active.

If the spawned asteroids would be too small, nothing is spawned. Later on, this would be the trigger to spawn a material drop.

Zig / Raylib

Learning zig and raylib was a big part of this. Fortunately, both were a lot of fun to learn and work with.

One thing I found annoying was that the vector functionality in raylib was scattered around as individual functions instead of on the vector struct. While this was understandable, with raylib being written in C, I found it a bit frustrating.

I ended up writing my own Vector struct in zig and the functions that I used as methods on that struct. It was an opportunity for me to learn some vector math as well.

I also encapsulated raylib inside a Canvas struct. I probably still have some rl. calls other places in the code, but the idea is that a canvas is passed into any bits of code that needs it. The main help is that it’ll convert our version of Vector2 to the one that raylib wants.

I am also thinking about how I want input handling to work. I would like to encapsulate that into a separate struct. Right now, I mainly access raylib directly.

Manual testing

While I am a big proponent and fan of Test Driven Development, I was happy enough with manual testing for triangle. I found joy in seeing it work each time I manage to get something working.

I do end up writing tests later, particularly when I got to bits of code that was harder to test manually.

Feel

triangle already feels fun and light. There are some clunky elements to be ironed out, but so far, it feels good :)

Other posts

• Companion vlog for this post
• Prev: A lone triangle vs the universe
• Next: Procedural Asteroid Field

My youngest uncle was a Computing Studies teacher at a local college. He also taught private classes at home. I couldn’t get enough.

I don’t know what most ten-year-olds dream about, but my dream was to learn C. I saved ₹300 - a lot of money in 1994 - to buy a book called Encyclopedia C. I read it cover to cover, understood maybe 10% of it, and reread it years later to pick up more.

But I never actually programmed in C.

The Long Detour

Life took me through a range of other languages instead: Prolog (strangely, what my school machines had), Visual Basic, ASP, PHP, Java, Python, JavaScript, Go, Rust. I tinkered with C++ when messing with game engines, but never quite got around to C.

Some of the early fears carried through - memory management was intimidating: malloc, free, and in C++, new and delete.

Over time, I began to overcome the fear of systems languages - first through Java, then Go. But I never revisited C, and I never quite got over the fear of manual memory management.

In hindsight, these concepts weren’t really designed for a ten-year-old to grasp. It makes sense that they felt out of reach.

Allocator Confusion

Zig had me curious for a while, and some recent health issues gave me the space to explore it. I’ve been building a small game in Zig, and it’s been feeding that original desire to learn C - just with a bit more clarity.

I was still intimidated by memory allocation though, and went as far as I could without using an allocator.

Eventually, I had to use one. I understood the convention of init and deinit, and the idea of allocators in general.

But I was confused about how deinit worked in the context of ArenaAllocator.

A little learning is a dangerous thing

– Alexander Pope

If the arena frees memory for you, wouldn’t calling deinit on individual objects inside it risk double-freeing?

If I skip calling deinit on a struct that normally needs it, will I miss other cleanup tasks?

And does this mean the arena allocator isn’t a true drop-in replacement if I have to skip deinit?

At the time, the answer wasn’t clear - and I couldn’t find documentation that resolved it.

Clarity

Thankfully, the super friendly folk at Ziggit helped clarify things.

ArenaAllocator handles it

ArenaAllocator is a drop-in replacement for other allocators. If you deinit objects using memory from the arena, and those objects try to free that memory, the operation is effectively (though not exactly) a no-op. There’s no risk of double-free.

It’s always safe to free / destroy memory from an arena, as long as you treat it as freed of course. But it won’t actually be released until the arena is deinit’ed.

– mnemnion

Even if some memory is freed manually before the arena is cleared, it’s handled safely.

I was overthinking it.

deinit should still be called

deinit exists for cleanup logic - not just memory. It should always be called where appropriate, regardless of the allocator. That part doesn’t change.

Further learning

Zig also encourages a light touch. One of the impacts of this is that the object itself should not hold on to the allocator in the init and use it in deinit. It could, but the better way would be to accept the allocator in both the init and the deinit.

This convention is further reinforced by zig deprecating the managed variants of collections

Thanks

In many ways, this was about cleaning up more than just memory.

Special thanks to the helpful folks at ziggit.dev.

References

• Full discussion on ziggit.dev
• Implementation of ArenaAllocator