November 2025

This month I managed to align quite well with the goals I setup for myself last month. I released a package of goodies that I can use for prototyping and I gave my synth an actual GUI. But there were plenty of side quests this month.

Wayland

Thanks to updating some packages I hit a very frustrating issue with GLFW. I use Wayland on my machine and GLFW deals with all window related stuff. For some unclear reason I got a weird stretchy letter box, which I figured must be related to the window management.

I consulted ChatGPT which wasn’t much help and it ended up blaming me and my code instead. I also tried out SDL, which didn’t have the issue, so I started to suspect some bug in GLFW. It tickled that part of the brain and I got curious whether I would be able fix it. However, I quickly realized I knew nothing about Wayland,

What better way to learn about something than doing it yourself? After reading about protocols, compositors, scanners, etc. I managed to piece together my own window handling. It’s not as nice and feature complete as using something like GLFW, but it works!

Someone managed to figure out a workaround for the GLFW issue so I could revert back to GLFW again. It’s very nice feeling to understand the code underneath you though, so I will probably stick with my own solution (until the day I need to support more platforms).

GUI

One issue solved, on to the next. I continued experimenting with my own immediate mode GUI. It’s very rewarding to work on as you see the results directly in front of you, but some things sure looks easier than they actually are.

One problem I looked into was layouting. The prototype I had before was a lot of just hand-feeding absolute positions to into a draw list. I wanted something more automatic, but how do you layout something without knowing the full picture beforehand. One example I encountered was determining the size of a panel. You queue a panel, then you queue the contents of the panel, and not until this is done do you know the size of the panel. I just opted for a 2 pass approach where I don’t render things directly, so I can update the panel command as soon as I know its actual size.

Talking of order of draw commands, another challenge is dealing with popups like dropdown menus. Luckily I know beforehand that I only need to support one level of overlapping elements so I went with just having a separate command queue that I ensure is drawn on top of everything else.

This blog post was a very interesting read on the subject.

Fonts

Initially I just had hardcoded bitmasks representing characters. It was fine for just uppercase letters and some special characters but it quickly got messy. Since I wanted to use the GUI in the game as well, I figured I should add proper fonts.

I didn’t really feel like writing my own truetype rasterizer or even depending on an existing one in the library itself so I added a pre-baked atlas instead. It’s basically just a TGA image and a ZON file. I picked TGA because its one of the simpler parsers to implement but I can still use it in most other software the deals with images. ZON I picked mostly because I like being able to just @import the data file.

Fonts are tricky, I’ve went for pixely font hoping it would be a bit simpler but there were still some challenges getting it to look right, like aliasing.

Zig Package

All this work went into an package I just call simeks-zig (in lack of a better name). This package is basically a set of tools mainly for myself to implement things like the synth. It’s provides a set of modules

• core: Various core tools
• gpu: Vulkan wrapper for graphics, it provides some high level concepts on top of Vulkan, such as a less verbose API and limited resource management.
• gui: GUI libray mentioned above.
• math: Math library
• os: For now only the window wayland wrapper.

They are far from complete but it’s a place for me to collect various things that I might need.

Synth

Using the package I managed to get a GUI going for the synth project with ease. I also played around with adding an envelope for the volume and some filtering. It was nice to have a smaller project to work against when setting up the package.

Game

I moved over the game project so that it now runs without zglfw and zgui. This is really nice as I’ve learned that trying out new Zig features is a bit tricky when having dependencies. I’ve helped a bit trying to keep them up to date with new Zig releases but sometimes you just want to quickly try something out on a Zig dev build. I’ll likely migrate back when things get more stable but I will enjoy the freedom while I can.

Migrating wasn’t that difficult, I only had a few contact points for third party libraries and the gpu module is basically the same one as I was using in the game already.

I did however decide to rehaul my hot-reloading a bit. It was a bit of a long shot and I haven’t gotten so far to determine if it was a success or not. The issue with my previous system was that it got very frustrating to deal with the layer between the host (executable) and the game (reloaded .so). It was an annoying barrier and putting something on the wrong side would cause a lot of pain down the line.

The idea I had now was to put as much as possible within the reloadable module. Just allocate the memory in the host and as you reload you just patch the memory in the new module. Can’t be that hard as long as I never change the memory layout?

Boy was I wrong. I spent a lot of time getting it to work, and I still have random failures every now and then. Some of the issues I encountered:

• Function pointers: VTables are commonly used with interfaces in Zig, such as in the Allocator, and they are problematic since they might point to functions in the library you just unloaded.
• Global variables: This is mostly my fault, but if you have global variables in a module you will have to patch these as well.

So we’ll see how this goes. There are more clever ways of doing this but not sure how much time I’m willing to put into this.

What’s next

Sebastian Aaltonen is currently working on a hobby project very similar to mine and he posts about it on X. This has really re-ignited the voxel flame so I hope to work more on that. But Christmas and Advent of Code is coming up so I’m certain I won’t be bored!