I’ve done a lot last week, but haven’t quiet finished it, so I’m only going to talk about the other stuff I’ve done this week. I’ll wait until next week to talk about everything else.

I started by adding in some gameplay components. Things like Skill, Person, MaidenName, Single, Partner, and Random.

Skill is just an enumeration of the different skills that a person could have. The thought is it have a maximum of say eight skills per person and that will direct them towards a particular job or role in the city. Random is another easy one. There may be a lot of things that are going to be random on a person, for example, what color clothes they are wearing. I’ve encoded this into a single random 128 bit number. Different parts of the code can therefore grab some random bits out of this random number and use that as the random value they need.

Last week, we started to think about curves. This week, we’ve mostly finished the curves in roads. There is still one thing to be done, which is reducing the radius of the curve to make it fit the space available, but this should not be too difficult, so can wait a bit.

However, to complete the curves, we had to add a clockwise argument to the draw_arc function.

const direction: f32 = if (clockwise) -1 else 1;

var angle: f32 = start;
const sweep: f32 =
    if (clockwise)
        @mod(start - end, std.math.tau)
    else
        @mod(end - start, std.math.tau);

const segments: usize =
    @max(3, @as(usize, @intFromFloat(num * sweep / std.math.tau)));

The important thing here is that the number of segments to draw should be related to the angular sweep from the start angle to the end angle. Once that is calculated, the way we draw the arc is pretty much the same as before.

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.