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.