I spent most of last week creating a new graphics library for drawing lines, circles, and quadratic bezier curves. This week, I’m ignoring the bezier curve bit whilst drawing roads. This is the problem with going too far ahead with the implementing side of things and not far enough with the thinking side of things.

I want to be able to draw roadways. And paths, canals, railways, and other transport infrastructure. I thought we would be doing this using quadratic bezier curves, just like most other games would do. However, I’m not currently convinced that this is the best way. You see we need to do three different things:

It feels like it has not been a very productive week this week. Mostly due to things happening in real life and not having the time or energy to do much work on fourth. This can be seen in the number of lines added this week:

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Zig                             31           1787           1568          14164
-------------------------------------------------------------------------------

Last week we were at 13912 lines of code. This week we’ve added only 252 lines of code. If we consider a standard five day week for working, this is only 50 lines of code a day. This code isn’t even that spectacular. But, next week, I hope to have a car that works, and a fridge/freezer that freezes and fridges things. Until then, life is a little less civilized at home.

Yes, premature optimization is the killer of all good programming projects, but it’s my project and therefore I can do what I want!

Firstly, we need some way to measure the performance of the system, because without knowing how things have improved it is mostly impossible to know if any performance improvements have worked. This is just a simple case of creating some benchmark tests.

Some interesting things to note here. The first run of any test will be mostly pointless as we would be more likely to be measuring the memory bandwidth of the code execution path and not the actual speed of any code we are benchmarking. We also want to do things more than once, because then any variation in what the system is doing, for example me typing on the keyboard in neovim could impact on the benchmarking, so we run it a number of times and find the iteration that runs the quickest. No, we don’t care about averages in these sort of tests, we just want to remove as many variables are possible like being task switched.

When writing software I like to do an implementation and then if we need to optimize it later, then we do that later. You don’t write software quickly if the first thing that you are doing is optimise first. When you hear the letters ‘ECS’ many people think about data oriented design and highly optimized processing of data. Yes, this is one possible reason for doing ECS, but it is not the primary reason that I’m using this design pattern.

It’s been a busy week. I’ve started three big things. First was starting to create an entity component system. I’m not going to talk about that much here, because it is nowhere near functional. I can create and destroy entities, and I can assign components to those entities. But there are no systems yet, which is a pretty much necessary part of an ECS, unless you just want to call it an EC!

It has been a bit of a week. I’ve only added about 6651 lines of code this week. Most of these lines are not code, but I’ll explain later.

First, we have to talk about uniforms. In the graphics world, the concept of a uniform is a very small bit of data that is used by a vertex or fragment shader to do a lot of work. For example, if we wanted to have a triangle rotating around the screen we could do all the math on the CPU and update the buffers that describe the triangle every frame. This is both a lot of math for a CPU to do, and also a lot of memory that has to be copied between the CPU memory subsystem and the GPU memory subsystem. These are different blocks of memory and are only connected by a slightly wet piece of string, typically called the PCIe bus by most people.

Productivity is always highest on day one when there are no problems to solve and no bugs to fix.

Well, I’ve decided to start up a little blog to discuss what I’ve been doing. I started this at about 10pm at night on the 15th February 2025. What is this project? Difficult to know at this point, but I have this little idea in my head that could become a game, or just a tool for others to be able to use, but I’d like it to be a fun thing to play with and therefore could become a game.

One of the lovely things about Zig is the way that you can just create types at compile time and then use these types elsewhere in your code. The other day, I needed a sparse array, but the standard library didn’t really have what I wanted. I could have used one of the hash-map types, but that wasn’t really what I wanted, so I created my own.

pub fn SparseArray(IndexType: type, DataType: type) type {
}

The first thing I did was create a function that returns a type and takes in the types that I’d be using for the index and data types.

Creating a list of primes takes a long time. This is especially true if you are using the very boring and simple sieve algorithm. In Zig, this is really easy to do:

pub fn calculate_prime_numbers (comptime size: usize) std.StaticBitSet(size) {
    var sieve = std.StaticBitSet(size).initFull();
    sieve.setValue (0, false);
    sieve.setValue (1, false);

    const last: usize = @intFromFloat(@sqrt(@as(f64, @floatFromInt(size))));

    for (2..size) |n| {
        if (sieve.isSet(n)) {
            results.set(n);
        }
        var i: usize = n * 2;
        while (i <= last) : (i += n) {
            sieve.setValue(i, false);
        }
    }
    return results;
}

The code is really simple. It creates a sieve set, initially full, except for the number 0 and 1. It then looks through from the number 2 up to the square root of the size parameter given, and then looks at the sieve set to see if the bit is set. If it is, then it goes from double the current number up to the size parameter jumping by the current number, and clears the sieve bits, effectively removing all the multiples of the current number as not prime for future iterations.

I have a theory that when writing software, you will do the best work only after you have written it for the third time. My hypothesis is that the first time you write it, you don’t really know what the problem is and therefore are just stumbling in the dark trying to find your way. The second time you now understand the problem domain but you haven’t worked out the best way to implement it yet. And then the third time you not only know the problem domain but understand the implementation constraints and therefore can create some of your best work.