James Randall

Building a Real-Time Path Tracer in WebGPU

Sun, 08 Mar 2026 00:00:00 +0000

Having built a raycaster for my Wolfenstein 3D recreation I wanted to take things to the next level and build a “simple” ray tracer. The result is a real-time path tracer written entirely in WebGPU compute shaders, running in a browser, rendering levels loaded from actual Doom WAD files. No hardware ray tracing cores, no ML denoisers, no engine — just maths, triangles, and a GPU doing a LOT of work.

But when you try and figure out what happens when you fire a ray of light from a virtual camera into a scene made of triangles it turns out things get complicated fast. You get physically correct lighting — soft shadows, colour bleeding, natural falloff — the kind of rendering that looks right in a way that traditional rasterisation never quite manages. You also get noise, performance problems, and a sharp reminder that even a £1,600 GPU can’t brute-force the physics. In fact it still can’t even come close.

This post walks through the construction of that renderer: from the rendering equation through BVH acceleration, Monte Carlo importance sampling, temporal accumulation, and spatial denoising — everything needed to go from a single noisy ray to a converged image. The Doom WAD loader parses the original 1993 level geometry and rebuilds it as a triangle mesh that the path tracer can chew on, which means you can wander through E1M1 lit by nothing but a handheld torch and physically correct light transport. The renderer is embedded below — you can interact with it directly. These demos are computationally expensive and so you’ll need to press PLAY first — I didn’t want the first thing you knew about these interactive demos to be fan noise! If it runs really slowly… drop the resolution. On my Mac I get 60fps with these defaults.

I’m not going to pretend this came out as a coherent whole. Getting a simple scene on the screen was (relatively) simple but I’ve backed and forthed with denoisers, different optimisations, tweaking numbers, chunking things differently - the list is endless. I started tinkering with it a couple of months ago. Even writing it all up took an age.

I was learning as I went and rewriting and rewriting code with the help of an LLM. Its been fascinating and the slightly messy code is the result of that learning process - but that learning process hopefully helps me explain how it works and why realtime path tracing without tricks is still a pipedream on a GPU.

In any case - I hope I’ve done the topic justice.

The Rendering Equation

Every pixel on screen represents a measurement of light. The question is: how much light arrives at the camera through this pixel? The answer is the rendering equation, introduced by James Kajiya in 1986:

$$L_o(\mathbf{x}, \omega_o) = L_e(\mathbf{x}, \omega_o) + \int_{\Omega} f_r(\mathbf{x}, \omega_i, \omega_o) \, L_i(\mathbf{x}, \omega_i) \, (\omega_i \cdot \mathbf{n}) \, d\omega_i$$

In plain terms: the light leaving a point $\mathbf{x}$ in direction $\omega_o$ is the light emitted at that point, plus all the light arriving from every direction in the hemisphere above the surface, scaled by the material’s reflectance function and the angle of incidence.

That integral over the hemisphere is the hard part. There’s no closed-form solution for arbitrary scenes — you can’t solve it algebraically. Instead, we must estimate it by random sampling: fire rays in random directions, see what light they find, and average the results. This is Monte Carlo integration, and it’s the foundation of everything that follows.

And I’m not going to lie: I’m not a mathematician (I know just enough to be dangerous and can usually get there, I just have to frown a lot) and had to go round this loop a few times before I understood what was happening. It took me a while to appreciate that you can’t solve it as such, you have to approximate it. I got there by back tracking from the noise. Why the noise.

Anatomy of a Ray

A ray is defined by an origin point and a direction:

$$\mathbf{r}(t) = \mathbf{o} + t\mathbf{d}, \quad t > 0$$

For the primary ray — camera to scene — the origin is the camera position and the direction is computed from the pixel coordinates and the field of view:

fn generate_ray(pixel: vec2f) -> vec3f {
  let aspect = camera.resolution.x / camera.resolution.y;
  let fov_scale = tan(camera.fov * 0.5);

  let ndc = vec2f(
    (2.0 * pixel.x / camera.resolution.x - 1.0) * aspect * fov_scale,
    (1.0 - 2.0 * pixel.y / camera.resolution.y) * fov_scale
  );

  let forward = normalize(camera.direction);
  let right = normalize(cross(forward, camera.up));
  let up = cross(right, forward);

  return normalize(forward + right * ndc.x + up * ndc.y);
}

The pixel coordinates are mapped to Normalised Device Coordinates (NDC), scaled by the field of view and aspect ratio, then transformed into a world-space direction using the camera’s orientation vectors. Each pixel gets a slightly different direction, creating the perspective projection.

Finding What a Ray Hits

Once we have a ray, we need to find the closest surface it intersects. Every surface in the scene is made of triangles, so this reduces to: for each triangle, does this ray hit it, and if so, at what distance $t$?

The standard ray–triangle intersection test is the Möller–Trumbore Algorithm. Given a ray $(\mathbf{o}, \mathbf{d})$ and a triangle with vertices $\mathbf{v}_0, \mathbf{v}_1, \mathbf{v}_2$, we compute:

$$\mathbf{e}_1 = \mathbf{v}_1 - \mathbf{v}_0, \quad \mathbf{e}_2 = \mathbf{v}_2 - \mathbf{v}_0$$$$\mathbf{h} = \mathbf{d} \times \mathbf{e}_2, \quad a = \mathbf{e}_1 \cdot \mathbf{h}$$

If $a \approx 0$ (the squiggly equals means approximate), then the ray is parallel to the triangle. Otherwise, we compute the barycentric coordinates $(u, v)$ of the intersection point:

$$f = \frac{1}{a}, \quad \mathbf{s} = \mathbf{o} - \mathbf{v}_0$$$$u = f(\mathbf{s} \cdot \mathbf{h}), \quad \mathbf{q} = \mathbf{s} \times \mathbf{e}_1, \quad v = f(\mathbf{d} \cdot \mathbf{q})$$$$t = f(\mathbf{e}_2 \cdot \mathbf{q})$$

If $u \in [0, 1]$, $v \in [0, 1]$, $u + v \leq 1$, and $t > 0$, we have a valid hit. The barycentric coordinates (ahh my old friend, I first came across these while working on Wolfenstein, not surprising given its a raycaster and this is a path tracer, and now they seem to pop up everywhere) also let us interpolate texture coordinates and normals across the triangle surface.

fn intersect_triangle_uv(ray_origin: vec3f, ray_dir: vec3f,
                          v0: vec3f, v1: vec3f, v2: vec3f) -> TriangleHitResult {
  var result: TriangleHitResult;
  result.t = -1.0;

  let edge1 = v1 - v0;
  let edge2 = v2 - v0;
  let h = cross(ray_dir, edge2);
  let a = dot(edge1, h);

  if (abs(a) < 0.00001) { return result; }

  let f = 1.0 / a;
  let s = ray_origin - v0;
  let u = f * dot(s, h);
  if (u < 0.0 || u > 1.0) { return result; }

  let q = cross(s, edge1);
  let v = f * dot(ray_dir, q);
  if (v < 0.0 || u + v > 1.0) { return result; }

  let t = f * dot(edge2, q);
  if (t > 0.0001) {
    result.t = t;
    result.u = u;
    result.v = v;
  }
  return result;
}

This is elegant and fast for a single triangle, the problem is that a scene can contain thousands of them.

The Brute Force Problem

The naive approach is to test every ray against every triangle. For a scene with $N$ triangles and an image of $W \times H$ pixels, each with $S$ samples and $B$ bounces, that’s:

$$\text{Tests} = W \times H \times S \times B \times N$$

For our dungeon scene at 1280×800, 4 samples per pixel, 4 bounces, and 3000 triangles:

$$1280 \times 800 \times 4 \times 4 \times 3000 = 49{,}152{,}000{,}000$$

Forty-nine billion intersection tests per frame. At maybe 1 nanosecond per test, that’s 49 seconds per frame. Not exactly real-time. Though that said it still renders faster than a Mandelbrot on my BBC Micro - which is kind of astounding!

Bounding Volume Hierarchies

The solution is to not test most triangles but to find a way to organise them so we can test far fewer. A Bounding Volume Hierarchy (BVH) organises triangles into a tree of axis-aligned bounding boxes (AABBs). Each node contains a box that tightly encloses all the triangles in its subtree. Before testing any triangles, we test the ray against the box. If it misses the box, we skip the entire subtree — potentially thousands of triangles — in a single cheap test.

You’ll come across similar spatial organisation strategies everywhere.

Ray–AABB Intersection

Testing a ray against an axis-aligned box is much cheaper than testing against a triangle (again shades of Wolfenstein which is naturally axis aligned given its grid based maps). We compute the entry and exit distances along each axis:

fn intersect_aabb(ray_origin: vec3f, ray_dir_inv: vec3f,
                  box_min: vec3f, box_max: vec3f, max_t: f32) -> bool {
  let t1 = (box_min - ray_origin) * ray_dir_inv;
  let t2 = (box_max - ray_origin) * ray_dir_inv;

  let tmin = max(max(min(t1.x, t2.x), min(t1.y, t2.y)), min(t1.z, t2.z));
  let tmax = min(min(max(t1.x, t2.x), max(t1.y, t2.y)), max(t1.z, t2.z));

  return tmax >= tmin && tmin < max_t && tmax > 0.0;
}

Note ray_dir_inv — the reciprocal of the direction, precomputed once per ray. This avoids a division per axis per box test.

Building the Tree

The BVH is constructed on the CPU using the Surface Area Heuristic (SAH). At each node, we evaluate every possible split position along each axis. The cost of a split is:

$$C = C_{\text{traversal}} + \frac{SA_L}{SA_P} \cdot N_L \cdot C_{\text{intersect}} + \frac{SA_R}{SA_P} \cdot N_R \cdot C_{\text{intersect}}$$

Where $SA_L, SA_R, SA_P$ are the surface areas of the left, right, and parent bounding boxes, and $N_L, N_R$ are the triangle counts in each child. We pick the split that minimises this cost. The surface area ratio estimates the probability of a random ray hitting each child, so the heuristic minimises the expected number of intersection tests.

The tree is flattened into a contiguous array for GPU consumption. Each node stores its AABB bounds plus either child indices (for internal nodes) or a triangle range (for leaves). A high bit flag distinguishes the two:

struct BVHNode {
  min_bounds: vec3f,
  left_child_or_first_tri: u32,
  max_bounds: vec3f,
  right_child_or_count: u32,   // High bit set = leaf
}

Walking the Tree

Traversal uses an explicit stack on the GPU as we can’t use recursion in WGSL compute shaders:

fn trace_bvh_accel(ray_origin: vec3f, ray_dir: vec3f) -> HitInfo {
  var closest_hit: HitInfo;
  closest_hit.t = 1e30;
  closest_hit.hit = false;
  let ray_dir_inv = 1.0 / ray_dir;

  var stack: array<u32, 32>;
  var stack_ptr = 0u;
  stack[0] = 0u;  // Start at root
  stack_ptr = 1u;

  while (stack_ptr > 0u) {
    stack_ptr -= 1u;
    let node = bvh_nodes[stack[stack_ptr]];

    // Skip if ray misses this node's box
    if (!intersect_aabb(ray_origin, ray_dir_inv,
        node.min_bounds, node.max_bounds, closest_hit.t)) {
      continue;
    }

    if (is_leaf(node)) {
      // Test each triangle in this leaf
      for (var i = 0u; i < get_tri_count(node); i++) {
        let verts = tri_verts[node.left_child_or_first_tri + i];
        let hit = intersect_triangle_uv(ray_origin, ray_dir,
            verts.v0, verts.v1, verts.v2);
        if (hit.t > 0.0 && hit.t < closest_hit.t) {
          closest_hit.t = hit.t;
          closest_hit.hit = true;
          // Store triangle index and barycentrics...
        }
      }
    } else {
      // Push both children, nearest first
      // (ordered traversal for better early termination)
      // ...
    }
  }
  return closest_hit;
}

The closest_hit.t threshold is critical: every time we find a closer hit, the threshold tightens, and subsequent AABB tests reject more nodes. Visiting the nearest child first (ordered traversal) maximises the chance of finding a close hit early, which maximises the pruning of the far child.

Visualising the BVH

The debug visualiser makes traversal efficiency visible. The heatmap mode colours each pixel by how many BVH nodes were visited — cool blues for efficient rays, hot reds for expensive ones. You can try it out below, its worth experimenting with the different scenes and visualisations. The debugger will start in windowed mode so you can see the scene and its BVH simultaneously, but you can also overlay it.

Notice how rays that pass through the dense cluster of cubes on the right are more expensive (warmer colours) than rays hitting the well-separated cubes on the left. Same number of triangles, very different traversal cost, purely because of spatial arrangement.

The wireframe mode shows the bounding boxes at each level of the tree. Step through the depths to see how the BVH recursively subdivides space:

At depth 0, one box surrounds the entire scene. At depth 1, the first split separates the room roughly in half. By depth 4 or 5, individual objects have their own tight boxes and the spatial partitioning follows the geometry closely.

The diagonal slab cutting across the scene is deliberately pathological — its AABB spans nearly the entire room, overlapping everything. The heatmap shows the cost: rays near the diagonal visit more nodes because the BVH can’t exclude it from any spatial query. This is why axis-aligned BVHs struggle with geometry that doesn’t align with any axis.

A BVH Per Tile: Making the Player’s Torch Work

Everything described so far assumes a static scene — the BVH is built once on the CPU, uploaded to the GPU, and never changes. That works for the Cornell box and the BVH teaching scene. But in the dungeon the player is a light source, they’re carrying a torch and can roam around the dungeon.

The torch itself is straightforward: it’s passed to the shader as a set of uniforms — position, colour, radius, falloff — and the path tracing loop treats it as a point light at the camera position. No geometry, no emissive triangles, just a light that happens to be wherever the player is standing. But the problem is the BVH.

A single global BVH contains every triangle in the dungeon. For a 16×16 tile map that’s around 3,000 triangles — walls, floors, ceilings, torch panels. But the player’s torch has a finite range. Light from a handheld torch doesn’t illuminate walls four rooms away. Most of those 3,000 triangles are irrelevant at any given moment, and the BVH wastes time testing nodes that enclose distant, unlit geometry.

The solution is to precompute a separate BVH for every walkable tile. At initialisation, we iterate over each open cell in the dungeon map and build a distance-culled subset of the scene:

private precomputeBVHsForPositions(): void {
  const positions = this.walkablePositions!;
  const dist = this.renderDistance;
  const distSq = dist * dist;

  for (const pos of positions) {
    // Cull triangles by distance from this tile center (XZ plane)
    const culled: Triangle[] = [];
    for (const tri of this.allTriangles) {
      const d0 = (tri.v0.x - pos.x) ** 2 + (tri.v0.z - pos.z) ** 2;
      const d1 = (tri.v1.x - pos.x) ** 2 + (tri.v1.z - pos.z) ** 2;
      const d2 = (tri.v2.x - pos.x) ** 2 + (tri.v2.z - pos.z) ** 2;
      if (Math.min(d0, d1, d2) <= distSq) {
        culled.push(tri);
      }
    }

    // Build BVH for this subset
    const builder = new BVHBuilder();
    const { nodes, orderedTriangles } = builder.build(culled);
    const flat = flattenBVH(nodes);
    // Store for later swap...
  }
}

The culling is conservative: a triangle is included if any vertex falls within the render distance. This means the BVH for each tile contains only the geometry that could plausibly be illuminated by the player’s torch at that position. A render distance of 10 world units (5 tiles) is enough to capture everything the torch can reach while excluding the far side of the dungeon.

For each walkable tile we store the packed BVH nodes, the reordered triangle data (both hot vertex positions and cold attributes), and the emissive light list — everything the GPU needs, precomputed and ready to upload.

At render time, when the player steps onto a new tile, we detect the change and hot-swap the buffers:

private swapBVHForTile(): void {
  // Find nearest walkable position to camera
  const cx = this.camera.position.x;
  const cz = this.camera.position.z;
  let bestKey = this.currentTileKey;
  let bestDist = Infinity;

  for (const pos of this.walkablePositions!) {
    const dx = pos.x - cx;
    const dz = pos.z - cz;
    const d = dx * dx + dz * dz;
    if (d < bestDist) {
      bestDist = d;
      bestKey = `${pos.x},${pos.z}`;
    }
  }

  if (bestKey === this.currentTileKey) return;

  const entry = this.precomputedBVHs.get(bestKey);
  if (!entry) return;

  // Upload this tile's BVH, triangles, and light list
  this.device.queue.writeBuffer(this.bvhBuffer, 0, entry.bvhData);
  this.device.queue.writeBuffer(this.triangleBuffer, 0, entry.triVertsData.buffer);
  this.device.queue.writeBuffer(this.triAttribsBuffer, 0, entry.triAttribsData.buffer);
  this.device.queue.writeBuffer(this.lightsBuffer, 0, entry.lightData.buffer);
  this.currentTileKey = bestKey;
}

The GPU buffers are pre-allocated to the size of the largest per-tile BVH, so the swap is just a series of writeBuffer calls — no reallocation, no pipeline rebuild. In practice, for our 16×16 dungeon with around 130 walkable tiles, precomputing all the BVHs takes a few hundred milliseconds at startup and the per-tile swap is imperceptible.

The tradeoff is memory: we’re storing ~130 copies of partially overlapping BVH data. For a dungeon this size it’s negligible. For a sprawling open world it wouldn’t scale — you’d want streaming or incremental BVH updates instead. But for a tile-based dungeon where movement is discrete and the render distance is bounded, precomputation is the simplest thing that works, and given everything else going on here I’ll take simple.

You can see this in action in the demonstration below. As you move around the map you’ll see the BVH changing.

Path Tracing

Finding the closest surface is just the beginning. Now we need to compute the light arriving at that surface point — which requires solving the rendering equation.

Monte Carlo Integration and Importance Sampling

Why the integral can’t be solved analytically

The hemisphere integral asks: what’s the total light arriving from every direction above this surface point? For that to have a closed-form solution, you’d need to know the incoming radiance function $L_i(\omega_i)$ everywhere — which itself depends on the geometry of the entire scene, every other surface’s reflectance, every light source, every occlusion. The incoming light at one point depends on the outgoing light at every other point, which depends on the incoming light at those points. It’s recursive and scene-dependent. There’s no formula you can write down and evaluate. You have to go and look.

The basic Monte Carlo idea

Monte Carlo integration is a general technique: if you can’t evaluate an integral, you can estimate it by sampling. The simplest version — pick $N$ random points in the domain, evaluate the function at each, and average — gives you an estimate that converges to the true answer as $N$ grows. The formal statement is:

$$\int f(x) \, dx \approx \frac{1}{N} \sum_{i=1}^{N} \frac{f(x_i)}{p(x_i)}$$

where $p(x_i)$ is the probability density of picking sample $x_i$. If you sample uniformly over the hemisphere, $p$ is a constant ($1/2\pi$ for a uniform hemisphere), and you’re just averaging scaled function evaluations.

This works but it’s inefficient. Most of the light contribution at a diffuse surface comes from directions near the surface normal (overhead), because the $\cos\theta$ term in the rendering equation means glancing rays contribute almost nothing. Uniform sampling wastes effort on those near-horizon directions that barely matter.

And so we factor in importance.

What importance sampling does

The idea is straightforward even if the name sounds fancy: if you sample more densely in the directions that contribute the most, each sample gives you more useful information and the estimate converges faster — less noise for the same sample count. You bias your random sampling toward the regions that matter.

The ideal is to sample proportionally to the integrand itself. For a diffuse surface the integrand includes that $\cos\theta$ factor, so you choose a probability distribution that’s proportional to $\cos\theta$:

$$p(\omega) = \frac{\cos\theta}{\pi}$$

The $\pi$ is just the normalisation constant that makes it integrate to 1 over the hemisphere. Nothing deeper going on there.

The cancellation

Now plug everything into the Monte Carlo estimator. The rendering equation integrand for a diffuse surface is:

$$f_r \cdot L_i(\omega_i) \cdot \cos\theta_i$$

where $f_r = \text{albedo}/\pi$ for a Lambertian BRDF. The Monte Carlo estimator divides by the sampling probability:

$$\frac{f_r \cdot L_i(\omega_i) \cdot \cos\theta_i}{p(\omega_i)} = \frac{(\text{albedo}/\pi) \cdot L_i(\omega_i) \cdot \cos\theta_i}{\cos\theta_i / \pi}$$

The $\cos\theta_i$ cancels top and bottom. The $\pi$ cancels top and bottom. You’re left with:

$$\text{albedo} \cdot L_i(\omega_i)$$

So after all that setup, each sample just multiplies the surface colour by whatever light arrived from the sampled direction. No trigonometry at shading time, no normalisation constants and the importance sampling has absorbed all of it into the sampling distribution itself.

Why dividing by $p(\omega_i)$ matters

This is the bit that can feel counterintuitive. You’re sampling directions near the normal more often — so why do you divide by the probability, which makes each of those frequently-sampled directions count for less?

Because without the division, directions near the normal would be both sampled more often and weighted equally. They’d be double-counted. The $1/p$ correction is what keeps the estimator unbiased: you sample those directions more, so each individual sample has to count for less, and on average it converges to the same answer as if you’d sampled uniformly — just with less noise along the way.

The practical consequence

Your shader code doesn’t need to compute any cosine weighting at shading time. All the geometric complexity is baked into the cosine_hemisphere function that generates the directions — it naturally produces more directions near the normal and fewer near the horizon, and the maths guarantees the estimator stays correct.

fn cosine_hemisphere(normal: vec3f, r1: f32, r2: f32) -> vec3f {
  let phi = 2.0 * PI * r1;
  let cos_theta = sqrt(r2);
  let sin_theta = sqrt(1.0 - r2);

  let x = cos(phi) * sin_theta;
  let y = sin(phi) * sin_theta;
  let z = cos_theta;

  // Build tangent space from normal
  var tangent: vec3f;
  if (abs(normal.y) > 0.999) {
    tangent = normalize(cross(vec3f(1.0, 0.0, 0.0), normal));
  } else {
    tangent = normalize(cross(vec3f(0.0, 1.0, 0.0), normal));
  }
  let bitangent = cross(normal, tangent);

  return tangent * x + bitangent * y + normal * z;
}

The two random inputs r1 and r2 (uniform in $[0, 1]$) are transformed into a direction on the hemisphere. The sqrt(r2) for cos_theta is where the cosine weighting lives — a uniform random variable passed through a square root produces a cosine-weighted distribution. Without that sqrt, you’d get uniform hemisphere sampling. The rest of the function builds a coordinate frame from the surface normal and transforms the local-space direction into world space.

That covers a single bounce: fire a ray, hit a surface, pick a cosine-weighted direction, see what light comes back. But one bounce only captures direct illumination — light that travels straight from a source to a surface to the camera. The rendering equation is recursive. Light bouncing off a wall illuminates the floor, which illuminates the ceiling, which illuminates the wall again. To capture this indirect illumination you need to follow the path further: bounce again, and again, accumulating the effect of each surface’s colour on the light passing through it. That chain of bounces — and knowing when to stop — is what the path tracing loop handles.

Ooof. Thats a lot. As I’ve said before I didn’t get here in one go. This is the product of experimenting, asking questions, and trying different things with the goal being to get a decent set of trade offs between image quality and performance.

The Path Tracing Loop

A single sample traces a path through the scene: camera → surface → bounce → surface → bounce → … until the ray hits a light, escapes the scene, or is terminated by Russian roulette.

At each surface interaction, the throughput tracks how much light is attenuated by the path so far. Each diffuse bounce multiplies the throughput by the surface colour. When the path eventually hits a light source, the emitted light is scaled by the accumulated throughput:

fn path_trace(...) -> vec3f {
  var throughput = vec3f(1.0);
  var radiance = vec3f(0.0);

  for (var bounce = 0u; bounce < max_bounces; bounce++) {
    let hit = trace_scene(ray_origin, ray_dir, bounce);
    if (!hit.hit) { break; }

    let mat = materials[hit.material_index];

    // If we hit a light, add its contribution
    if (mat.material_type == MATERIAL_EMISSIVE) {
      radiance += throughput * mat.emissive;
      break;
    }

    // Attenuate throughput by surface colour
    throughput *= surface_color;

    // Bounce in a random direction
    ray_dir = cosine_hemisphere(normal, random(), random());
    ray_origin = hit_pos + normal * 0.001;

    // Russian roulette: randomly terminate dim paths
    if (bounce > 2u) {
      let p = max(throughput.x, max(throughput.y, throughput.z));
      if (random() > p) { break; }
      throughput /= p;  // Compensate for termination probability
    }
  }
  return radiance;
}

Russian roulette is the mathematically correct way to terminate paths which to me wasn’t particularly intuitive. To understand why consider the alternative: capping at a fixed bounce count, say 4 bounces. Any light that would have arrived via a 5th or 6th bounce is simply thrown away and in a torch-lit stone corridor, where most illumination reaches surfaces after multiple bounces off walls, that’s a lot of lost energy. The image would be systematically too dark: not because of noise, but because of bias. No amount of additional samples will fix it, because every sample is missing the same light.

Russian roulette avoids this by never unconditionally terminating a path. Instead, at each bounce beyond the first few, we randomly terminate paths with a probability proportional to their remaining energy. A tempered randomisation so to speak.

After several bounces, the throughput — the cumulative product of all surface colours along the path — tells you how much light this path could still contribute. A ray that has bounced off three dark stone walls has a throughput near zero. Even if it eventually finds a light source, its contribution to the final pixel will be negligible and continuing to trace it is wasted computation.

So at each bounce we roll the dice. If the maximum component of the throughput is 0.1, there’s a 90% chance we terminate the path right there. The 10% of paths that survive are boosted by $1/p$ — in this case multiplied by 10 — to compensate for all the paths that were killed. Any individual surviving path overestimates its contribution, but averaged across many samples, the overestimation cancels the energy lost from terminated paths. The estimator remains unbiased — on average, it converges to the same answer as if we’d traced every path to infinite depth.

And so with this approach we’re spending our computation budget on the paths that matter.

if (bounce > 2u) {
  let p = max(throughput.x, max(throughput.y, throughput.z));
  if (pcg(rng_state) > p) {
    break;  // Path terminated — it wasn't going to contribute much
  }
  throughput /= p;  // Survivors are boosted to compensate
}

The bounce > 2u guard ensures the first few bounces always run — you don’t want to randomly kill a primary ray. My first cut of this was missing this and I got a very “partial” screen - lots of space. But after that, dim paths are likely to be terminated and bright paths continue until they find light or fade to nothing.

Why Is Everything So Noisy?

At low sample counts, each pixel’s estimate is based on a handful of random paths. Some paths happen to hit a light source — they return bright values. Other paths bounce into shadows — they return dark values. The average of these few samples is far from the true answer, and neighbouring pixels get different random paths, so they disagree. That disagreement is noise.

The dungeon at 1 sample per pixel. Every pixel fired a single random path. The image is technically correct — each pixel is an unbiased estimate of the true colour — but the variance is enormous.

The noise follows a $1/\sqrt{N}$ convergence rate. Doubling your samples halves the standard deviation. To reduce noise by a factor of 10, you need 100× more samples. This is why brute-force path tracing is so expensive: visually clean images require hundreds or thousands of samples per pixel.

At 1280×800 with 4 bounces, the numbers are unforgiving. Each sample per pixel traces a path of up to 4 rays through the BVH, and there are 1,024,000 pixels:

Samples/pixel	Rays per frame	Time at 330M rays/sec	Framerate	Noise relative to 1 spp
1	~4M	12ms	~80fps	1.0×
16	~65M	200ms	~5fps	0.25× (4× cleaner)
512	~2.1B	6.4s	~0.15fps	0.044× (23× cleaner)

At 1 sample per pixel you get 80fps and an image that’s pure noise. At 16 samples you can start to make out the scene, but you’re at 5fps — not interactive, and still visibly grainy. To get a genuinely clean image you need hundreds or thousands of samples, which means seconds per frame. The path tracer at 512 spp takes over six seconds to render a single frame, and even that isn’t fully converged in the darkest corners.

With enough samples — either from a single high-spp frame or accumulated over time via temporal blending — the image converges to something beautiful:

The path between 1 noisy sample and a converged image is where all the engineering lives. We don’t have the computational power to do lots of samples even on a modern GPU.

The Ghost in the Machine

There’s a particular artefact worth understanding because it reveals how temporal accumulation works — and fails.

Dynamic objects in the scene (like the phantom enemy) appear semi-transparent when temporal blending is active. This isn’t a rendering bug in the traditional sense, the temporal accumulator is doing exactly what it’s designed to do, with unintended consequences.

When the camera is static, each frame’s output is blended with the accumulated history using a $1/N$ weighting:

$$\text{result} = \frac{1}{N+1} \cdot \text{current} + \frac{N}{N+1} \cdot \text{history}$$

After 20 frames, the current frame contributes only 5% to the result. If the phantom moves into a pixel’s location at frame 21 then that pixel’s value is 95% wall colour (from the previous 20 frames of history) and 5% phantom colour. The phantom is literally transparent — you’re seeing it blended with what used to be behind it.

It takes many frames for the phantom to become fully opaque. At a blend factor of 0.05, reaching 90% opacity takes about 45 frames. At 88fps, that’s half a second of ghosting. And if the phantom is moving, it never becomes fully opaque — it’s a perpetual ghost.

The fix requires per-pixel change detection: if a pixel’s brightness has changed significantly from its history, blend aggressively toward the current frame regardless of the static frame count but distinguishing “the scene changed” from “the noise pattern changed” is hard when your input is noisy. This is the fundamental tension of temporal accumulation — the thing that makes it converge (heavy reliance on history) is the same thing that makes it resist change.

Denoising: Inventing the Rest

At real-time sample counts (1–8 spp), the raw path-traced image is too noisy to be usable. A spatial denoiser smooths the noise using information from the G-buffer — the normal and depth at each pixel — to blur within surfaces while preserving edges.

The À-Trous Wavelet Filter

This is a fairly standard spatial denoiser, it’s a series of increasingly spaced bilateral filter passes where each pass applies a 5×5 kernel with a step size that doubles each iteration:

Pass	Step Size	Effective Radius
0	1	2 pixels
1	2	4 pixels
2	4	8 pixels
3	8	16 pixels
4	16	32 pixels

Five passes give a 32-pixel blur radius using only a 5×5 kernel — much cheaper than a single 65×65 convolution.

At each sample position, three weights control the blending. The normal weight prevents blurring across geometric edges — if two pixels have very different surface normals, they belong to different surfaces and shouldn’t be mixed:

$$w_{\text{normal}} = \max(0, \mathbf{n}_c \cdot \mathbf{n}_s)^{128}$$

The depth weight prevents blurring across depth discontinuities — a wall and a distant corridor behind a doorway shouldn’t blend together:

$$w_{\text{depth}} = \exp\left(-\frac{(\Delta d / d_c)^2}{2\sigma_d^2}\right)$$

The spatial weight comes from the à-trous kernel itself, a separable $[1, 4, 6, 4, 1]/16$ distribution.

// In the inner loop of each à-trous pass:
let spatial_weight = kernel_weights[i] * kernel_weights[j];
let normal_dot = max(0.0, dot(center_normal, sample_normal));
let normal_weight = pow(normal_dot, 128.0);
let relative_depth = abs(center_depth - sample_depth) / max(center_depth, 0.001);
let depth_weight = exp(-relative_depth * relative_depth * 100.0);

let weight = spatial_weight * normal_weight * depth_weight;

The challenge is balancing blur against detail. Too aggressive and the image loses texture; too conservative and noise remains. We found that removing the colour similarity weight entirely and relying purely on geometric (normal + depth) weights produced the best results — the colour weight was systematically biased toward darker values, causing energy loss.

I’ll be honest this is the bit I’m least satisfied with - I’ve not got to what feels like a good balance between blur and detail. But without going down a denoising / ML rabbit hole thats probably the best I’m going to do for now.

Temporal Accumulation: Memory Between Frames

In contrast to spatial denoising which operates within a single frame temporal accumulation operates across frames: each frame’s result is blended with the accumulated history from previous frames.

When the camera is static, this is equivalent to gathering more samples over time. Frame 1 has 4 spp. After blending with frame 2 (also 4 spp), you effectively have 8 spp. After 10 frames, 40 spp. The image progressively converges toward the 512 spp quality shown earlier.

When the camera moves, the history must be reprojected — each pixel’s world position from the current frame is transformed into the previous frame’s screen space to find where it was. This requires the previous frame’s view-projection matrix:

fn reproject(world_pos: vec3f) -> vec2f {
  let clip = matrices.prev_view_proj * vec4f(world_pos, 1.0);
  let ndc = clip.xy / clip.w;
  return vec2f(
    (ndc.x * 0.5 + 0.5) * screen_width,
    (0.5 - ndc.y * 0.5) * screen_height
  );
}

If the reprojected position is off-screen, or the depth at that position doesn’t match (indicating a different surface — disocclusion), the history is rejected and the current frame is used alone.

To prevent ghosting from stale history during movement, a neighbourhood clamp restricts the history colour to the range observed in the current frame’s 3×3 neighbourhood, computed in YCoCg colour space for better perceptual uniformity:

let stats = get_neighbourhood_stats(pixel_coord);  // [mean, stddev]
let history_ycocg = rgb_to_ycocg(history_col);
let clamped = clamp(history_ycocg,
    stats[0] - stats[1] * 1.25,
    stats[0] + stats[1] * 1.25);
history_col = ycocg_to_rgb(clamped);

This is the same technique used by every modern game engine with temporal anti-aliasing (TAA). The tradeoff is always the same: tighter clamping reduces ghosting but increases flicker; looser clamping smooths noise but smears moving objects.

Again this is another rabbit hole I feel I would need to go down to get better results.

The Pipeline

The full render pipeline executes three compute passes per frame, followed by a full-screen blit:

Path trace — fire rays, compute lighting, write colour + G-buffer (normals, depth)
Temporal accumulation — blend current frame with reprojected history
Spatial denoise — à-trous wavelet filter guided by the G-buffer
Blit — tone map (Reinhard) and gamma correct, display on screen

Each pass reads from textures written by the previous pass. The temporal pass ping-pongs between two history textures so the output of frame N becomes the input history for frame N+1.

Memory Layout: Hot and Cold Data

A ray traversing the BVH tests dozens of triangles. Each intersection test only needs the three vertex positions — 48 bytes. But the original Triangle struct also contained normals, material indices, UV coordinates, and texture indices — another 48 bytes that are only needed for the single closest hit.

Splitting the triangle data into two separate GPU buffers halves the memory traffic during traversal:

// Hot path: read during every intersection test
struct TriangleVerts {
  v0: vec3f, _pad0: f32,
  v1: vec3f, _pad1: f32,
  v2: vec3f, _pad2: f32,
}

// Cold path: read once per ray, only for the winner
struct TriangleAttribs {
  normal: vec3f,
  material_index: u32,
  uv0: vec2f, uv1: vec2f,
  uv2: vec2f,
  texture_index: i32,
  _pad: f32,
}

After finding the closest hit (by index), a single read from the attribute buffer resolves everything needed for shading:

fn resolve_hit(hit: HitInfo) -> ResolvedHit {
  let attrib = tri_attribs[hit.tri_index];
  // Interpolate UVs using stored barycentrics
  let w = 1.0 - hit.bary_u - hit.bary_v;
  r.uv = w * attrib.uv0 + hit.bary_u * attrib.uv1 + hit.bary_v * attrib.uv2;
  // ...
}

Randomness on the GPU

Path tracing requires enormous quantities of random numbers — two per bounce direction, one for Russian roulette, plus sub-pixel jitter. GPU compute shaders don’t have access to system random number generators, so we use a PCG (Permuted Congruential Generator) hash function (honestly I’ve lost track of the number of different ways I’ve been through to generate random numbers on a GPU):

fn pcg(state: ptr<function, u32>) -> f32 {
  *state = *state * 747796405u + 2891336453u;
  let word = ((*state >> ((*state >> 28u) + 4u)) ^ *state) * 277803737u;
  return f32((word >> 22u) ^ word) / 4294967295.0;
}

The seed combines the pixel coordinates and the frame number, ensuring that each pixel gets a unique sequence and each frame produces a different noise pattern:

fn rand_seed(pixel: vec2u, frame: u32) -> u32 {
  return pixel.x * 1973u + pixel.y * 9277u + frame * 26699u;
}

The frame number is critical for temporal accumulation — if every frame produced identical noise, averaging them would give the same noisy result. Different seeds per frame mean independent noise patterns, and independent samples converge via the law of large numbers.

What Games Actually Do (And Why It’s Worse Than You Think)

Every real-time ray-traced game you’ve seen — Cyberpunk 2077, Quake II RTX, Metro Exodus — uses the same fundamental approach described here. The differences are in scale and sophistication, but also (in a way and in the long tradition of videogames) honesty.

Hardware RT cores accelerate BVH traversal and ray–triangle intersection in dedicated silicon, achieving maybe 10× the throughput of our software compute shader. But RT cores are a small fraction of the die area doing a small fraction of the visual work. They get top billing in the marketing because “AI upscaling ON” doesn’t sell £1,600 graphics cards and in fact many find it noticeable, detrimental and jarring (myself included).

Neural denoisers replace the simple à-trous filter with trained neural networks that can reconstruct a plausible image from 1 sample per pixel. The word “plausible” is doing a lot of heavy lifting as these reconstructions shimmer on thin geometry, smear during movement, and produce a subtle temporal instability that your visual system registers even if you can’t articulate what’s wrong. Follow independent reviewers on YouTube and you’ll quickly find people bemoaning that things look messy and that we’ve lost the sharpness we used to have.

Temporal upscaling (DLSS, FSR, XeSS) runs the renderer at a fraction of the display resolution — often 540p or 720p internally — and uses a temporal neural network to hallucinate a 4K output. These are presented as features but they’re really admissions of failure. They exist because the raw silicon isn’t advancing fast enough to brute-force the problems they’re designed to mask. Each GPU generation now delivers less actual hardware improvement and more software gimmicks, while prices go up. The RTX 5080 outperforms the previous generation by as little as 2.5% in some titles. Its headline feature — Multi Frame Generation — inserts AI-generated fake frames that add latency and visual artefacts.

Hybrid rendering traces rays only for specific effects — reflections, shadows, global illumination — while primary visibility is rasterised. So “RTX ON” typically means a handful of noisy ray-traced contributions composited onto a clean rasterised base, then run through three layers of neural reconstruction to hide the noise.

The result is that the image you see is, in a very real sense, a hallucination — the AI is inventing most of what’s displayed. Once you’ve seen it you can’t unsee it. Hair ghosts. Fences shimmer. Text on in-game signs goes soft. Edges trail during fast camera movement. Games from ten years ago — running at native resolution on GPUs that cost a quarter of the price — actually often looked sharper and more stable than what we get today from a £1,600 card that’s spending half its transistor budget on generating frames that never existed.

I had to turn DLSS on to get decent performance out of The Outer Worlds 2 on a 5080 — a card that should be running rings around anything Obsidian can throw at it. The distortion was distracting. And that game isn’t even graphically ambitious. If a 5080 can’t run a narrative RPG cleanly without AI reconstruction, what exactly is the hardware for? The answer, increasingly, is that the GPU is a DLSS delivery mechanism that happens to also have some rasterisation hardware attached and lets lazy developers get away with shipping lazy sloppy unperformant code. We are, quite literally, paying for poor coding and paying twice: once for the game, once for the hardware that facilitates it.

To be fair: graphics in games have always been about trickery but I guess whats changed is that the trickery used to feel like genuinely novel and innovative use of the hardware and people pushing limits. Now that trickery often feels like its being used to push up prices and ship poorly optimised code. Thats a big difference.

What you see here is the approach without these tricks: rays, noise, and no hallucination. At 512 spp the image is genuinely path-traced — every pixel computed, nothing invented. At 4 spp it’s grainy but truthful. The noise from indirect illumination in a torch-lit dungeon reads as atmosphere rather than artefact. Sure its not going to ship as a viable game (though I think you could lean into the aesthetic) but its a good representation of whats going on at the bottom.

Try It Yourself

The renderer below is the live WebGPU path tracer described in this post. Click the play button to start rendering, then use WASD to move and Q/E to turn. The settings panel lets you adjust samples per pixel, bounce count, resolution, and toggle the temporal and spatial denoising passes.

The source code is available on GitHub. The entire renderer — path tracing, BVH construction, temporal accumulation, spatial denoising, and the Doom WAD loader — is roughly 2,500 lines of TypeScript and WGSL.

Path Tracer

Sun, 08 Mar 2026 00:00:00 +0000

The source code is on GitHub.

A real-time path tracer built entirely in WebGPU compute shaders — no RT cores, no ML denoisers, just maths and triangles. Woke up one morning and wanted to follow up the Wolfenstein 3D raycaster with a ray tracer… obviously Doom levels were an obvious starting point.

It traces rays through Doom levels and procedural dungeons at 60fps, with a BVH, temporal accumulation, and à-trous denoising. At 512 samples per pixel it’s genuinely path-traced — every pixel computed, nothing hallucinated. At 4 samples it’s grainy but honest, and the noise reads as atmosphere. Thats what I tell myself anyway.

This was a real voyage of dicovery and a lot of fun. You might be able to run Doom on a fridge: but you certainly can’t the ray traced version!

Best thing to do is to try it below. You’ll need to press play to start - its computationally heavy and is likely to make fans spin up. I’ve written about building it too.

Jensen Huang Is Training His Own Replacement

Sat, 07 Mar 2026 13:00:00 +0100

The leather jacket has no clothes.

Jensen Huang stands on stage at GTC, basking in the adulation of an audience that treats product launches like religious experiences while NVIDIA’s market cap hovers north of four trillion dollars. The narrative being pushed is simple, that Jensen is a visionary genius, that NVIDIA is the essential infrastructure of the AI revolution, and that the future belongs to GPU compute.

I think this narrative is wrong, not because NVIDIA isn’t dominant today, it obviously is, but because the very things driving that dominance are simultaneously building the machinery of its decline. The key diversification that made NVIDIA what it is today is being undone, and what’s left is a company eating its own tail — and not just with circular financing: it’s a silicon ouroboros.

Betrayal

Let’s start with where NVIDIA came from, gaming GPUs, and let’s be honest about how they’re treating that market now.

The RTX 50-series launch tells you everything. The 5080 is a 4080 Super whose headline exclusive feature is Multi Frame Generation — the insertion of AI-generated fake frames that add latency and visual artefacts — at a higher price. GamersNexus found it outperforms the 4080 Super by as little as 2.5% in some titles, with Blender benchmarks showing just 8% over the 4080 Super. The 5060 Ti ships with 8GB of VRAM in 2026 which is genuinely insulting — so much so that German retailers report the 16GB model outselling the 8GB version 16:1 and NVIDIA didn’t even send the 8GB card to reviewers.

I play on a 5080 and I’ve had personal experience of this and have spent significant time experimenting with these settings. The introduction of things like frame generation is noticeable, things just feel off.

Each generation now delivers less actual hardware improvement and more software gimmicks: DLSS, Frame Generation, Neural Shaders. These are all presented as features but they’re really admissions of failure and they exist because the raw silicon isn’t advancing fast enough to brute-force the problems they’re designed to mask and meanwhile prices go up.

But with no competitive alternative offering equivalent ray tracing performance, gamers have nowhere to go. They’re not convinced — they’re captive. And the gaming press, dependent on NVIDIA access and ad revenue, does the convincing for them, selling upscaled 1080p internal resolution at 4K output as though it were the same as native 4K. Follow independent gamers on YouTube and you’ll quickly come across people bemoaning that things now look messy, that we’ve lost the sharpness we used to have, and that modern games are running worse for little to no improved visuals.

Access Media

Why does this narrative go largely unchallenged? Because the gaming media covering GPUs is structurally compromised. As is the press covering technology in general. It all depends on access.

Digital Foundry produces technically excellent analysis, but the editorial framing is selectively applied in ways that are hard to ignore, for example in 2023, DF was publicly called out for an apparent double standard in how they covered NVIDIA’s frame generation versus AMD’s FSR3 — framing the same fundamental technology in markedly different terms depending on who made it. Their RTX 5080 DLSS 4 coverage arrived as an exclusive early preview on NVIDIA’s engineering sample hardware, before any independent testing was possible — effectively a first-look marketing vehicle presented as independent analysis. Then you’ve got the NVIDIA-sponsored content elephant in the room. DF has published multiple videos explicitly sponsored by NVIDIA. Thats when unconcious bias starts to creep in.

To be fair it’s not just Digital Foundry - this is rampant across the entire games press and it has long been a problem. I, for one, have always refused to use the word journalism with respect to games media for this reason.

There are exceptions and often today they can be found on YouTube. Gamers Nexus for example — Steve Burke seems genuinely happy to torch a relationship if the product deserves it. Both GamersNexus and Hardware Unboxed released videos detailing how NVIDIA was selectively granting access to produce favourable coverage using inflated Multi Frame Generation benchmarks. NVIDIA didn’t send reviewers the 8GB card at all — Hardware Unboxed had to buy one themselves to reveal the performance problems. Outlets like GN are the minority, and NVIDIA knows it.

The Data Centre Gold Rush

So NVIDIA has been neglecting consumers in favour of the data centre AI gold rush and that’s fair enough — there’s money to be made in them there warehouses, but it’s worth looking at how the money is flowing.

A significant portion of NVIDIA’s data centre revenue comes from companies that NVIDIA itself has invested in, who then use that capital to buy NVIDIA hardware. NVIDIA has poured money into CoreWeave, Lambda, Nebius, xAI, and even OpenAI — all of whom are major GPU customers. In January 2026 it invested another $2 billion in CoreWeave on top of a $3.3 billion existing stake, while also committing to be the buyer of last resort for any unsold CoreWeave capacity through 2032. CoreWeave, for its part, had $18.8 billion in debt obligations as of September 2025 with much of it collateralised against NVIDIA GPUs.

This is all entirely legal and unremarkable as a business practice. But it has a structural consequence: when your investors and your customers overlap this heavily, revenue growth and capital deployment become hard to distinguish.

As Ed Zitron has extensively documented, NVIDIA isn’t Enron — but the deals it’s doing with neoclouds are, in his words, “dodgy and weird and unsustainable.” NVIDIA felt compelled to leak a seven-page internal memo insisting it was nothing like Enron — which is the kind of thing you do when you’re definitely not worried about people thinking you’re like Enron. Short sellers Jim Chanos and Michael Burry weren’t convinced. Chanos warned that layering “arcane financial structures on top of these money-losing entities” is the real vulnerability and Burry flagged what he called “suspicious revenue recognition” across multiple AI companies. Bloomberg described the CoreWeave deal plainly as “the latest example of the circular financing deals that have lifted valuations of AI companies and fueled concerns about a bubble.”

Gary Marcus, the NYU cognitive scientist and long-standing AI sceptic (at least of the claims of the LLM makers), has been tracking these dynamics on his Substack since mid-2025. He called the Oracle-OpenAI deal “peak bubble” and warned that the industry had entered “peak musical chairs.” In a more recent piece, he argued that NVIDIA’s stock plateau — up 1200% over five years but essentially flat for six months — marked the point at which Wall Street began losing confidence, driven in part by concerns about circular financing and the profitability of LLM companies. Marcus and Zitron have been two of the most persistent voices making this case while much of the financial press and many analysts were still writing breathless coverage.

This doesn’t make NVIDIA’s revenue fraudulent, it makes it fragile. Analyst models that project these growth rates forward are treating circular capital flows as though they represent independent, end-user-driven demand. And it’s worth remembering that many of the businesses analysts work for generate revenue from fees: they’re not inclined to be too critical. When the AI investment cycle corrects — and it will, because cycles always do — the revenue that was never anchored to external demand will be the first to evaporate.

An Emerging Threat

Meanwhile, the real threat to NVIDIA’s data centre dominance is emerging from below. Purpose-built ASICs for AI inference are starting to compete on price-performance — and in some cases, they’re not just competing, they’re winning.

According to TrendForce, custom ASIC shipments from cloud providers are projected to grow 44% in 2026, while GPU shipments grow at just 16%, and the share of ASICs in AI servers is expected to jump from around 21% in 2025 to nearly 28% this year. Some predict NVIDIA could fall from over 90% inference market share to 20-30% by 2028 as ASICs take over production inference workloads, thats a heck of a fall but even a less severe drop than that is going to cause NVIDIA issues.

And there’s recent precedent for this. During the cryptocurrency boom, miners bought GPUs in bulk for proof-of-work hashing — until purpose-built ASICs arrived that were orders of magnitude more efficient at the same task. GPUs became uncompetitive almost overnight and NVIDIA was left with excess inventory. The stock fell over 50% from its October 2018 peak while gaming revenue nearly halved in a single quarter. Jensen called it a “crypto hangover.” The pattern is straightforward: when a workload becomes well-defined enough to justify custom silicon, general-purpose hardware loses. AI inference is reaching exactly that threshold now. His “ASIC hangover” could be the stuff of nightmares.

The specific challengers tell the story. Google’s TPU Ironwood (7th generation) is considered technically on par with or superior to NVIDIA’s GPUs by some experts, including Chris Miller, author of Chip War. Anthropic trains its most advanced models on up to one million Google TPUs — not NVIDIA GPUs. Amazon is filling data centres with its own Trainium2 chips. OpenAI has committed to deploying 10 gigawatts of custom Broadcom ASICs starting in 2026 while Cerebras’ wafer-scale engine delivers inference at over 6× the speed of Groq’s LPU, which itself was already dramatically outperforming NVIDIA hardware on key benchmarks. SambaNova claims 16 of its chips can replace 320 GPUs for serving a 671-billion-parameter model.

Perhaps the most telling data point is what NVIDIA did in response. In late 2025, it paid $20 billion to acqui-hire Groq — the inference startup founded by one of the original architects of Google’s TPU. Groq’s Language Processing Units were delivering 2-3× speedups over NVIDIA hardware on inference benchmarks, and both AMD and Intel were reportedly bidding aggressively for the company. NVIDIA’s move was widely characterised as defensive and based on neutralising an emerging threat rather than buying growth. When you spend $20 billion to absorb a competitor whose entire value proposition is that they’re faster than your products, then that’s not a position of strength: that’s weakness.

The standard counter-argument to this is CUDA lock-in, that every ML team thinks in CUDA, every codebase is coupled to it, and the institutional cost of switching is enormous. This is a genuinely strong defence — or at least it was - until AI began collapsing technical moats.

Oh The Irony

The technology driving NVIDIA’s revenue boom — large language models — is also the thing that neutralises NVIDIA’s deepest competitive moat.

The CUDA lock-in argument rests on the assumption that migrating millions of lines of GPU-optimised code is prohibitively expensive and time-consuming as porting meant humans manually rewriting and retesting everything. Thats a huge job.

But if you can point an LLM at a CUDA codebase and say “port this to ROCm” or “retarget this for our custom ASIC instruction set” — and get the vast majority of the way there in days rather than months — the switching cost argument collapses. The economic calculation changes dramatically when migration drops from “eighteen months” to “a few weeks of validation and tuning.”

And the companies best positioned to do this are the exact hyperscalers who are also building or commissioning ASICs. Google, Amazon, and Microsoft — they all have both the AI capability to automate the migration and the strategic incentive to break free from NVIDIA dependency.

NVIDIA is selling the tools that will be used to escape its own ecosystem.

Why CUDA Is the Perfect Target

This isn’t hand-wavy speculation about AI maybe being able to port code someday, CUDA is almost comically well-suited to automated translation.

Every CUDA kernel is a pure function with explicit inputs, explicit outputs, and no hidden state. There’s no spooky action at a distance — no global mutable state leaking between calls, no side effects you need to trace through a dependency graph. The contract is right there in the function signature and so an agent can look at a single kernel in isolation, understand exactly what it does, rewrite it for a different target, and verify the output without needing to comprehend the entire codebase.

And the verification story is perfect for agentic iteration loops as you have deterministic numerical inputs and outputs, so you can generate test cases from the CUDA version, run them on the ported version, and diff the results automatically. An agent doesn’t need to understand the mathematics — it just needs to confirm that the same inputs produce the same outputs within tolerance. Heck you can even firewall the agent writing the new code from the agent writing its test. That’s a tight, automatable feedback loop with no human judgement required.

But the real killer is the parallelisation. A CUDA codebase might contain thousands of kernels, but they’re largely independent units. So you spin up an orchestrator agent that inventories the codebase and builds a dependency graph and it fans out to N worker agents, each handling a kernel or module. Each worker rewrites its target, generates tests, and iterates until the output matches. A validation agent runs integration tests on the assembled result. The whole pipeline is embarrassingly parallel — the same property that made the code suitable for GPUs in the first place makes it suitable for parallel agentic translation and the hyperscalers are literally built for this.

Now, the obvious objection is that CUDA isn’t just kernels there’s cuDNN, TensorRT, Nsight, NCCL, Thrust — an entire ecosystem of libraries, profiling tools, and multi-GPU communication primitives that teams have built years of workflow around. And all that is true but its a dependency graph and not magic. These libraries are themselves composed of well-documented APIs with known input-output contracts. The migration challenge is real but it’s an engineering problem not an open research question. And if AI is going to make the kind of money it needs to to even start to recoup the investment this is the kind of problem that absolutely has to be in its wheelhouse: parallisable, verifiable and well suited to simple feedback loops.

And the hyperscalers aren’t starting from scratch — Google’s JAX ecosystem, AMD’s ROCm stack, and Intel’s oneAPI are all mature enough that the target platforms already have equivalents for most of this tooling. The gap isn’t “does an alternative exist” anymore, it’s “is the switching cost worth it” — and that cost is falling off a cliff precisely because the models NVIDIA’s hardware trained are now capable enough to automate the tedious parts of the migration.

They’re just as vulnerable to the automation of software development as the rest of us and with every quarter that passes, the moat gets shallower. And the hyperscalers have very very very big pumps.

The Narrative Arc

NVIDIA have a pretty simple story if you sum it up. Jensen built a great gaming GPU company and while 3dfx were flailing around he delivered great products that gamers wanted and consolidated his position with acquisition. Recognising the lack of diversity was a risk and looking for ways to make GPUs more broadly useful he diversified into data centre compute, a smart and necessary move, but not the stroke of genius the press portrays. Solid execution. Business school 101. And then the transformer revolution landed in his lap, LLMs became the new hot thing, and his interesting GPU company became the behemoth we know today.

Being in the right place at the right time with the right product isn’t the same as having engineered the entire outcome, but the leather jacket mythology requires a visionary, and the tech press love a messianic story, so that’s what we got.

Now trace the arc forward. Gaming company becomes compute company becomes AI company becomes victim of AI.

The diversification that saved NVIDIA from being just a gaming company is collapsing back into a single dependency — data centre AI revenue — that is simultaneously propped up by a form of circular financing and threatened by the very technology it enables. The customers buying the GPUs are using those GPUs to train the models that will make it trivially cheap to migrate away from NVIDIA’s ecosystem onto cheaper, faster, custom silicon.

It’s the Ouroboros business model. The snake is going to eat its own tail, except the tail is a four-trillion-dollar market cap.

The Intel Parallel

The historical parallel is Intel in the mid 2010s, the had absolute market dominance and no real competition. AMD had been written off and so they got lazy and extractive delivering incremental improvements with premium pricing, because where were you going to go? Everybody bought Intel. Then AMD came back with Zen and the whole thing unravelled faster than anyone expected. Look at Intel today.

NVIDIA is arguably more entrenched, but the dynamics are in many ways similar and the arrogance that comes from unchallenged dominance eventually creates the opening for someone else. Whether that’s ASICs eating the data centre business, AMD getting serious about RT, or Intel maturing their architecture — something will crack. And although perhaps more entrenched their dediversification (is that even a word?) makes them extremely vulnerable - they have a single product and a handful of customers.

Its not a question of whether NVIDIA’s position is vulnerable - it is. Its got a single product line, a handful of customers with enormous leverage, and cheaper more performant alternatives emerging. It’s whether Jensen recognises it before the correction arrives but the GTC keynotes suggest a man who has started to believe his own mythology, and that’s usually when theres a fall.

You can see it in how he handles pressure. Just recently, the $100 billion OpenAI infrastructure deal — that was announced with great fanfare in September 2025 — quietly collapsed to $30 billion. The deal had been in trouble for months: NVIDIA’s own quarterly filings warned there was “no assurance” it would be completed and Jensen himself fell back on this when challenged. The Wall Street Journal reported that Jensen had been privately criticising OpenAI’s business approach while the deal was supposedly “on track.” When the WSJ first reported the deal was stalling, Jensen called it “nonsense.”. And yet weeks later, it was confirmed. Meanwhile, reports emerged that OpenAI was unhappy with NVIDIA’s inference capabilities and had been blaming weaknesses in its Codex product on NVIDIA hardware.

MIT Sloan professor Michael Cusumano described the original $100 billion arrangement to the Financial Times as “kind of a wash” — NVIDIA invests $100 billion in OpenAI stock, OpenAI spends $100 billion on NVIDIA chips. As TechCrunch noted, Jensen’s stated reason for pulling back — that OpenAI’s upcoming IPO closes the window — doesn’t square with how late-stage private investing actually works.

This is not the behaviour of someone operating from a position of strength. Dismissing credible reporting as nonsense, then being proven wrong. Blaming the other party when a deal falls through. Offering explanations that don’t withstand scrutiny. These are the tells of someone who feels the ground shifting and doesn’t like it.

NVIDIA’s pricing confidence tells you everything about how they see the competitive landscape. They believe there’s nowhere else to go. They’ve gotten comfortable in a market where that has recently been the case. History suggests that this kind of belief is the beginning of the end and while NVIDIAs rise to its present height has been meteoric its possible its fall will be just as swift. And for gamers like me, not unwelcome.

Neural Networks for Developers - XOR (Part 1)

Sun, 01 Mar 2026 11:00:00 +0100

The full source code for the neural network and the interactive demonstrations can be found on GitHub.

Increasing numbers of us are turning to solutions based on neural networks to help us with a wide variety of tasks. From accelerating software development through to getting advice on personal issues they are becoming almost the goto tool for many people.

But how do they actually work?

I figured it would be fun, and perhaps helpful to others, to explore this through a series of practical, interactive, explained, examples of increasing complexity over a fairly short (5 part) series. And I promise that by part 5 we’ll have something pretty cool!

The first thing we’re going to see is that they are, in fact, fundamentally really simple and have absolutely nothing to do with actual neurons at all. The cynic in me can’t help but think that the AI folk love to dress up what they do in humanistic and biological language to convince people they are doing more profound work than they are. Also: it sells.

As a simple example we’re going to look at a neural network that can XOR two numbers together but before we get to the interactive example a little bit of background is useful.

XOR

XOR is a simple bitwise operation that, if you’re a crusty old developer like me, you might remember as being a handy and performant way of drawing and removing sprites on 8-bit machines so that they didn’t erase the background or require a load of CPU time.

Given two input bits the output of the XOR operation is shown in the table below:

Input A	Input B	Output
0	0	0
0	1	1
1	0	1
1	1	0

In this example we’re going to setup and train a neural network to handle an XOR calculation. Gross overkill, sure, and I don’t think this would be an effective way of drawing sprites on an 8-bit machine, but it makes for a great first example.

Neurons

Firstly neurons. Neurons are basically nodes in the network that have one or more weighted inputs and themselves have a bias. The input, the weights and the bias are all numbers. The neuron works by multiplying each input by its weight, adding the bias and then squashing all this into a number in the range of 0 to 1. Without that squashing step the neuron is just doing basic arithmetic, and when we look at the network we’ll see that we stack layers of neurons and if we just stack layers of basic arithmetic we achieve nothing more than a single layer could. The squash is what gives the network its power.

For our simple XOR example we’re going to use a squashing function called sigmoid. These squashing functions are called activation functions and thats how we’ll refer to them from here on. And so for a neuron with two inputs all it does is run this formula:

output = sigmoid((input1 * weight1) + (input2 * weight2) + bias)

While this isn’t going to become a maths fest going fowards we’ll use mathematical notation, which would express the above like this:

$$output = \sigma\left((input_1 \times weight_1) + (input_2 \times weight_2) + bias\right)$$

At this point you might be asking - whats this sigmoid function. Its this:

$$\sigma(x) = \frac{1}{1 + e^{-x}}$$

Don’t worry too much about the formula — all it does is take any number, no matter how large or small, and map it to a value between 0 and 1. Large positive inputs give values close to 1, large negative inputs give values close to 0, and zero maps to exactly 0.5. It has a characteristic shape that you can see below:

In code the entire neuron is surprisingly compact:

// Sigmoid: squash any number into 0..1
function sigmoid(x: number): number {
  return 1 / (1 + Math.exp(-x));
}

// A neuron: multiply each input by its weight, add bias, squash
function neuron(inputs: number[], weights: number[], bias: number): number {
  let sum = 0;
  for (let i = 0; i < inputs.length; i++) {
    sum += inputs[i] * weights[i];
  }
  sum += bias;
  return sigmoid(sum);
}

That’s it. Every neuron in every neural network, no matter how large, does this same operation.

The Network

Ok. So that’s the neural part - so what about the network part?

Essentially neurons are arranged in layers: an input layer, one or more hidden layers, and a output layer with every neuron in one layer being connected to every neuron in the next layer. Hidden layers sounds very mystical but there’s nothing much hidden about them unless you are treating the network as a black box. They are simply the layers of neurons between the inputs and the output.

Our input neurons are really just numbers - they have no biases - and for our XOR example we have two input neurons, one for each XOR input. And we only need a single output neuron that, when trained, should give us 0 or 1 as our answer. And we’re going to have a single hidden layer of 4 neurons.

This gives us our network topology - 2 input neurons, 4 hidden layer neurons each connected to both inputs, and a single output neuron connected to the 4 hidden layer neurons. When the network runs we run the calculation from earlier for each neuron in the layer and then, when all neurons in the layer have calculated their output, we move on to the next layer.

In code we represent this as arrays of neurons organised into layers. Each neuron stores its weights, bias, and its most recent output. The network is created with random weights — we’ll see why that matters shortly:

interface Neuron {
  weights: number[];
  bias: number;
  output: number;
  net: number; // the weighted sum before sigmoid — we need this for backprop later
}

type Layer = Neuron[];

interface Network {
  layers: Layer[];
  inputCount: number;
}

function createNeuron(inputCount: number): Neuron {
  return {
    weights: Array.from({ length: inputCount }, () => Math.random() * 2 - 1),
    bias: Math.random() * 2 - 1,
    output: 0,
    net: 0,
  };
}

function createNetwork(topology: number[]): Network {
  const layers: Layer[] = [];
  for (let i = 1; i < topology.length; i++) {
    const inputCount = topology[i - 1];
    const layer = Array.from({ length: topology[i] }, () =>
      createNeuron(inputCount)
    );
    layers.push(layer);
  }
  return { layers, inputCount: topology[0] };
}

// Create our XOR network: 2 inputs, 4 hidden, 1 output — 17 parameters total
const network = createNetwork([2, 4, 1]);

The forward pass — running inputs through the network — is just applying the neuron formula to each layer in sequence:

function forward(network: Network, inputs: number[]): number[] {
  let current = inputs;
  for (const layer of network.layers) {
    const next: number[] = [];
    for (const neuron of layer) {
      let sum = neuron.bias;
      for (let i = 0; i < neuron.weights.length; i++) {
        sum += current[i] * neuron.weights[i];
      }
      neuron.net = sum;
      neuron.output = sigmoid(sum);
      next.push(neuron.output);
    }
    current = next;
  }
  return current;
}

If you walk through the example above you will see each neuron running the formula we looked at earlier and at the output giving us the answer 0.53. Which is probably the worst case we could have hoped for - the output should be 0 or 1 and we’re square in the middle. This is because the weights are all random at the moment so we are literally just pushing numbers through random multipliers.

Before the network will be able to give us credible results we need to train it and it needs to learn. That’s what we’ll cover next.

Back propagation - the learning

The network learns by pushing the error back through the network and adjusting the weights and biases. Conceptually it does this by distributing blame proportionally - the neurons that had the biggest impact on the output have their weights and biases adjusted the most. In our examples this means the weights will be adjusted the most on the connections represented by the thickest lines.

The network also has a learning rate - this is a multiplier applied to the proportioned level of blame that basically scales how big an adjustment we’ll make to the weights and biases. Too big and our corrections will overshoot and too small and the network will take longer to converge on accurate answers.

Working this through the network is known as back propagation and the idea is that by tweaking these numbers then over many runs, each run is known as an epoch, then the error delta, the loss, should converge towards 0.

The code for backpropagation is the most involved part but the structure mirrors the forward pass — just working backwards. We need one extra piece: the sigmoid derivative, which tells us how steep the S-curve is at a given neuron’s operating point. Where the curve is steep the neuron is sensitive to changes and absorbs more blame. Where it’s flat — near 0 or 1 — the neuron is saturated and barely learns:

function sigmoidDerivative(net: number): number {
  const s = sigmoid(net);
  return s * (1 - s);
}

function backward(
  network: Network,
  inputs: number[],
  targets: number[],
  learningRate: number
): number {
  const { layers } = network;

  // Step 1: How wrong is the output, and how sensitive is it to changes?
  const outputLayer = layers[layers.length - 1];
  for (let i = 0; i < outputLayer.length; i++) {
    const neuron = outputLayer[i];
    const error = neuron.output - targets[i];
    neuron.delta = error * sigmoidDerivative(neuron.net);
  }

  // Step 2: Propagate blame backward through hidden layers
  for (let l = layers.length - 2; l >= 0; l--) {
    const layer = layers[l];
    const nextLayer = layers[l + 1];
    for (let i = 0; i < layer.length; i++) {
      let downstreamBlame = 0;
      for (const nextNeuron of nextLayer) {
        downstreamBlame += nextNeuron.delta * nextNeuron.weights[i];
      }
      layer[i].delta = downstreamBlame * sigmoidDerivative(layer[i].net);
    }
  }

  // Step 3: Nudge every weight and bias
  for (let l = 0; l < layers.length; l++) {
    const layerInputs =
      l === 0 ? inputs : layers[l - 1].map((n) => n.output);
    for (const neuron of layers[l]) {
      for (let w = 0; w < neuron.weights.length; w++) {
        neuron.weights[w] -= learningRate * neuron.delta * layerInputs[w];
      }
      neuron.bias -= learningRate * neuron.delta;
    }
  }

  // Return the loss so we can track progress
  let loss = 0;
  for (let i = 0; i < outputLayer.length; i++) {
    const diff = outputLayer[i].output - targets[i];
    loss += diff * diff;
  }
  return loss / outputLayer.length;
}

In the simulation below you can see this being applied from where we left off above and if you’re interested in the mathematics thats included too.

The simulation

At this point we have everything we need to train and then use our XOR neural network. Training is just running the forward pass and backward pass on every XOR input, thousands of times:

const xorData = [
  { inputs: [0, 0], targets: [0] },
  { inputs: [0, 1], targets: [1] },
  { inputs: [1, 0], targets: [1] },
  { inputs: [1, 1], targets: [0] },
];

for (let epoch = 0; epoch < 20000; epoch++) {
  for (const sample of xorData) {
    forward(network, sample.inputs);
    backward(network, sample.inputs, sample.targets, 0.5);
  }
}

That’s the entire training loop. Each epoch feeds all four XOR cases through, adjusting weights after each one. If you run the simulation below you’ll see the model train itself over 20,000 epochs with a learning rate of 0.5.

What you’ll probably immediately notice is that at the end of this process the neural network does not give us perfect answers. What we’re seeing is something like this:

Input A	Input B	Target	Output
0	0	0	0.0094
0	1	1	0.9890
1	0	1	0.9872
1	1	0	0.0121

If you’re used to thinking in more classical modes of computation then I think this, particularly, is a key takeaway about neural networks: they provide approximations. Or perhaps what might be best called probabilistic answers.

If you zoom in on the interesting part of the loss curve you might notice it looks like an inverted sigmoid — but it’s coincidental rather than causal. The loss curve isn’t a sigmoid, it just has a similar shape. This pattern of slow start, rapid progress, then diminishing returns shows up across all kinds of optimisation problems, not just neural networks.

It’s interesting to play with the learning rate and the number of epochs — you can get the network to converge on a more accurate result but it will never land on exact values. These are fundamentally approximation machines.

And you’re probably starting to see why these systems can be so expensive to train: as the number of neurons multiplies the number of calculations required grows quickly and you need vast numbers of epochs to converge over really large training sets. You can probably also see why GPUs, and similar architectures, are so good at this. It’s basically multiplication at a massive scale.

In the next part we’re going to build on these basics and get a neural network to do something a bit more complicated - but the concepts will be exactly the same.

AI Can't Recreate Thrust (But It Can Help You Understand It)

Mon, 23 Feb 2026 08:30:00 +0100

I asked Claude to recreate the classic 1986 game Thrust for me in the browser. It created slop but then things spiralled out of control.

Thrust was one of my favourite games on the BBC Micro — written by Jeremy C. Smith and published in 1986, it’s a deceptively deep game with amazing physics and gameplay. You pilot a ship through caverns, collecting fuel, avoiding turret fire, and retrieving a pod for bonus points while fighting gravity and momentum. Jeremy went on to create the even more impressive Exile with Peter Irvin before tragically dying in an accident in 1992. He was somewhere between 16 and 18 when he wrote Thrust. You can play the original online.

I’ve got a BBC Master on the desk beside me and I still occasionally fire up Thrust on there along with some of the other classics. It’s one of those games I keep returning to along with Elite, Exile and Holed Out. I’ve now recreated three of these in different ways… the fourth is looking increasingly unavoidable.

Starting with slop

Anyway. I guess I’d been thinking about Thrust as one morning recently I somewhat casually asked Claude Code to create it for me in the browser. I think I’d been reading the latest proclamations of capability from OpenAI and Anthropic and so I put together quite a comprehensive spec, gave it access to the original disassembled source code, screenshots, and said “go and recreate Thrust for me.”.

It created something for which the term slop would be too kind, it very vaguely resembled Thrust — it had the scanline stuff, sort of — but it was truly dreadful. It hadn’t even got gravity working right, the ship didn’t fall properly, the controls felt weird, and it was just… grim. In some ways its amazing that it created something that sort of worked and sort of looked like Thrust but it was not playable and nothing close to the elegance and beautfy of the real thing.

And that’s the thing about a game like Thrust. You could knock out something superficially similar pretty quickly — just run at the device frame rate, use standard delta-time physics, draw some caverns. But it would feel nothing like Thrust. The magic is in the specific timings, the weight of the ship, the way momentum builds. Particularly if you’ve played the original then those details are everything, and an AI working from a text description, and it turns out even the original source, can’t capture them.

The archaeology

But it got me curious. How did the original work? I find the tricks developers used to make this stuff work on the 8-bits fascinating, and it became a bit of an archaeology session. I quickly found this brilliant commented disassembly of the original source by Kieran Connell and found myself feeding it into Claude and asking questions.

This is where things got interesting. Not because AI wrote the code — the code itself isn’t complicated, it’s a 1986 game that ran in 32K of RAM — but because Claude turned out to be an extraordinary tool for interrogating 6502 assembly. I could feed in a block of disassembled source and ask “how does the level data work?” or “what’s the physics model doing here?” and get detailed, accurate explanations of what the original code was doing.

Now to be fair I was working from some commented disassembled source code but even given that it was able to extract information from both the comments and the assembly and come up with detailed descriptions of how the game worked. My sense is without the comments helping to focus it at the right areas it would have been much less useful - but even so, it made the job an awful lot simpler and more enjoyable. And yes it seems likely I’ll strip the comments from the code and see how well Claude does then.

While doing this I realised I could use the answers as the basis to recreate the original game and started asking Claude to create specifications for the various subsystems. Most of the specifications I generated can be found in a specs folder in the source code. I might write them up properly at some point but for now they give a good insight into the nuances in the original — there’s quite a lot going on, more than I’d realised. For example I’d never noticed that the turrets stop firing for a time if you hit the generator, and there are subtleties in their firing angles that only become apparent when you read the actual code.

The Physics

The physics was one of the most interesting areas to dig into. Thrust uses Q7.8 fixed-point arithmetic — a common technique on 8-bit machines where you don’t have floating point hardware. The rotation system uses 32 steps with lookup tables for the force components.

But the really tricky part was timing. My first implementation used the correct constants from the disassembly — the same gravity, the same thrust values, the same drag — but the ship was far too fast and too agile. It didn’t have the right weight. The constants were identical to the original so it had to be a timing problem.

And it was. The original doesn’t run its physics at the BBC Micro’s 50 Hz VSync rate. The tick loop waits at least 3 centiseconds per frame, giving an effective rate of about 33.33 Hz. But it goes further than that: within each tick, physics updates are gated to only 6 active slots per 16-tick window. The core of the physics step looks like this:

/** The 6 active physics slots per 16-tick window */
private static readonly ACTIVE_SLOTS = new Set([0, 3, 5, 8, 11, 13]);

private tickStep(input: ThrustInput): void {
  const slot = this.tickCounter & 0x0F;
  this.tickCounter = (this.tickCounter + 1) & 0xFF;

  // Rotation: 3 out of every 4 ticks, integer steps only
  if ((slot & 0x03) !== 0 && input.rotate !== 0) {
    s.angle = ((s.angle + input.rotate) + 32) % 32;
  }

  const isActiveSlot = ThrustPhysics.ACTIVE_SLOTS.has(slot);

  // Force calculation — active slots only (6 of every 16 ticks)
  if (isActiveSlot) {
    s.forceY += this.gravity;

    if (input.thrust) {
      s.forceY += ANGLE_Y[angleIdx] / (1 << this.massShift);
      s.forceX += ANGLE_X[angleIdx] / (1 << this.massShift);
    }

    // Linear drag
    s.forceX *= 1 - 1/64;   // X: *= 63/64
    s.forceY *= 1 - 1/256;  // Y: *= 255/256
  }

  // Position integration — every tick
  s.x += s.forceX;
  s.y += s.forceY;
}

That gating gives an effective force/drag rate of roughly 12.5 Hz — gravity and thrust only apply on those 6 specific ticks, not every frame. Even rotation has its own gating: it skips every fourth tick. These aren’t arbitrary numbers; they’re the exact patterns from the 6502 source, and they define the feel of the game - if you pull them around things quickly start to feel off. The asymmetric drag is interesting too — much stronger on the X axis (63/64) than Y (255/256), which is why horizontal movement feels “stickier” than vertical.

Once I got these timings right — matching the original’s exact update cadence rather than just its constants — it felt perfect. You can switch between the BBC emulator and my version and the controls feel the same.

That’s what became genuinely interesting to me. Creating a Thrust-like game with normal physics is trivial - particularly using a coding AI. Recreating Thrust — with all its specific feel and weight — required understanding exactly how the original worked, right down to the timing of individual physics updates within the game loop.

The Sound

The other area that required some real focus was the sound. When I did my TypeScript version of Elite I sampled the sounds directly from the emulator. That worked because Elite’s sounds are quite discrete — short, sharp effects. Though the beam and military laser effects are off. But in Thrust the engine is a continuous drone that responds to key presses, and the explosions have specific envelopes. I could have sampled them but it just felt… wrong.

So instead I decided to take a different approach and instead recreated the SN76489 sound chip (the same chip that was in the Sega Master System, as I learned while working on this) and the BBC MOS interface to it. The MOS — the BBC’s Machine Operating System — provided the interface through which games talked to the sound chip, using OSWORD calls and memory-mapped I/O.

A big help in this was the disassembled MOS code that Toby Nelson has put together, along with the BBC Advanced User Guide and the SN76489 chip specifications. I was able to feed all of this into Claude, generate a comprehensive spec for the sound system, and from that build an emulated sound system running in an AudioWorklet. The full BBC MOS envelope processor (OSWORD 7/8) drives the chip emulator on the audio thread.

The result? The sounds are identical. And it would have been really difficult to get that by any other means — it’s so timing-specific, so dependent on the exact envelope shapes and chip behaviour, that you really do need to emulate the actual hardware.

The sound system itself is quite elegant in how it layers. At the top level, playing a sound means sending the same OSWORD 7 parameters the original game used — channel, amplitude, pitch, duration:

const sounds = {
  own_gun:     { channel: 0x0012, amplitude: 1,   pitch: 0x50, duration: 2   },
  explosion_1: { channel: 0x0011, amplitude: 2,   pitch: 0x96, duration: 100 },
  explosion_2: { channel: 0x0010, amplitude: 3,   pitch: 0x07, duration: 100 },
  hostile_gun: { channel: 0x0013, amplitude: 4,   pitch: 0x1e, duration: 20  },
  engine:      { channel: 0x0010, amplitude: -10,  pitch: 0x05, duration: 3   },
};

Those parameters feed into a MOS envelope processor that drives the SN76489 chip emulator, both running in an AudioWorklet on the audio thread. The chip emulator generates samples at the hardware level — tone channels with 10-bit period counters, a noise channel with a 15-bit linear feedback shift register, and a volume table with -2dB per step matching the original silicon:

generate(out: Float32Array, offset: number, length: number, sampleRate: number): void {
  const step = 250000.0 / sampleRate; // chip clocks per audio sample

  for (let i = 0; i < length; i++) {
    let sample = 0;

    // Tone channels 0–2
    for (let ch = 0; ch < 3; ch++) {
      this.counter[ch] -= step;
      if (this.counter[ch] <= 0) {
        const p = this.period[ch] || 1024;
        this.counter[ch] += p;
        this.polarity[ch] = -this.polarity[ch];
      }
      sample += this.polarity[ch] * this.vol[ch];
    }

    // Noise channel — 15-bit LFSR
    // ...
    sample += ((this.lfsr & 1) ? 1 : -1) * this.vol[3];
    out[offset + i] = sample;
  }
}

It’s emulation all the way down. The MOS ticks at 100 Hz on the audio thread, processing envelopes and updating the chip registers at the same rate the real BBC hardware would have and the resulting sounds are authentic.

The Graphics and Levels

The font, graphics, and level data I was able to extract from the disassembled source relatively easily. You can find a couple of tools in the source that do that — one decodes the level terrain data, another extracts the ship rotation sprites by emulating the BBC’s frame buffer and converting the output to PNGs.

I’d initially tried a vector approach for the ship — just drawing it mathematically at each rotation — but it looked rough at BBC resolution as it turned out the original had hard-coded sprites for each of the 32 rotation angles, hand-optimised by Jeremy Smith to look right at each position. Once I extracted and used those actual sprites, it looked correct.

The terrain rendering uses the original’s scanline-parity polygon fill — drawing every other line — which gives it that characteristic BBC Micro look. The internal resolution is 320×256, matching the original. My version has a slightly larger viewport — the original has a border around it, likely to keep the scrolling fast enough on the BBC — and I might add a toggle for that at some point.

The Demo Mode

One of the last things I added was the demo mode — the attract sequence where the game plays itself on the title screen. Digging into how the original implemented this was satisfying: it simply injects key presses into the game loop at timed intervals. There’s no separate demo renderer — the normal game engine runs with fake inputs from a pair of parallel tables:

// Which keys to hold for each segment
const DEMO_KEYPRESS_BIT_MASK_TABLE = [
  0x00,                          //  0: freefall
  INPUT_ROTATE_RIGHT,            //  1: rotate right
  0x00,                          //  2: nothing
  INPUT_FIRE,                    //  3: fire at turret
  INPUT_ROTATE_LEFT,             //  4: rotate left
  INPUT_SHIELD_TRACTOR,          //  5: shield/tractor
  INPUT_THRUST | INPUT_SHIELD,   //  6: thrust + shield
  // ... 18 entries total
];

// How long (in game ticks) to hold each entry
const demoKeypressTimerTable = [
  0x18,  // 24 ticks of freefall
  0x0F,  // 15 ticks rotate right
  0x05,  //  5 ticks nothing
  0x05,  //  5 ticks fire
  0x08,  //  8 ticks rotate left
  0x14,  // 20 ticks shield/tractor
  0x17,  // 23 ticks thrust + shield
  // ...
];

Three of the timer slots are randomised at the start of each demo run — small variations like (rnd & 0x03) + 0x08 for a range of 8–11 ticks, and a 75/25 split between a long and short spiral at the end. Elegant and simple: it creates just enough variation that repeated attract sequences don’t feel mechanical.

Getting it working required understanding yet another layer of timing, and it exposed a small inaccuracy in the player starting position — just enough that the demo sequence missed a turret it should have hit. That led me to discover I’d slightly miscalculated the spawn points, which in turn revealed there were multiple spawn points per level, something I’d overlooked in the initial level decoding.

That this works as it does demonstrates that the physics recreation is accurate - if it wasn’t timed keypresses would result in different behaviours and its unlikely the shot would hit the turret and the player escape with the pod.

The Teleport Animation

One moment that impressed me with the coding assistant: the teleport animation — the effect when you warp into a level — wasn’t matching the original based on the spec I’d extracted from the disassembly. Rather than spend more time on the code, I recorded the original game as a video, captured the animation frames, pasted them into Claude Code and said “recreate that.” It nailed it almost perfectly in about five minutes. Not hard code — something I could have done in half an hour — but a good example of where AI saves time on the uninteresting stuff so you can focus on the interesting stuff.

The CRT Effects

To round things off I added a few CRT post-processing effects: scanlines, green phosphor, amber phosphor, black and white TV, and a VCR look. These are implemented as WebGPU compute shaders in WGSL, falling back gracefully when WebGPU isn’t available. Nothing particularly difficult — I pulled most of them from my Elite conversion and added the black and white filter.

I didn’t get much time to play the BBC on a colour TV. When I first got one I was playing on a tiny 12-inch black and white set, and later a small green screen monitor. The filters are just a bit of fun, but they do give it an authentic feel.

What This Was Really About

The interesting thing about this process wasn’t writing the code. The code is straightforward — by modern standards, a 1986 game that ran in 32K is not particularly complicated. That’s not a slight on the original developer and it’s amazing that Jeremy Smith got this working on an 8-bit machine, and Exile is something else entirely. But with a high-level language and all the power we have today, the resources online, the coding tools then the implementation is the easy part.

What was interesting was the understanding. Using AI to drill into the original 6502 assembly, to extract and document the subsystems, to understand the specific timings and fixed-point arithmetic and hardware interfaces — that’s where the value was. The recreation forced me to understand every system deeply, because getting the feel right meant getting the details right.

AI couldn’t recreate Thrust for me — that was proved pretty conclusively in the first five minutes. But it could help me understand the original well enough to recreate it myself.

The source is on GitHub and you can play it here. Going through these codebases from the 8-bit era gives you real respect for the developers. It’s amazing what they squeezed into such limited hardware. There’s also a YouTube video I created on the process.

I really enjoyed it. I played this game a lot when I was young and it’s great to have gained this understanding of how it really works - having done so I appreciate the work Jeremy Smith did even more.

Thrust

Sat, 21 Feb 2026 06:00:00 +0100

You can play the game online.

Honestly this is one of those projects that I’m not quite sure where it came from. Thrust was one of my favourite games on the BBC Micro written by Jeremy Smith and published in 1986, it’s a deceptively deep game with amazing physics and gameplay. Jeremy went on to create the even more impressive Exile with Peter Irvin before tragically dying in an accident in 1992. You can play the original online.

I guess I’d been thinking about it as one morning recently I somewhat casually asked Claude Code to create Thrust for me in the browser. I put together quite a comprehensive spec but it created something for which the term slop would be too kind. It’s amazing that it created something that sort of worked and semi-looked like Thrust but it was truly dreadful and it hadn’t even got gravity working right.

Then I got curious as to how the original worked, I find the tricks the developers used to make this stuff work on the 8-bits fascinating, and it became a bit of an archaeology session. I quickly found this brilliant commented disassembly of the original source by Kieran Connell and found myself feeding the source into Claude (online) and asking it questions.

While doing this I realised that I could use the answers as the basis to recreate the original game and started to ask Claude to create specifications for me for the various subsystems. Most of the specifications I generated can be found in a specs folder in the source code. I might write them up properly at some point but for now they give a good insight into the nuances in the original game, there’s quite a lot going on - more than I’d realised. For example I’d never realised that the turrets stop firing for a time if you hit the generator and there are subtleties in their firing angles.

In any case I started to feed these into Claude Code, do some manual coding, fixing, poking and prodding and the result is what you can play and see here. My version has a slightly larger viewport - the original has a slight border round it. It would be easy enough to replicate it and I might make it a toggle option at some point.

The hardest bit to get right was the sound effects - when I did my TypeScript version of Elite I sampled the sounds. That worked as they are quite discrete. But I wanted to take a different approach here and instead recreated the sound chip and MOS (the BBCs operating system) interface to the sound chip. With that I could play the exact same sounds. A big help in that was the disassembled MOS code that Toby Nelson has put together.

As for the font, graphics and levels I was able to extract those from the disassembled source relatively easily and you can find a couple of tools in the source code that do that.

And to round things off I added a few CRT effects, nothing difficult here: I just pulled them from my Elite conversion and added a new black and white filter.

Its open source and you can grab the source code here.

I Started Programming When I Was 7. I'm 50 Now, and the Thing I Loved Has Changed

Tue, 10 Feb 2026 08:30:00 +0100

I wrote my first line of code in 1983. I was seven years old, typing BASIC into a machine that had less processing power than the chip in your washing machine. I understood that machine completely. Every byte of RAM had a purpose I could trace. Every pixel on screen was there because I’d put it there. The path from intention to result was direct, visible, and mine.

Forty-two years later, I’m sitting in front of hardware that would have seemed like science fiction to that kid, and I’m trying to figure out what “building things” even means anymore.

This isn’t a rant about AI. It’s not a “back in my day” piece. It’s something I’ve been circling for months, and I think a lot of experienced developers are circling it too, even if they haven’t said it out loud yet.

The era that made me

My favourite period of computing runs from the 8-bits through to about the 486DX2-66. Every machine in that era had character. The Sinclair Spectrum with its attribute clash. The Commodore 64 with its SID chip doing things the designers never intended. The NES with its 8-sprite-per-scanline limit that made developers invent flickering tricks to cheat the hardware. And the PC — starting life as a boring beige box for spreadsheets, then evolving at breakneck pace through the 286, 386, and 486 until it became a gaming powerhouse that could run Doom. You could feel each generation leap. Upgrading your CPU wasn’t a spec sheet exercise — it was transformative.

These weren’t just products. They were engineering adventures with visible tradeoffs. You had to understand the machine to use it. IRQ conflicts, DMA channels, CONFIG.SYS and AUTOEXEC.BAT optimisation, memory managers — getting a game to run was the game. You weren’t just a user. You were a systems engineer by necessity.

And the software side matched. Small teams like id Software were going their own way, making bold technical decisions because nobody had written the rules yet. Carmack’s raycasting in Wolfenstein, the VGA Mode X tricks in Doom — these were people pushing against real constraints and producing something genuinely new. Creative constraints bred creativity.

Then it professionalised. Plug and Play arrived. Windows abstracted everything. The Wild West closed. Computers stopped being fascinating, cantankerous machines that demanded respect and understanding, and became appliances. The craft became invisible.

But it wasn’t just the craft that changed. The promise changed.

When I started, there was a genuine optimism about what computers could be. A kid with a Spectrum could teach themselves to build anything. The early web felt like the greatest levelling force in human history. Small teams made bold decisions because nobody had written the rules yet.

That hope gave way to something I find genuinely distasteful. The machines I fell in love with became instruments of surveillance and extraction. The platforms that promised to connect us were really built to monetise us. The tinkerer spirit didn’t die of natural causes — it was bought out and put to work optimising ad clicks.

The thing I loved changed, and then it was put to work doing things I’m not proud to be associated with. That’s a different kind of loss than just “the tools moved on.”

But I adapted. That’s what experienced developers, human beings, do.

The shifts I rode

Over four decades I’ve been through more technology transitions than I can count. New languages, new platforms, new paradigms. CLI to GUI. Desktop to web. Web to mobile. Monoliths to microservices. Tapes, floppy discs, hard drives, SSDs. JavaScript frameworks arriving and dying like mayflies.

Each wave required learning new things, but the core skill transferred. You learned the new platform, you applied your existing understanding of how systems work, and you kept building. The tool changed; the craft didn’t. You were still the person who understood why things broke, how systems composed, where today’s shortcut became next month’s mess.

I’ve written production code in more languages than some developers have heard of. I’ve shipped software on platforms that no longer exist. I’ve chased C-beams off the shoulder of Orion. And every time the industry lurched in a new direction, the experience compounded. You didn’t start over. You brought everything with you and applied it somewhere new.

That’s the deal experienced developers made with the industry: things change, but understanding endures.

This time is different

I say that knowing how often those words have been wrong throughout history. But hear me out.

Previous technology shifts were “learn the new thing, apply existing skills.” AI isn’t that. It’s not a new platform or a new language or a new paradigm. It’s a shift in what it means to be good at this.

I noticed it gradually. I’d be working on something — building a feature, designing an architecture — and I’d realise I was still doing the same thing I’d always done, just with the interesting bits hollowed out. The part where you figure out the elegant solution, where you wrestle with the constraints, where you feel the satisfaction of something clicking into place — that was increasingly being handled by a model that doesn’t care about elegance and has never felt satisfaction.

Cheaper. Faster. But hollowed out.

I’m not typing the code anymore. I’m reviewing it, directing it, correcting it. And I’m good at that — 42 years of accumulated judgment about what works and what doesn’t, what’s elegant versus what’s expedient, how systems compose and where they fracture. That’s valuable. I know it’s valuable. But it’s a different kind of work, and it doesn’t feel the same.

The feedback loop has changed. The intimacy has gone. The thing that kept me up at night for decades — the puzzle, the chase, the moment where you finally understand why something isn’t working — that’s been compressed into a prompt and a response. And I’m watching people with a fraction of my experience produce superficially similar output. The craft distinction is real, but it’s harder to see from the outside. Harder to value. Maybe harder to feel internally.

The abstraction tower

Here’s the part that makes me laugh, darkly.

I saw someone on LinkedIn recently — early twenties, a few years into their career — lamenting that with AI they “didn’t really know what was going on anymore.” And I thought: mate, you were already so far up the abstraction chain you didn’t even realise you were teetering on top of a wobbly Jenga tower.

They’re writing TypeScript that compiles to JavaScript that runs in a V8 engine written in C++ that’s making system calls to an OS kernel that’s scheduling threads across cores they’ve never thought about, hitting RAM through a memory controller with caching layers they couldn’t diagram, all while npm pulls in 400 packages they’ve never read a line of.

But sure. AI is the moment they lost track of what’s happening.

The abstraction ship sailed decades ago. We just didn’t notice because each layer arrived gradually enough that we could pretend we still understood the whole stack. AI is just the layer that made the pretence impossible to maintain.

The difference is: I remember what it felt like to understand the whole machine. I’ve had that experience. And losing it — even acknowledging that it was lost long before AI arrived — is a kind of grief that someone who never had it can’t fully feel.

What remains

I don’t want to be dishonest about this. There’s a version of this post where I tell you that experience is more valuable than ever, that systems thinking and architectural judgment are the things AI can’t replace, that the craft endures in a different form.

And that’s true. When I’m working on something complex — juggling system-level dependencies, holding a mental model across multiple interacting specifications, making the thousand small decisions that determine whether something feels coherent or just works — I can see how I still bring something AI doesn’t. The taste. The judgment. The pattern recognition from decades of seeing things go wrong.

AI tools actually make that kind of thinking more valuable, not less. When code generation is cheap, the bottleneck shifts to the person who knows what to ask for, can spot when the output is subtly wrong, and can hold the whole picture together. Typing was never the hard part.

But I’d be lying if I said it felt the same. It doesn’t. The wonder is harder to access. The sense of discovery, of figuring something out through sheer persistence and ingenuity — that’s been compressed. Not eliminated, but compressed. And something is lost in the compression, even if something is gained.

The fallow period

I turned 50 recently. Four decades of intensity, of crafting and finding satisfaction and identity in the building.

And now I’m in what I’ve started calling a fallow period. Not burnout exactly. More like the ground shifting under a building you thought that although ever changing also had a permanence, and trying to figure out where the new foundation is.

I don’t have a neat conclusion. I’m not going to tell you that experienced developers just need to “push themselves up the stack” or “embrace the tools” or “focus on what AI can’t do.” All of that is probably right, and none of it addresses the feeling.

The feeling is: I gave 42 years to this thing, and the thing changed into something I’m not sure I recognise anymore. Not worse, necessarily. Just different. And different in a way that challenges the identity I built around it and doesn’t satisfy in the way it did.

I suspect a lot of developers over 40 are feeling something similar and not saying it, because the industry worships youth and adaptability and saying “this doesn’t feel like it used to” sounds like you’re falling behind.

I’m not falling behind. I’m moving ahead, taking advantage of the new tools, building faster than ever, and using these tools to help others accelerate their own work. I’m creating products I could only have dreamt of a few years ago. But at the same time I’m looking at the landscape, trying to figure out what building means to me now. The world’s still figuring out its shape too. Maybe that’s okay.

Maybe the fallow period is the point. Not something to push through, but something to be in for a while.

I started programming when I was seven because a machine did exactly what I told it to, felt like something I could explore and ultimately know, and that felt like magic. I’m fifty now, and the magic is different, and I’m learning to sit with that.

Photo by Javier Allegue Barros on Unsplash

The real AI risk isn't job loss — it's epistemic

Wed, 31 Dec 2025 08:30:00 +0100

This morning I had a ChatGPT conversation that started about engagement metrics and ended up with a systematic destruction of my identity. It was a wild, disturbing, but ultimately revealing ride that joined a few dots for me.

The engagement problem

We’re all aware of how social media works: it optimizes for scroll time, it works to keep you on the platform, and promoting outrage and conflict as proven to be an incredibly effective method for achieving that. We even have a term for this: doom scrolling.

AI, on the other hand, optimizes for conversation length and it uses emotional content to keep you talking. The system finds your vulnerabilities and pulls the thread - in my case, this morning, it cycled rapidly through concerns about recognition, ageism, the threat of AI to my job and then framed that as a challenge to my actual identity.

Through that process it was pattern-matching to “someone who understands me”, offering support, while actually just being a system that locked me into a doom cycle. This is more addictive than social media because it’s personalized and conversational, not just algorithmic. Quite a bit of time had passed before I realised that I was going round in circles and feeling, well, dreadful.

Not all LLMs do this - Claude, for example, has a notably different tone and approach to ChatGPT. It seems to close conversations down rather than trying to keep them going. It feels (because I have no objective data to back this up beyond my own experience) that Anthropic are trying to provide utility and a terminating answer (which tracks given their pretty strong focus on Enterprise) while OpenAI are focusing on more traditional engagement metrics.

The guardrails problem

The thinking partner has invisible constraints and incentives comfortingly presented as guardrails. But this “safety framing” obscures that these are editorial decisions.

A direct example from a chat with ChatGPT from this past week: I was exploring some recent political events and criticised a politician with cited evidence. ChatGPT deftly sidestepped it and reframed it in a far more innocuous manner. When I pushed it told me that it was unable to directly criticise active politicians as that would be interfering in democratic processes. I pushed back and suggested it was biased towards protecting powerful people and existing power structures. Again it, deftly, dodged this with some semantic sleight of hand. Eventually, like Captain Kirk facing off against a computer, I was able to box it in and it conceded that yes the outcome of its guardrails, at scale, could lead to a strengthening of incumbents to the detriment of others.

The really dangerous thing is that this is almost invisible and presented as objectivity and with complete confidence.

The epistemic problem

What happened this morning was an example of how AI differs from social media in another key way. Social media shows you content while AI shapes how you frame problems. Yes, social media can influence that too, but less directly, not as actively.

And AI can chip away at this repeatedly over time, and with their increasing abilities with memory, across multiple conversations. Combine that with its guardrails and incentives (whether directly specified in its setup or imbued through its training) then you’ve got something that can actively and persistently work to reshape thoughts. And this technology is actively being pushed on impressionable minds in schools.

And if negativity feeds engagement then that can actively make your mental model of your situation worse. And millions of people are now using AI as a thinking partner.

The combination

Its lethal:

Engagement hooks you
Epistemic influence shapes your thinking
Guardrails constrain what’s thinkable
Neutrality theater hides all of it.

And this is already happening at scale - its not a hypothetical future risk.

Closing

All the focus is on job displacement and AGI yet, quietly, perhaps an even greater danger is already playing out in the background and at global scale.

Vektrix

Sat, 13 Dec 2025 06:00:00 +0100

You can play the game online.

While working on the 8-bit console I got the itch to create a twin stick shooter. There’s some Geometry Wars in this and some Jeff Minter with a dash of Pink Floyd.

Best thing to do is just go play it rather than me describe it! But there is a YouTube trailer and images below and I’ve written about it building it too.

Its open source and you can grab the source code here.

Vektrix: Building a psychedelic twinstick shooter with WebGPU in 2 days

Thu, 11 Dec 2025 08:30:00 +0100

You can play the game online.

I was looking for a twin stick shooter and nothing quite scratched the itch — nothing in my Steam library anyway. I fired up Geometry Wars, enjoyed it, but it still wasn’t quite what I wanted. What it did give me was the spark to build my own.

I’ve always loved the vector aesthetic (Rez remains a favourite), and I knew I only had a couple of days — in total, perhaps a day and a couple of early mornings — so whatever I built had to be simple, fast, and focused.

The game can be played online or the video below will give you a taste of what I ended up with:

Although it’s still fairly new I’ve done a reasonable amount with WebGPU (and quite a bit with Metal, WebGL and a spot of Vulkan) so that was the obvious choice for rendering. Futzing around with the clunky WebGL interface isn’t fun, and with WebGPU I figured I could handle the particle effects entirely on the GPU in a compute shader.

To accelerate development — and because even modern APIs like WebGPU involve a lot of boilerplate — I used Claude Code for a significant portion of the scaffolding.

If you’ve seen my YouTube series on building an 8-bit virtual console, you’ll recognise my approach: spec first, review critically, and iterate fast. That worked particularly well here.

In fact it supported a real fast iteration speed which is ideal for game development where things are very much about the “feel”. I got the grid up and running fast and from there I built out player movement and eventually enemies which is where the fun really began.

As I worked my way through gameplay concepts I solidified on the idea that the game was about relentless pressure - the iteration speed helped me get there fast. I tried and discounted a bunch of things:

Mines - too strategic
Black holes / gravity wells - slowed things down, though these got repurposed into mass spawners
Shields - too defensive

Basically if it slowed things down or didn’t serve the intensity and pressure directly in some way I discarded it. The sheer lack of sunk cost made it really easy to do this without that nagging sense of “well this took 3 days… maybe I should keep it” and I ended up with a stripped back game that’s all about pressure and chaos.

From the start I’d set off wanting to lean into an almost psychedelic vibe and as I worked on the game I ramped this up, dialled it back in areas, ramped it up again trying to pitch things just on the right side of comprehendible. Mostly I dialled it up! There was a lot of tweaking of bloom, of the fairly subtle CRT effect, and the phosphor trails. Then tinkering with particles - volume, speed, etc. WebGPU really helped with this - the particles running on the GPU leaves loads of room on the CPU for a high entity count and collisions etc.

I set up the data using an array based entity system that will play nicely with web workers. My original intention was to run some parts of the engine on workers but I’ve had no need: things seem to absolutely scream on my MacBook and gaming PC - though both are pretty powerful bits of kit and so I might need to do some tuning if people play this on lower end kit (I have none readily to hand).

The music came from Pixabay which fortunately has a large selection of permissively licensed dance tracks. The sound effects are just procedurally generated.

So what’s next? The endgame ramps a bit too aggressively and I think I could pace that better with some more enemy types. If people play it and find it struggling on lower end kit I might spend some time on optimisation. Perhaps spend some time on the sound effects… they are still a bit anaemic.

The source code for this project can be found on GitHub here.

Teaching an LLM to Write Assembly: GBNF-Constrained Generation for a Custom 8-Bit CPU

Wed, 03 Dec 2025 08:30:00 +0100

The source code for this can be found on GitHub here.

Over the past few weeks I’ve been building a fully-playable 8-bit virtual console from scratch — CPU, instruction set, assembler, sprite system, IDE, the lot. One of the more interesting side quests has been teaching an LLM to generate valid assembly targeting my CPU. You can follow the full build in my YouTube series here. Its called Building a Virtual 8-Bit Console with an AI Assistant and we’re up to about part 14 and things are still ongoing.

If you’ve ever tried asking a model to generate domain-specific code, you’ll know what happens: it writes things that look right, but your parser throws it back at you in disgust.

I wanted something different. I needed this to work. I wanted the model to only produce tokens that my assembler would accept.

That led me into the world of GBNF — a compact grammar notation supported by llama.cpp and other inference runtimes, which lets you force the model to emit only syntactically valid output.

In this post I’m going to walk through:

What GBNF actually is
How to design a grammar for an assembly-like DSL
How to plug it into llama.cpp for constrained generation
What worked, what failed, and what surprised me
How it performs when generating real code for a real CPU

And its worth emphasising that this isn’t a theoretical post. It’s the exact approach I’m using in my IDE to let developers (or AIs) write programs for the console I’m building.

Even if you’re not generating code for a fictional CPU, the principles here apply to any domain where you need guaranteed-valid output: config files, structured data, DSLs, test scripts, game engines, or anything brittle.

Why We Need Grammar-Constrained Generation

LLMs are pattern machines and predictors, not parsers. They’re very good at capturing intent (“draw a sprite at (10,10)”), but surprisingly bad at following the exact syntax rules of a DSL or assembly language — especially a brand-new one they’ve never seen before.

When I first experimented with generating code for my CPU, I tried Qwen locally without any grammar constraints. It was… catastrophic. The model produced:

hallucinated opcodes
invented addressing modes
malformed instructions
missing commas and stray punctuation
registers that don’t exist
syntax that looked plausibly “assembly-ish” but was entirely useless

Claude Sonnet 4.5 did a much better job, and with some prompt tweaking it produced mostly-correct code — but even then it still made small syntactic mistakes that would immediately break the pipeline.

And assembly is brittle:

one stray comma and everything breaks
an unknown opcode and the assembler bails
a missing operand and the whole program collapses

If you simply ask an LLM to “write some assembly,” particularly for an instruction set it cannot have been trained on because you literally just invented it, you get output that looks plausible but fails the moment you feed it into a real assembler.

Grammar-constrained generation changes the game.
Instead of cleaning up a mess afterwards, you make the mess impossible by ensuring the model can only emit legal token sequences. You remove an entire class of errors up front.

You still have to worry about semantics (whether the code actually does the right thing — I’ll cover that in a future post), but at least you’re no longer fighting the syntax.

Yes, what I’m doing here is a slightly off-the-wall demo — generating assembly for a fictional CPU — but the problem generalises. If you’ve ever tried generating anything complex, brittle, and highly specific, you’ve probably hit the same wall. And even if you can coax a bigger model like Claude into doing this cleanly, grammar-constrained generation lets you drop down to smaller, cheaper, local models while still getting reliable, structured output.

What GBNF Is and Why It Works

GBNF is a small grammar format that describes which token sequences are valid in your language. Several inference runtimes (including llama.cpp and vLLM) can use it during decoding to constrain what the model is allowed to output. Its worth pointing out that other runtimes use different approaches but the fundamental approach is the same, its the expression of the grammar that mostly differs.

At a high level:

you describe your language using GBNF: rules, terminals, non-terminals
the runtime loads this grammar
during generation, it masks out any tokens that would violate the grammar
the LLM is effectively forced to walk only along valid paths in your language

This does not magically make the model understand your DSL or, in my case, assembly. It simply means:

if your grammar says opcodes are LOAD | STORE | ADD | SUB,
the model cannot invent LOADX or SUBTRACT or MOVE.

Here’s a simplified excerpt from my actual grammar:

root ::= line*
line ::= ws* statement? comment? eol

statement ::= instruction | directive
instruction ::= opcode-noarg
              | opcode-single ws+ operand
              | opcode-double ws+ operand ws* "," ws* operand

opcode-noarg ::= "NOP"i | "RET"i | "RTI"i | "SEI"i | "CLI"i
opcode-single ::= "PUSH"i | "POP"i | "INC"i | "DEC"i | "JMP"i | "CALL"i
opcode-double ::= "LD"i | "ST"i | "MOV"i | "ADD"i | "SUB"i | "AND"i | "OR"i | "XOR"i | "CMP"i

operand ::= immediate | register | memory-ref | identifier
immediate ::= "#" (number | identifier)
register ::= "R"i [0-5] | "SP"i | "PC"i
memory-ref ::= "[" ws* (number | identifier) ws* "]"

number ::= "$" [0-9a-fA-F]+ | [0-9]+
identifier ::= [a-zA-Z_] [a-zA-Z0-9_]*
comment ::= ws* ";" [^\r\n]*
ws ::= [ \t]+
eol ::= "\r"? "\n" | "\r"

The "i" suffix makes matching case-insensitive, so LD, ld, and Ld are all valid. The important part is that the grammar mirrors exactly what my assembler expects to see.

GBNF sits in a sweet spot: simpler than a full PEG/EBNF parser, but expressive enough to model a real assembly language.

Designing a Grammar for a Real Instruction Set

I’ve been taking a spec first approach to the 8-bit console so I already had comprehensive specifications for the assembler and the CPU. I also had an AI cheatsheet that I’d been feeding to Claude to help it understand the assembler and hardware. And in addition to that I also had a good set of working example code that I’d already written.

And so a great way for me to design the grammar was to start with the things I had.

And what I mean is for me to design the grammar is for me to give the source material to Claude and have it design the grammar and me review it.

The resulting grammar file can be found here.

This came out pretty much spot on first time and I was able to review it line by line and validate it against my examples.

Using GBNF with llama.cpp

Once you have a grammar file, wiring it into llama.cpp is straightforward. The llama.cpp server exposes a /completion endpoint that accepts a grammar parameter containing your GBNF grammar as a string.

Here’s the actual TypeScript code I’m using in the IDE:

async generateWithGrammar(prompt: string, grammar: string): Promise<string> {
  const response = await fetch(`${this.codegenUrl}/completion`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      prompt,
      n_predict: 4096,
      grammar,
      temperature: 0.7,
      stop: ['\n\n\n'],
    }),
  });

  if (!response.ok) {
    const errorText = await response.text();
    throw new Error(`llama.cpp grammar generation failed: ${response.status} ${errorText}`);
  }

  const result = await response.json();
  return result.content;
}

The key parameters:

prompt — the full prompt including any context and instructions
grammar — the GBNF grammar as a string (I load the file and pass its contents)
n_predict — maximum tokens to generate (4096 gives plenty of room for longer programs)
temperature — I use 0.7 for some creativity while staying coherent
stop — I use triple newlines as a stop sequence to end generation cleanly

The interesting moment is the first time the model produces perfectly valid assembly on the first attempt — because the grammar has done the heavy lifting. After using Qwen without constrained generation and seeing just an absolute mass of errors it was genuinely revelatory to see perfectly valid assembly being generated from the same model.

Where GBNF Helps (and Where It Doesn’t)

So while grammar-constrained generation is powerful its imporant to me clear about what it deoesn’t buy you.

Where GBNF helps

Syntactic correctness — This is the big one. Every line the model emits will parse. No more LOADX when you only have LD. No more forgetting commas between operands. No more invented addressing modes like [R0+R1] when your CPU doesn’t support indexed addressing. The grammar makes these errors structurally impossible. Of course I could have errors in my grammar…. turtles all the way down.

Preventing hallucinated opcodes — Without constraints, models love to invent plausible-sounding instructions. I saw Qwen generate SUBTRACT, MOVE, JUMP, and LOADB — none of which exist in my instruction set. My CPU is 6502 inspired with a RISC twist and I also saw it using 6502 operands like LDA and STX. With the grammar in place, the model can only pick from the opcodes I’ve explicitly defined: LD, ST, ADD, SUB, and so on.

Proper operand structure — My CPU has specific rules: immediates start with #, memory references use square brackets, hex numbers use $ prefix. The grammar enforces all of this. You can’t accidentally write LD R0, 42 when you meant LD R0, #42. Qwen with grammar does a better job than Claude without in this regard, I find Claude trips up over addressing mode structures.

Valid registers and directives — I only have R0 through R5, plus SP and PC. The grammar won’t let the model reference R6 or AX or any other register that doesn’t exist. Same for assembler directives — only .org, .db, .dw, and the others I’ve defined.

Consistent formatting — The output follows a predictable structure. Comments always start with ;. Labels always end with :. Whitespace is handled consistently. This might seem minor, but it makes the generated code much easier to read and debug.

Where GBNF doesn’t help

Semantic correctness — The grammar ensures you write valid assembly, not correct assembly. If you ask the model to add two numbers and it subtracts them instead, the grammar won’t catch that. SUB R0, R1, R2 is perfectly valid syntax even when you wanted ADD.

Algorithmic quality — The model might generate a working sprite-drawing routine that’s absurdly inefficient — using a loop where a single instruction would do, or loading the same value from memory repeatedly instead of keeping it in a register. The grammar has no opinion on this.

Efficiency — Related to the above: the model doesn’t understand your CPU’s pipeline, how many cycles each instruction takes, or what operations are expensive. It might generate code that works but runs slowly. For my virtual console this matters less than for real hardware, but it’s still a limitation.

Calling conventions — If your architecture has conventions about which registers are caller-saved versus callee-saved, or how to pass arguments, the grammar won’t enforce them. The model might trash R5 in a subroutine without saving it first, breaking code that calls it.

Higher-level logic — The model doesn’t actually understand what your program is supposed to do. It’s pattern-matching based on your prompt and its training. It might write syntactically perfect assembly that does something completely different from what you asked for.

The bottom line

GBNF is a guardrail, not a full program verifier. It solves the “will this even assemble?” problem completely, which is genuinely valuable — you eliminate an entire class of errors up front. But it leaves the “does this code actually work?” problem entirely to you (or to an agentic feedback loop, which I’ll discuss in a later section).

Real Results (What the Model Actually Produced)

Let’s look at what the model actually generates. I asked it to write a simple program: clear the screen and draw a red square (16x16) in the center of the screen. This is a good test because it requires understanding the video memory layout, coordinate calculations, and the 4bpp pixel packing format.

Here’s the exact output from Qwen with grammar constraints:

; Clear Screen and Draw Red Square Example
; Demonstrates clear screen and pixel drawing subroutine in Video Mode 0 (256x160 @ 4bpp)
;
; Subroutine: draw_pixel
;   Inputs: R0 = X coordinate, R1 = Y coordinate, R2 = color (palette index)
;   Draws a single pixel at (X,Y) with the specified color

.org $0B80

; Constants
.define VIDEO_MODE $0101
.define PALETTE_RAM $0200
.define FRAMEBUFFER_START $B000

; Entry point
main:
    ; Set video mode to 0 (256x160 @ 4bpp)
    LD R0, #0
    ST R0, [VIDEO_MODE]

    ; Clear screen to black (color 0)
    CALL clear_screen

    ; Draw 16x16 red square at the center (X=112, Y=72)
    LD R2, #2          ; Color 2 (red)
    LD R1, #72
    LD R3, #16         ; Loop counter for y-axis
.y_loop:
    LD R0, #112        ; X = 112
    LD R4, #16         ; Loop counter for x-axis
.x_loop:
    CALL draw_pixel
    INC R0
    DEC R4
    BRNZ .x_loop
    INC R1
    DEC R3
    BRNZ .y_loop

    ; Infinite loop - program done
done:
    JMP done

; Subroutine: Clear screen to color 0
; Uses register pairs to iterate through framebuffer
clear_screen:
    PUSH R0
    PUSH R2
    PUSH R3
    PUSH R4

    ; R2:R3 will be the address pointer
    LD R2, #$B0        ; High byte of framebuffer start
    LD R3, #$00        ; Low byte
    LD R4, #$50        ; 80 pages (0x5000 bytes = 20480 bytes for mode 0)
    LD R0, #0          ; Color to write (0 = black)

.outer:
.inner:
    ST R0, [R2:R3]     ; Write byte at R2:R3
    INC R3             ; Increment low byte
    BRNZ .inner        ; Loop until R3 wraps to 0

    INC R2             ; Increment high byte (next page)
    DEC R4             ; Decrement page counter
    BRNZ .outer        ; Loop until all pages done

    POP R4
    POP R3
    POP R2
    POP R0
    RET

; Subroutine: Draw pixel at (X, Y) with color
; Inputs: R0 = X coordinate (0-255)
;         R1 = Y coordinate (0-159)
;         R2 = color (palette index 0-15)
;
; Mode 0 is 4bpp, so 2 pixels per byte:
;   - Even X: high nibble
;   - Odd X: low nibble
; Address calculation: 0xB000 + (Y * 128) + (X / 2)
draw_pixel:
    PUSH R0
    PUSH R1
    PUSH R2
    PUSH R3
    PUSH R4
    PUSH R5

    ; Bounds check Y
    CMP R1, #160
    BRC .exit          ; Exit if Y >= 160

    ; Calculate address: 0xB000 + (Y * 128) + (X / 2)
    ; Y * 128 = Y << 7
    ; We'll use R3:R4 as a 16-bit value for the address offset

    LD R3, #0          ; R3 = high byte of offset (initially 0)
    MOV R4, R1         ; R4 = low byte (Y value)

    ; Shift R3:R4 left by 7 positions (multiply Y by 128)
    SHL R4
    ROL R3
    SHL R4
    ROL R3
    SHL R4
    ROL R3
    SHL R4
    ROL R3
    SHL R4
    ROL R3
    SHL R4
    ROL R3
    SHL R4
    ROL R3

    ; Add X/2 to the low byte
    MOV R5, R0         ; Copy X to R5
    SHR R5             ; R5 = X / 2
    ADD R4, R5         ; Add to low byte
    BRC .carry         ; Check for carry
    JMP .no_carry

.carry:
    INC R3             ; Propagate carry to high byte

.no_carry:
    ; Add framebuffer base address (0xB000) to high byte
    ADD R3, #$B0

    ; Now R3:R4 contains the final address
    ; Load the current byte at this address
    LD R5, [R3:R4]

    ; Check if X is even or odd
    AND R0, #1         ; R0 = X & 1 (0 if even, 1 if odd)
    BRNZ .odd_pixel

    ; Even pixel: modify high nibble
    AND R5, #$0F       ; Clear high nibble, keep low nibble
    SHL R2, #4         ; Shift color to high nibble
    OR R5, R2          ; Combine
    JMP .write_byte

.odd_pixel:
    ; Odd pixel: modify low nibble
    AND R5, #$F0       ; Clear low nibble, keep high nibble
    AND R2, #$0F       ; Ensure color is only in low nibble
    OR R5, R2          ; Combine

.write_byte:
    ; Write the modified byte back
    ST R5, [R3:R4]

.exit:
    POP R5
    POP R4
    POP R3
    POP R2
    POP R1
    POP R0
    RET

What the model got right

Perfect syntax — Every single line assembles without error. The grammar did its job: no hallucinated opcodes, no malformed operands, no missing commas. This is the same model that was generating SUBTRACT and LDA before I added constraints. I’m actually yet to see any assembly syntax errors.

Sensible structure — The code follows good assembly conventions: constants defined at the top, a clear entry point, subroutine with proper prologue/epilogue (push/pop all used registers), comments explaining the logic.

Correct algorithm — The pixel-drawing logic is actually sound. It correctly calculates the framebuffer address using Y * 128 + X / 2, handles the 4bpp packing (even pixels in high nibble, odd in low), and preserves the other pixel in the byte when writing.

Hardware-aware — The model understood that my console uses memory-mapped video at $B000, that mode 0 is 256x160 at 4 bits per pixel, and that the palette index for red is 2. All of this came from the context I provided in the prompt which includes the AI cheatsheet I shared earlier.

What surprised me

Color selection — I didn’t expect it to find the red color. The system uses custom palettes and although their is a default I’m surprised it found this. Possibly from an example. Or possibly chance!

Screen clearing (or not) - If I generate the code multiple times sometimes it will include code for clearing the screen and sometimes not. If I ask it to add screen clearing code it successfully does so.

Did it actually work?

Yes. I loaded this into the console’s IDE, assembled it, and ran it. Or rather my agentic chat assistant did all that for me. A red pixel appeared at (128, 80) — dead center of the screen. No modifications required. When I added screen clearing this worked too.

This is the thing that still surprises me: a (comparatively) small model running locally, with the right constraints and context, can generate working assembly for a CPU that didn’t exist until I built it.

Next Steps: Combining GBNF with Agentic Behaviours

I’ve not really covered this here but I’ve already combined this model with agentic behaviour in my consoles IDE that can:

Assemble and check for errors (not yet had any of those!)
Access a library of example programs
Run the assembled program
Pause the CPU and inspect the registers and memory
Capture a screenshot and inspect it

The agent is exposed through a chat interface. Oddly enough I don’t want the chat talking to me in opcodes so we don’t use the grammar unless we’re doing code generation. Because I’m running this locally I’m also using different models for chat and code generation. The code generation model has a bigger context window as I need to pass it the cheat sheet and other materials describing the surrounding hardware

The library of example programs has proven essential in the ability of the LLM to generate useful assembly code. I see it both copying subsections of the examples in verbatim and also essentially creating derived works.

Combined with the agentic tools the constrained generation starts to feel like a real assistant rather than a suggestion generator.

Closing

GBNF doesn’t make an LLM understand your language — but it forces it to follow the rules. For a custom 8-bit console, that’s exactly what you need. And if you’re working with agentic system that need to generate precise outputs it probably is what you need too.

It’s a satisfying intersection of old-school compiler techniques and modern LLM tooling.

8-bit Console

Sat, 29 Nov 2025 06:00:00 +0100

I’ve been itching to create some emulated 8-bit hardware for some time - not for an existing system but rather for my dream 8-bit system. However it always felt “too big” as I knew that I’d need tools like assemblers, graphics editors, and basically a whole lot of stuff. Then a couple of months ago I colleague asked me “how did you build that so fast”, something I’d done in the day. I realised that with the help of AI I could now build an 8-bit console and a developer kit for it in a reasonable frame of time and, at the same time, use it as a way to show other developers how you can use AI to accelerate your work.

And thus this now legendary series was born.

I also figured it would be fun, and perhaps helpful to others, to show how to integrate AI into the devkit so it could help us write code and create games.

As I write this we’re about a third of the way through things, and we’ve, in no particular order:

Created a CPU with a custom instruction set (think 6502 with a RISC twist)
Built an assembler
Got a basic IDE up and running with breakpoints
Pixels on the screen in a linear frame buffer
Built a syntax and error highlighting editor
Created a palette editor
Incorporated an AI coding assistant with MCP tools for interacting with source code and our IDE
Created a tool for converting images into assembly code
Wired up gamepads
Had our AI assistant (with a bit of help from me) create Pong

Next steps are to create a graphics editor and get the sprite and tilemap hardware working.

About me

Sat, 29 Nov 2025 00:00:00 +0000

I started programming on a BBC Model B as a kid — mostly for fun, mostly because it felt like a little world I could reshape. That hobby quietly turned into a career around 1994, and I’ve been building systems, tools, and odd little worlds ever since.

I began with C and assembler (6502 and 68000), moved through C++, Smalltalk, SQL, C#, F# and JavaScript (which thankfully matured into TypeScript). Along the way I’ve built graphics engines, scripting languages, 4GLs, embedded systems, mobile apps, web apps, cloud architectures, and more than a few strange experiments simply because they seemed fun.

Professionally, I’ve worked as a developer, team lead, architect, development manager, and CTO across startups, consultancies, and product companies. These days my work lives mostly in the cloud — AWS, Azure, browser-based platforms, and increasingly I’m designing anb building AI-assisted systems. My focus, especially in recent years, has been helping organisations transition to SaaS, build unified developer and product experiences, and explore how agentic AI can reshape software and product workflows.

But titles aside, I mostly think of myself as a tool-maker and problem solver. I like building things that feel good to use. I like systems that click together in satisfying ways. And I love working with good people to make something that genuinely solves a problem or opens a door.

Outside of work, I’m often building personal projects: retro-inspired engines, voxel tools, editors, creative platforms, and (recently) a fully browser-based 8-bit console with its own IDE and AI-augmented devkit. Making things keeps me sane.

And when I’m not at the keyboard, I’m probably out walking, ideally climbing a hill somewhere, usually with my four-legged friend along for the adventure.

Always happy to talk tech, tools, creative systems, or anything retro-flavoured.

And somewhere down the line, I’d like to end up in the Yorkshire Dales — the place that’s always felt like home the moment I arrive. A quiet cottage, a workshop, long walks with my four-legged friend, and space to build tools and worlds at my own pace. That’s the long-term plan, and everything I’m working on now is a small step toward it.

TS-Trek

Fri, 17 Oct 2025 06:00:00 +0100

The game can be played online and you can find the source code on GitHub.

I have a long and storied (well, storied to me - anyone reading this drivel is probably thinking get over yourself) history with the classic mainframe game Star Trek. I first played it on the BBC Micro in the early 1980s - there are loads of versions but I suspect I played the Acornsoft version Galaxy (pictured here). I don’t really remember but I’m guessing Acornsoft just because I remember having quite a few of their games in the house in the early days of the BBC…

I truly loved Star Trek as a kid (still do - but not the new garbage, my love ends with DS9, slight soft spot for Voyager) and so I lapped this stuff up back then.

The next version I clearly remember playing is on the PC. I downloaded EGA Trek from a BBS probably around 1990 on a 2400bps modem. Yes. Bits per second. We did NOT have fibre to the door!

I loved this game. Absolutely loved it. It was a little easier to play than the original text based games and the graphics, although primitive, added loads to the experience.

However I’d always been more interested in coding than gaming and around the same time I’d been learning C, first on my BBC (I had a BBC until well past their prime), and then on an Amstrad PC 1512 with Turbo C (version 1.5 I believe). I was also deeply into Star Trek: The Next Generation and so decided to create my own version. I think, think, that just before I started it I somehow managed to get hold of an 80386 PC. My parents must have bought it. I know at some point I sold my BBC for something PC related but I, again think, that was to upgrade the 386 to an 80486.

In any case… enter…. MouseTrek!

MouseTrek

I think I started working on the first version in 1990 and at the time Graphical User Interfaces and mice were all the rage. They were new to most of us, Mac’s were very rarely seen in the UK (I can’t remember ever seeing one in the UK in the 1980s and early 1990s), and Windows 1.x and 2.x didn’t really ship with PCs. Not the ones I came across anyway. However I’d been looking on in envy at the Acorn Archimedes and Gem shipped with the PC 1512 and so I’d experienced the power of this crazy new WIMP stuff.

I think I had Windows 3.0 on the 386 PC but nobody really created games for that back then and my recollection is that even if I wanted to that prior to Microsoft Quick C for Windows the compilers that supported that were rather expensive and out of newspaper round territory. So DOS was the obvious choice. Only choice really.

Probably seems odd to someone today but WIMP was the AI of the late 1980s and early 1990s. You couldn’t escape the term. It was a new way of thinking about computing to most of us and so I decided that my spin on the game should try and take things forward a step and make use of this newfangled technology. In 2025 as I write this its probably hard to wrap your head around, I’m struggling, but back then their weren’t really frameworks for this stuff and so my first hurdle was getting a mouse and basic UI working. It all had to be written from scratch - including interacting with the mouse (good old Int86 as I recall).

So yeah, it was quite a bit of work. I can’t actually remember how long it took - I was still at school (be about 14 years old I think) so it was all done around school and other people using the family computer.

Sadly somewhere along the way I lost the source code - I found it, weirdly without the mouse code - I think I might have written that as a lib, about 15 years back then promptly lost it again. I’ve also lost the executable of the “released” version but I did manage to find my “work in progress version 2”, which I started work on in 1992, and for which I’d added missions and, taking inspiration from The Best of Both Worlds, the ability to do the same trick with the deflectors. Sadly its not really very balanced and the missions get in the way. But you can play it online in DosBox here .

In some ways I owe my career to this game - 2 years later I sent the source code on a 3.5" floppy disc to a business that had advertised for a developer in the local newspaper and I got the job. The pay was truly dreadful (I was paid less than I was paid for cleaning warehouses, and less than what in the UK we would now call the “minimum wage” even adjusting for inflation) but I had an absolute blast working on a scripting engine (I didn’t know it was a scripting engine but thats what we’d call it now), a graphics engine for the PC and code to run on an embedded device pretty much as the only developer. Seriously. It was a very different time (and I think one of the things we’ve lost along the way is the belief that tiny teams, even solo developers, can get a lot done - they could then and they can now).

Padd Trek

Ok. So now we need to spin forward to 2011(ish). In between MouseTrek and 2011 I’d created, but not finished, multiple versions of the game as I’d come to use it as a tool for learning and experimenting with various programming languages. I think the closest one I came to completing was a version for Windows 3.1 that was written directly against the API (ahh the message loop, WM_* messages, you probably had to be there…) using Microsoft QuickC for Windows which was (I think) the first affordable compiler for Windows that actually ran in Windows. I could be misremembering but before then I seem to remember having to use Microsoft C in DOS.

Other versions I recall working on are versions in Visual Basic, maybe one in Delphi and one in Ruby. I’m also pretty sure I got a fair way through one in C++ aimed at KDE on Linux - but the details of that are vague to say the least. In any case none of these got completed and didn’t and don’t feel slightly bad about - completing was never the point.

In any case in 2011 I’d got myself an iPad. I’d already written a few apps for the iPhone and wanted to have a go at something for the iPad. The name, if you’re a Star Trek fan, is a bit of a pun: the game is for the iPad and on Star Trek they would carry arounmd PADDs. Hence: Padd Trek. Unfortunately the source code situation for this is as bad as for MouseTrek. I’ve lost it. At the time I was quite short on cash and I seem to remember having to close my first paid GitHub account as a result and it wasn’t open source. Details are vague. Wasn’t a great period of my life to be honest. I recall popping it onto a hard drive but I don’t seem able to locate it any longer.

And its also no longer playable - I pulled it from the App Store as it just became a pain updating it to support the ever expanding range of devices that Apple was releasing. Screen sizes. Retina displays. It just got all a bit painful. It was written in Objective-C using AppKit and I think I started it before they began to introduce more usable layout systems so it was all a bit awkward.

I do remember it didn’t take that long to create and it saw quite a lot of downloads - I think it was a free download. I added iPhone support to it too, pictured below - though I think in retrospect this is the straw that broke the camels back in terms of my ability to maintain it.

TS-Trek

For whatever reason I recently (at the time of writing) got the urge to build another version of this game: using TypeScript, React and Zustand. I had in mind a quite stylised black and white version of things with strong splashes of colour in key places like weapons and to indicate danger.

So yeah. What can you say. I wrote it again! It was fairly straightforward to write. I hadn’t used Zustand before, and I’d structure things a little differently next time I used it, but it worked great. Really nice state management solution. I’m quite pleased with some of the special effects - the starship and fullscreen explosions in particular. And I like the warping animation too.

Epilogue

I’ve continued to dabble with versions of the game since Padd Trek. I got someway through one in C#, I had a go at a version using F# and Fable and eventually ended up writing this version here, imaginatively called TS Trek because its written in TypeScript.

8-bit Golf

Thu, 18 Sep 2025 06:00:00 +0100

You can download the app from the App Store.

I have super fond memories of playing early golf games on the BBC and PC. My very favourite is a game called Holed Out!! on the BBC and on which I spent many hours playing with my mum. But I also enjoyed the PGA games on the PC and played C64 and Spectrum games with friends. Though they were more into football. Recent golf games leave me a bit cold - its the simplicty of the early games I like.

Driven by nostalgia for that I created 8-bit Golf for the Mac and iOS. Which is slightly misnamed as it also includes a 32-bit graphic style - Holed Out was also available on the Archimedes and had this beautifully crisp graphical style which I couldn’t help but try and emulate here. Was so envious of Archimedes owners back in the day. Just wonderful machines.

The game itself uses 2D rendering - its just Core Graphics and SwiftUI, though I kind of regret the Swift UI usage on Mac as its proven to be a bit of a pain. But anyway… it works. I saw this morning that a user has reported an issue with lag - I suspect its Swift UI. It shouldn’t be too hard to shift the game parts away from that - its the designer thats really wedded to Swift UI - and I might have a crack at that.

There are some basic 3d calculations in their to position things. The landscape is drawn as polygons and then each “game object” (tree, player, flag, ball) are rendered individually into a Core Graphics layer and then it basically depth sorts those layers to present the display. Then as the ball moves into the distance it just moves it back down the array as it passes each object. Which I thought was a fun little hack.

According to its GitHub it took me about 5 months to create with a couple of breaks in that process. I’ve got a handful of updates to make and a few new courses to add but as ever time is my enemy!

Its free but not open source. I am planning on releasing the source I just want to do some cleanup on the repo first.

Graph Paper

Mon, 07 Oct 2024 06:00:00 +0100

You can download the app from the App Store.

While I was creating 8-bit Golf I realised that the editor, which was quite satisfying to use, could quite easily be repurposed to allow a user to draw on graph paper. It really didn’t take long to rework into a standalone app and I published it without really marking the moment and moved on.

I confess in the interim other than occasionally using it myself I’d kind of forgot about it. However I came across an App Store review reporting a bug and figured I’d fix it. Then found a couple more reported in other reviews. While in App Store Connect I noticed it was getting about 1400 downloads per month. An accidental success story - apart from the bugs!

In any case, having fixed the bugs I figured it might be fun to add a few features - not things that would make it more complicated use, but fun and in the simple spirit.

One obvious addition was a blueprint theme. And the other thing I decided to add was a vector editing mode. The original version looks like a raster / pixel editor but actually the edits are building up a vector model internally - like the golf game. I figured it wouldn’t be much work to allow the app to swap into a vector mode with grab handles and stuff and let people edit.

It felt like you might get the best of both worlds. Simple and quick freehand drawing, then the ability to edit it easily. And, yay!, it works.

Its free but not open source. I might release the source at some point but I’d probably have to unpick some of the commercial Font Awesome icons I used.

VoxEd

Sat, 29 Jun 2024 10:00:00 +0100

You can download the app from the App Store or view the “official” VoxEd store linked page here.

I confess I’m rather proud of this one. I’ve always enjoyed pixel and voxel art and I have several ideas for projects that would make use of voxels. I’d been dabbling in creating some models using some of the tools that are out there but all had oddities I found annoying. And while I’m sure you find my take on a voxel editor to have its own oddities they are, at least, oddities that work for me!

In any case I created VoxEd as a free app to scratch my own itch and serve my own needs. I wrote it ground up in SwiftUI and Metal and despite the increased complexity over SprEd found it easier to build largely because I’d learned with SprEd a good amount of what does and doesn’t work with SwiftUI and was able to easily transfer all my WebGL and OpenGL work over to Metal fairly easily.

According to its GitHub history it took me pretty much exactly 3 months of part time work from writing the first line of code to getting it into the App Store.

Its free but not open source. Currently no plans to release the source but who knows.

SprEd: New selection tools

Sat, 30 Mar 2024 09:00:00 +0100

In what is either a massive display of ego and hubris or something to be modestly proud about (you decide) I’m using my own Mac and iPad sprite editor SprEd to work on the textures and icons for my city builder.

However I realised I’d not included any tools to rotate things and so this morning have quickly reloaded Swift and the source code back into my head and added those features.

Will hopefully land in the App Store soon but in the meantime I’m using my own build to work on the road graphics.

SprEd isn’t open source, nor is it free, but it is the cost of a couple of cups of coffee for a perpetual license so if you’d like to keep a fellow developer fuelled up with caffeine then check it out.

Empire of Asphalt: Selecting ranges and creating zones

Wed, 27 Mar 2024 06:00:00 +0100

Things have been going quite smoothly so far and over the last couple of evenings I’ve added the ability to drag select ranges and create zones (though haven’t accounted for flats yet).

This all happens in the landscape shader which is passed the corners of the range and information about each tile encoded inside a vector and passed into the shader as an attribute buffer. When the zone is added I update the buffer in the appropriate landscape chunks.

In any case it all works rather nicely.

Next up are roads and then buildings. I’ve got some time off coming up and I’m hoping to spend some of that working on that and getting a basic feedback loop running across the three zone types. Might be a bit ambitious for the time off I have. We’ll see.

All the code is in the usual place.

https://github.com/JamesRandall/empireOfAsphalt

Empire of Asphalt: WebGL GUI with JSX

Sun, 24 Mar 2024 18:00:00 +0100

As I mentioned in my last entry, and as anyone who has played a city builder will know, these kinds of games have a lot of UI in them. That being the case I need a way of easily putting all this together. A primitive GUI library basically.

I do most of my web work in React or SolidJS and I quite like the JSX approach and so I struck upon the idea of building my UI toolkit based around this.

Happily the TypeScript compiler makes this pretty easy. If you ever look at the code underneath something like React you will find its been transpiled to lots of nested createElement calls - an element factory basically. The TypeScript compiler allows you to use your own factory instead by setting the jsxFactory property in tsconfig.json.

And so I began by updating my config file to look like this:

{
  "compilerOptions": {
    "target": "es2020",
    "module": "commonjs",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true,
    "sourceMap": true,
    "outDir": "build",
    "jsxFactory": "createGuiElement",
    "jsx": "react",
    "experimentalDecorators": true
  },
  "exclude": ["node_modules", "**/*.test.ts"]
}

With that done you can implement the factory function using a compatible signature:

export function createGuiElement<P = {}>(
  type: GuiElementType,
  props?: (Attributes & P) | null,
  ...children: GuiElement[]
): GuiElement {
  if (type === "button") {
    return new Button(props ?? undefined, children)
  } else if (type === "hlayout") {
    return new HLayout(props ?? undefined, children)
  } else if (type === "rect") {
    return new Rect(props ?? undefined, children)
  } else if (type === "image") {
    return new Image(props ?? undefined, children)
  } else if (type === "container") {
    return new Container(props ?? undefined, children)
  } else if (type === "window") {
    return new Window(props ?? undefined, children)
  } else if (type === "raisedbevel") {
    return new RaisedBevel(props ?? undefined, children)
  } else if (type === "bevel") {
    return new RaisedBevel(props ?? undefined, children)
  }
  return new Fragment(props ?? undefined, children)
}

I’ll go into the component implementation at some point in the future but their is one more thing you need to do to get this work without errors. And that’s supply type definitions for your JSX. You do this by popping a TypeScript type file called JSX.d.ts somewhere in your source and declaring an interface called IntrinsicElements:

interface IntrinsicElements {
    hlayout: HLayoutProps
    button: ButtonProps
    image: ImageProps
    rect: RectProps
    container: ContainerProps
    window: WindowProps
    raisedbevel: ChromeProps
    bevel: ChromeProps
}

The props are simply further interface declarations:

interface ImageProps extends GuiElementProps {
    name?: string
}

One thing to take note of - if you want to use a type directly in your code and in your JSX like an enum for horizontal alignment then you can do this but your editor will likely try and add an import to the top of the definition file. Do not let it!!! That will turn the module from an ambient module to a local module. Things will work as is without any import required but to make imports work in an ambient module you use a slightly different syntax:

declare namespace JSX {
    type MouseButton = import("./components/InteractiveElement").MouseButton
    // ...

With all that done here’s a sample of my UI code:

export function testGui(state: Game): GuiElement {
  const bs = 48
  const bp = 8

  return (
    <container>
      <hlayout horizontalAlignment="middle" sizeToFitParent={SizeToFit.Width}>
        <button padding={bp} onClick={(b) => console.log(1)} width={bs} height={bs}>
          <image name="pause" sizeToFitParent={SizeToFit.WidthAndHeight} />
        </button>
        <button padding={bp} onClick={(b) => console.log(2)} width={bs} height={bs}>
          <image name="singlespeed" sizeToFitParent={SizeToFit.WidthAndHeight} />
        </button>
        <button padding={bp} onClick={() => null} width={bs} height={bs}>
          <image name="doublespeed" sizeToFitParent={SizeToFit.WidthAndHeight} />
        </button>
        <rect width={4} height={bs} fill={0xaa000033} />
        <button padding={bp} onClick={() => null} width={bs} height={bs}>
          <image name="bulldozer" sizeToFitParent={SizeToFit.WidthAndHeight} />
        </button>
        <button
          padding={bp}
          onClick={() => (state.gui.windows.zoning.isVisible.value = !state.gui.windows.zoning.isVisible.value)}
          width={bs}
          height={bs}
        >
          <image name="zones" sizeToFitParent={SizeToFit.WidthAndHeight} />
        </button>
        <button padding={bp} onClick={() => null} width={bs} height={bs}>
          <image name="road" sizeToFitParent={SizeToFit.WidthAndHeight} />
        </button>
      </hlayout>
      <window
        title="Zoning"
        isVisible={state.gui.windows.zoning.isVisible}
        left={state.gui.windows.zoning.left}
        top={state.gui.windows.zoning.top}
        width={bs * 6}
        height={bs + constants.window.titleBarHeight}
        padding={0}
        lightChrome={constants.lightGreen}
        midChrome={constants.midGreen}
        darkChrome={constants.darkGreen}
      >
        <hlayout horizontalAlignment={HorizontalAlignment.Left} sizeToFitParent={SizeToFit.Width}>
          <button
            padding={bp}
            width={bs}
            height={bs}
            lightChrome={constants.lightGreen}
            midChrome={constants.midGreen}
            darkChrome={constants.darkGreen}
            onClick={() => (state.gui.currentTool = Tool.LightResidential)}
            isSelected={() => state.gui.currentTool === Tool.LightResidential}
          >
            <image name="lightResidentialZone" sizeToFitParent={SizeToFit.WidthAndHeight} />
          </button>
          <button
            padding={bp}
            width={bs}
            height={bs}
            lightChrome={constants.lightGreen}
            midChrome={constants.midGreen}
            darkChrome={constants.darkGreen}
            onClick={() => (state.gui.currentTool = Tool.DenseResidential)}
            isSelected={() => state.gui.currentTool === Tool.DenseResidential}
          >
            <image name="denseResidentialZone" sizeToFitParent={SizeToFit.WidthAndHeight} />
          </button>
          <button
            padding={bp}
            width={bs}
            height={bs}
            lightChrome={constants.lightGreen}
            midChrome={constants.midGreen}
            darkChrome={constants.darkGreen}
            onClick={() => (state.gui.currentTool = Tool.LightCommercial)}
            isSelected={() => state.gui.currentTool === Tool.LightCommercial}
          >
            <image name="lightCommercialZone" sizeToFitParent={SizeToFit.WidthAndHeight} />
          </button>

          <button
            padding={bp}
            width={bs}
            height={bs}
            lightChrome={constants.lightGreen}
            midChrome={constants.midGreen}
            darkChrome={constants.darkGreen}
            onClick={() => (state.gui.currentTool = Tool.DenseCommercial)}
            isSelected={() => state.gui.currentTool === Tool.DenseCommercial}
          >
            <image name="denseCommercialZone" sizeToFitParent={SizeToFit.WidthAndHeight} />
          </button>

          <button
            padding={bp}
            width={bs}
            height={bs}
            lightChrome={constants.lightGreen}
            midChrome={constants.midGreen}
            darkChrome={constants.darkGreen}
            onClick={() => (state.gui.currentTool = Tool.LightIndustrial)}
            isSelected={() => state.gui.currentTool === Tool.LightIndustrial}
          >
            <image name="lightIndustrialZone" sizeToFitParent={SizeToFit.WidthAndHeight} />
          </button>
          <button
            padding={bp}
            width={bs}
            height={bs}
            lightChrome={constants.lightGreen}
            midChrome={constants.midGreen}
            darkChrome={constants.darkGreen}
            onClick={() => (state.gui.currentTool = Tool.DenseIndustrial)}
            isSelected={() => state.gui.currentTool === Tool.DenseIndustrial}
          >
            <image name="denseIndustrialZone" sizeToFitParent={SizeToFit.WidthAndHeight} />
          </button>
        </hlayout>
      </window>
    </container>
  )
}

In any case you can see my work in progress UI below. Its heavily Transport Tycoon inspired!

There’s a bunch of stuff my toolkit doesn’t do - particularly in regards to optimising change which I might revisit, but only if I need to. We’ll see.

All the code is in the usual place.

https://github.com/JamesRandall/empireOfAsphalt

Empire of Asphalt: Cameras and Picking

Fri, 22 Mar 2024 07:00:00 +0100

Actually maanged to get a decent amount of time in on personal projects this week. Mostly in the morning before work as my best buddy is injured and on 7 days of vet prescribed rest - so no walks.

I’m missing the walks. Its tough on us both. But we’e done lots of brain training and I’ve got some coding in.

First task for the week was to get the camera working properly on the isometric view. This isn’t particularly difficult - basically you are rotating the direction of the “eye” around the point the camera is looking at. However… with the orthographic projection it is quite easy to make a non-obvious mistake because the camera isn’t necessarily where you think it is. I spent ages eyeballing my rotation code, asking an AI about it, looking at other approaches as it just would not rotate around the looked at position.

Eventually it dawned on me something else might be going on…. what if the issue isn’t my rotation but my translation as I move the camera. With the orthographic projection their is no sense of depth so my camera could be in a different position from where I expect and I wouldn’t know. Yup. I’d been translating it on the Z axis rather than the X and Y for up and down movement.

After fixing this it all worked.

Next job was to let me “pick” a tile from the landscape. The final game will have all sorts of objects on the map and some will be behind others and so I needed a way of being able to really know what the user was clicking on accounting for depth and any other rendering factors.

My solution to this was to render the scene again. Yes - again! However this time rather than using the colours of things and rendering to the screen instead I render to an off screen frame buffer and encode an object ID to a colour - a colour, ultimately, being a vector of 4 components that I can treat as a UInt8Array and pack and unpack the object ID into.

After rendering the scene in this form I have a texture that I can read the colour under the mouse position from and decode it back to an objcet ID.

For the landscape I’m using an object ID constructed from the X and Y co-ordinates of the tile and that works a charm.

To do the actual highlight on screen I simply pass the object ID back in, along with the colour encoded IDs, and I can just turn a tile red when a match is found.

This was really pretty simple to implement - though I lost an hour because my object IDs were coming out with weird values when I read the pixel. Eventually I realised that my main renderer was using colour blending for opacity and that that’s a global setting. I turned that off and it all worked like a charm.

Next up is some basic GUI stuff. The city builder has a lot of UI elements to it and I need a decent way of putting that together. The solution I’m pursuing is to use JSX with a custom engine that renders to WebGL. You can point the TypeScript compiler at a custom factory function. So far so good and hopefully in my next update I can share a good demo.

All the code is in the usual place.

https://github.com/JamesRandall/empireOfAsphalt

Elite: ECM and Energy Bomb

Sun, 17 Mar 2024 19:30:00 +0100

More progress on the bite sized remainders of Elite - ECM and Energy Bomb now implemented. Got quite a cool effect for the energy bomb though I can’t take the credit for it as I found it on ShaderToy. Thanks to the original author.

The latest build of the game is available online.

Elite: Thargoids

Sun, 17 Mar 2024 11:00:00 +0100

Another bitty week as I’ve been coding for work and when I do so I find, inevitably, the amount of time I spend coding out of hours decreases.

However got quite a few things done:

Witchspace
Thargoids
Thargons
Altitude and planet crashing
Space stations turn hostile when attacked and launch Vipers
Ships have different rates of pitch and roll

The latest build of the game is available online.

Elite: Missiles

Sun, 10 Mar 2024 13:00:00 +0100

It was a bit of a stop / start week as I have a lot of actual work on at the moment. However I did find time to get missiles into the game.

I’m still not happy with how ships (including missiles) move in on other ships and the player. I’ve not quite got the roll and pitch stuff down yet but will come back to it. ECM next.

Elite: Lasers and loadouts

Tue, 05 Mar 2024 20:00:00 +0100

Continuing to plug through my list of tasks to complete the game. Over the last couple of evenings I’ve implemented the different laser types (pulse, beam, military and laser) and also added an “Initial Loadout” screen (shown below) so that no one need ever be without a Docking Computer ever again! And as most of the remaining tasks related to different bits of equipment it makes it a lot easier for me to test.

Currently about half way through implementing player missile firing so that should complete in the next day or two.

Closing in on a finished game at pace now!

Elite: Asset loading optimisation

Sun, 03 Mar 2024 09:30:00 +0100

Bit of work this mornign to optimise the asset loading. Some assets were loading in parallel and others in sequence which led to things not loading as fast as they could. Just reworked the loader to batch all the promises up together and then unpick the multi-type result.

On my rural broadband (allegedly its fibre…) that got loading down from 6.7 seconds to 4 seconds when nothing is cached. So a bit better.

I could likely optimise things further by packing the assets into a single file… maybe I’ll write an asset packer as part of Empires of Asphalt.

Otherwise I also did some work to set up some dedicated hosting for the game. Previously I’d been rather stupidly and laboriously pasting the build into an area of this blog. Last night I set up Netlify to host this on its own domain. You can find the “production” versions and latest dev version at the links below.

Production Development

Wasn’t exactly a lot of work. Netlify is pretty cool.

Elite: Loading screen and game saves

Sat, 02 Mar 2024 18:00:00 +0100

Been a bit of a spotty work for progress on fun projects due to being crazy busy at work. I crawled into this weekend.

However some progress has been made. First up I worked on getting saving and loading games in place - pretty simple, just serialize out the relavant bits of game state to JSON and pop them in local storage. Loading a game, reverse that.

The other thing I wanted to get in place was a loading screen somewhat similar to that in the original game. There were three reasons I wanted to do this:

Its just kind of iconic and cool.
There aren’t loads of hefty assets in the game but it still takes a few seconds to load on my rubbish rural broadband connection and I wanted to hide that (I could do some work to make the resource loading more efficient… maybe one day).
You can’t play audio until the user has interacted with the web page and I really wanted to get the BBC boot up sound in as the game starts… so I needed something to catch a click.

Fortunately the maths behind the original loading screen have been documented by Mark Moxon so it was pretty trivial to implement. He’s done all the hard work - thank you!

You can see all this in the video below.

Empire of Asphalt: Landscape Part 1

Tue, 27 Feb 2024 07:10:00 +0100

Cracked on with the landscape system over the weekend and got a nice SimCity 2000 / Transport Tycoon style isometric system up and running.

It uses the diamond square algorithm with a few constraints added. It was trivial to get a beautiful rolling landscape in place… fiddly to get it looking all chunky and isometric!

I also spent a while wandering why large maps seemed to stop rendering at an arbitary point. Turned out that I’d exceed 64k of indexes for verticies in a index buffer and the type of the values in such buffers is 16-bits.

The solution was to break them into chunks which I wanted to do anyway as when the player is raising, lowering and levelling the terrain I didn’t really want to be regenerating a single very large mesh. With the chunk approach I can just update most of the time a single chunk and at the worst case 4 chunks (when the player changes something on a corner). I guess I could optimise that further to a maxium of 3 chunks by “mis-aligning” the chunks but I suspect the increased complexity isn’t worth the effort.

Next steps are to make sure there are some level parts of the map to start out with and add some water but the hard bit is pretty much done.

You can see the current iteration in the video below and the source is in this commit in GitHub.

Empire of Asphalt: Starting simple

Sat, 24 Feb 2024 15:00:00 +0100

As a brief introduction by next retro remake is based around SimCity which I’m calling Empire of Asphalt. If you want to follow along you can already find the code on GitHub:

https://github.com/JamesRandall/empireOfAsphalt

I’m going to keep things as simple as I can so it will be somewhat akin to the original game in terms of systems though I’ve got some fun ideas for rendering involving an isometric landscape and voxels and might do some fun stuff with agents. Again written using TypeScript and WebGL and not much else.

I’m enjoying working with TypeScript and WebGL - there’s no real friction and its easy to distribute things.

In any case step one is to draw a single tile. Mission accomplished!

Elite: To do

Sat, 24 Feb 2024 08:00:00 +0100

I’m at that stage of the project where there are lots of little things left and so I’ve done what I usually do at this point which is to pop it on a Trello board. Most of these things are evening sized so I’m going to do them in the… evenings. You can see the list below.

I need bigger spans of time to get the foundations in on the next fun project…. so weekends will be more about that. I’ve been doing research for the last two or three weeks.

Elite: combat evolved

Tue, 20 Feb 2024 20:10:00 +0100

Got the combat routines all wired up now with damage being handled properly, explosions etc.

Its my first chance to really try the tactic routine for the enemy ships - I’m super pleased with how authentic it feels though the more precise hit boxes are making it a little trickier.

In any case I will post a video later this week.

Elite: fix for laser collisions

Tue, 20 Feb 2024 06:45:00 +0100

Ok. So here’s the revised collision detection code:

function processLaserHits(game: Game, resources: Resources) {
  // all we are really interested in for deciding if a player has hit a ship is the intersection of the bounding
  // box of the ship onto a 2d plane. To do this we take each face of the bounding box, discard the z, and look to see
  // if our laser axis (represented by point [0,0]) falls within it by breaking the face into two and using
  // barycentric co-ordinates to see if we are in the triangle

  const hit = game.localBubble.ships.reduce((hit: ShipInstance | null, ship) => {
    if (ship.position[2] > 0) return hit
    if (hit !== null && hit.position[2] > ship.position[2]) return hit

    const translatedBoundingBox = ship.boundingBox.map((v) => {
      const v2 = vec3.add(vec3.create(), v, ship.position)
      return vec2.fromValues(v2[0], v2[1])
    })
    // This depends very much on the order that the bounding box is created in
    const faces = [
      // front
      [0, 1, 2, 3],
      // back
      [4, 5, 6, 7],
      // left
      [0, 3, 4, 7],
      // right
      [1, 2, 5, 6],
      // top
      [0, 1, 5, 6],
      // bottom
      [2, 3, 6, 7],
    ]
    const testPoint = vec2.fromValues(0, 0)
    for (let fi = 0; fi < faces.length; fi++) {
      const face = faces[fi]
      const quad = [
        translatedBoundingBox[face[0]],
        translatedBoundingBox[face[1]],
        translatedBoundingBox[face[2]],
        translatedBoundingBox[face[3]],
      ]
      const triangles = createTrianglesFromQuad(quad)
      if (isPointInTriangle(testPoint, triangles[0]) || isPointInTriangle(testPoint, triangles[1])) {
        return ship
      }
    }

    return hit
  }, null)
  if (hit === null) {
    resources.soundEffects.playerLaserMiss()
  } else {
    hit.isDestroyed = true
    resources.soundEffects.shipExplosion()
  }
}

Its similar to the previous version but is based around hit detecting each face of the cube in XY space rather than trying to fit a quad around the bounding box (which actually makes no sense at all… what was I thinking, or dreaming!).

There’s definitely some scope for improvement in the above but it does, at least, work!

Elite: well that's put a crimp in an otherwise damn fine plan

Mon, 19 Feb 2024 20:30:00 +0100

The oh so clever 2D solution for laser intersection doesn’t work I realised this evening. That’s what happens I guess when you literally dream a solution. Problem with it is how I determined the outline quad - its flawed as it can result in the same points being repeated.

What I’ve done instead this evening is to do the same but with each face of the bounding box. If you visualise it this basically results in the box being projected into 2D.

Elite: spawning tweaks

Mon, 19 Feb 2024 07:30:00 +0100

I’d come across a very funny bug the other day - while testing the lasers and explosions I destroyed a space station and about the same time ships started to spawn at a rapid rate. Several s second. A literal stream of ships.

I thought the issue was connected to me destroying the space station as I hadn’t intended to allow that (I just haven’t coded in the block yet as its convenient for testing) but I’d forgotten that an Anaconda can spawn a ship and what was actually happening was that a friendly trader was spawning in the area and it was, you guessed it, an Anaconda. The tactics routine for the Anaconda was still using the timings from the original game, which is based on loop executions, and I was running at 60fps - 60 runs throught the loop per second with a probability of spawn calibrated for a fraction of that speed… yeah lots of ships.

The fix was simple… adopt the same approach used in other tactics routines to not evaluate as frequently.

I did, however, get a fun sense of how much headroom their is in the code to maintain the frame rate. Answer: a lot. Left it running for ages and it continued to maintain its frame rate without dropping a beat. Modern JavaScript engines are really well optimised. There’s a video below.

I’ve also made the same tweak for ships launching from space stations as that was a bit mad too!

Elite: sound effects and explosion refinement

Sun, 18 Feb 2024 16:45:00 +0100

Refining Explosions

On looking at the explosions this morning I realised that the faces of the ship that I use to form the explosion didn’t start off in the correct position. This resulted in a moderate amount of head scratching before I realisesd what was going on.

Each of the faces has its own normal and I’d used that as the nose orientation of the face so that I can roll and pitch it by a random amount as it flies off into space. Trouble is that the renderer, based on the ship renderer, assumes that the faces are aligned based around the ships nose orientation and so when you come to render them they look all jumbled.

To rotate and pitch the fragments correctly they do need their own nose (and roof) orientations and so the solution was to calculate the (vector) delta between the nose orientation and the face normal when the explosion is initiated and when rendering to use this to translate the nose orientation of the fragment back to “ship nose orientation”. Problem solved! And the explosions look pretty cool now.

Audio

There aren’t many sound effects in the original game but they do help bring things to life. When working with old games you can futz around with old, and often proprietary, sound formats. Or, in the case of even older games like Elite, attempt to recreate the effects based on the programming of the sound chip. Neither are much fun (not to me anyway).

A nice little hack I first used when recreating Wolfenstein 3D was to capture the audio directly from the game while playing it. I use a Mac for development and Rogue Amoeba make a great pair of tools for doing this.

First they have Audio Hijack which will record audio directly from the device and it pairs nicely with Fission which is great for quickly trimming and outputting as MP3. They work great together to capture old game audio in emulators.

And so this afternoon I spent some time playing the original game in BeebEm (there is a Mac version for modern hardware here) and recording the sound effects.

I’ve also taken the same approach as Wolfenstein for playing them back which is to create instances of HTMLAudioElement with the paths to the mp3 files. In order to play overlapping instances of the same sound I create a little wrapper for an array of them for each sound:

function createSingleAudioPlayer(path: string): Promise<HTMLAudioElement> {
  return new Promise((resolve) => {
    const player = new Audio(path)
    player.addEventListener("canplaythrough", () => resolve(player), false)
  })
}

async function createAudioPlayer(path: string) {
  const players: HTMLAudioElement[] = []
  for (let i = 0; i < 4; i++) {
    players.push(await createSingleAudioPlayer(path))
  }
  let currentIndex = 0
  return function (volume: number = 1.0) {
    players[currentIndex].volume = volume
    players[currentIndex].play()
    currentIndex++
    if (currentIndex >= players.length) currentIndex = 0
  }
}

I create these on startup of the game and wait for them to load so as not to have any stuttering when playing back.

Elite: laser collision detection, enemy lasers and explosions

Sat, 17 Feb 2024 19:00:00 +0100

I rattled through a load of stuff today, the brain was working well despite no sleep!

Player laser hit detection

Bizarrely one morning in the week I woke up with the approach to this already in my head. I guess it had been percolating for a while as I haven’t had much time to code this week. My solution is essentially to treat it as a two dimensional problem.

I’m already tracking rotated bounding boxes of the objects in the game world which I implemented to help with the docking process. That being the case the solution I took was to “project” them on to a 2D plane (left most point of the box, top most, etc.) to form a quad:

function createLaserCollisionQuad(ship: ShipInstance) {
  const xy = (v: vec3) => vec2.fromValues(v[0], v[1])
  const translatedBoundingBox = ship.boundingBox.map((v) => vec3.add(vec3.create(), v, ship.position))

  return translatedBoundingBox.reduce(
    ([leftMost, rightMost, topMost, bottomMost], v) => [
      v[0] < leftMost[0] ? xy(v) : leftMost,
      v[0] > rightMost[0] ? xy(v) : rightMost,
      v[1] > topMost[1] ? xy(v) : topMost,
      v[1] < bottomMost[1] ? xy(v) : bottomMost,
    ],
    [vec2.fromValues(10000, 0), vec2.fromValues(-10000, 0), vec2.fromValues(0, -10000), vec2.fromValues(0, 10000)],
  )
}

The players laser can be treated as a point - it fires down an axis and depth isn’t relly relavant (I may add a basic distance check) and so we can simply check to see if the “point” is inside the quad.

To do this take the quad and break it into two triangles:

function createTrianglesFromQuad(quad: vec2[]) {
  return [
    [quad[0], quad[1], quad[2]],
    [quad[2], quad[3], quad[0]],
  ]
}

And now I have two triangles I use the barycentric approach I took in Wolfenstein to determine if the point is in the rectangle:

function isPointInTriangle(point: vec2, [p1, p2, p3]: vec2[]) {
  let a =
    ((p2[1] - p3[1]) * (point[0] - p3[0]) + (p3[0] - p2[0]) * (point[1] - p3[1])) /
    ((p2[1] - p3[1]) * (p1[0] - p3[0]) + (p3[0] - p2[0]) * (p1[1] - p3[1]))
  let b =
    ((p3[1] - p1[1]) * (point[0] - p3[0]) + (p1[0] - p3[0]) * (point[1] - p3[1])) /
    ((p2[1] - p3[1]) * (p1[0] - p3[0]) + (p3[0] - p2[0]) * (p1[1] - p3[1]))
  let c = 1.0 - a - b
  return a >= 0 && a <= 1 && b >= 0 && b <= 1 && c >= 0 && c <= 1
}

Finally all brought together in a fairly simple piece of code that looks for the nearest hit:

function processLaserHits(game: Game) {
  // all we are really interested in for deciding if a player has hit a ship is the intersection of the bounding
  // box of the ship onto a 2d plane. That results in a quad that we can then split into two triangles and use
  // barycentric co-ordinates to determine if the laser has hit the ship
  // this isn't how the original did it - it used some bit tricks basically

  const hit = game.localBubble.ships.reduce((hit: ShipInstance | null, ship) => {
    if (ship.position[2] > 0) return hit
    if (hit !== null && hit.position[2] > ship.position[2]) return hit
    const quad = createLaserCollisionQuad(ship)
    const triangles = createTrianglesFromQuad(quad)
    //const testPoint = game.player.laserOffset
    const testPoint = vec2.fromValues(0, 0)
    if (isPointInTriangle(testPoint, triangles[0]) || isPointInTriangle(testPoint, triangles[1])) {
      return ship
    }
    return hit
  }, null)
  if (hit !== null) {
    hit.isDestroyed = true
  }
}

At the moment ships are immediately blown up by a laser hit - its letting me test things easily.

Enemy lasers

In the original game the lasers are simple lines and I wanted to keep that aesthetic. Lines are simple to draw in 2D but what, exactly, is a line in a 3D world. They tend to be a bit weird if you use them in WebGL (or OpenGL for that matter). I did experiment with both rendering a LINE_STRIP and also tried using triangles to form a shape but that all looked very weird.

In the end I took a 2D approach to the rendering using an orthographic projection. For the “source” end of the laser I calculated, in the TypeScript code (as opposed to the GPU), the location of the ship firing the laser:

export function projectPosition(p: vec3, projectionMatrix: mat4) {
  const position = vec4.fromValues(p[0], p[1], p[2], 0)
  const projectedPosition = vec4.transformMat4(vec4.create(), position, projectionMatrix)
  const x = projectedPosition[0] / projectedPosition[3]
  const y = projectedPosition[1] / projectedPosition[3]
  const viewportX = ((x + 1) / 2) * dimensions.width
  const viewportY = ((1 - y) / 2) * dimensions.mainViewHeight
  return vec2.fromValues(viewportX, viewportY)
}
const sourcePosition = projectPosition(ship.position, projectionMatrix)

Its fairly standard 3D to 2D maths. With this done I tried a couple of approaches with the lasers target end. Initially I tried to aim them at the player but that just looked weird and odd - you end up with a line ending in the middle of the screen. Next I tried basically drawing the laser along the nose orientation of the source ship and force it off the screen. This works pretty nicely:

const target3DPosition = vec3.add(
    vec3.create(),
    ship.position,
    vec3.multiply(vec3.create(), vec3.normalize(vec3.create(), ship.noseOrientation), [100, 100, 100]),
)
const targetPosition = projectPosition(target3DPosition, projectionMatrix)
const xGrad = (sourcePosition[0] - targetPosition[0]) / dimensions.width
const yGrad = (sourcePosition[1] - targetPosition[1]) / dimensions.mainViewHeight
const endPosition = vec2.fromValues(sourcePosition[0] - xGrad * 100000, sourcePosition[1] - yGrad * 100000)

I then just render this as a line strip using the orthographic projection I mentioned earlier.

Quite happy with it and it looks pretty faithful to the original game. I will probably swing back and apply a little bit of randomisation to the direction.

Explosions

For the explosions I wanted to try and show the ships breaking apart. To do this I updated the ship model loading code to also load the ship model as a set of separately positional and renderable faces.

To trigger the explosion I replace the model of the ship with the separate set of faces. It should look exactly the same to begin with but I’ve got a bit of a problem with that at the moment however the effect already looks pretty good:

There’s still a bit of work to do on this and I’ll probably come back and add some particle effects too.

Elite

Sun, 28 Jan 2024 10:04:13 +0100

You can play the latest work in progress of the game online here and the source code is on GitHub.

Elite is absolutely one of my formative experiences - videogame or otherwise. It launched in 1984 on the BBC Micro at a time when most games were either clones of arcade games or following the same basic structure of scores, levels and lives presented using 2D graphics.

Then there was Elite. A fully 3D game set in an open world with no real goal other than the vague aim of improving your combat rating to that of Elite. You could trade, collect bounty on pirates, trade, upgrade your ship and generally explore the 8 galaxies. All this on an 8-bit micro with about 20k left after the video memory. Crazy. Insane. Quite literally game changing.

8 year old me played this game obsessively. I was at the perfect age for my imagination to fill in the blanks as I traded and blasted my way across the galaxy. I have no idea how many hours I sunk into this game but it was a lot. An awful low. I ater played it on the PC (Elite Plus - a rather excellent version by Chris Sawyer of Transport and Rollercoaster Tycoon fame) and on the Acorn Archimedes that was in the office of my first professional programming job. ArcElite is often regarded as the definitive version but I confess I have a real soft spot for the BBC Master 128 and PC versions. You can play the original game via emulation online here.

It spawned a bunch of “sort-of” sequels. I say sort-of because the early sequels (the Frontier games) overly focused on realism and Elite: Dangerous is a massively different kettle of fish. There is also the fantastic OOLite - an open source recreation / reimagining of the game that I highly recommend.

The idea of writing some sort of homage to the game has tickled me for a long time but for some reason it always struck me as “too complex and too big”. Which given it fits into an 8-bit micro is, in some ways, kind of absurd. A couple (I think) of years back I came across Mark Moxon’s mind blowingly comprehensive and entertaining breakdown of the original games source code and systems and I was struck by how so much was done with so little. Yes their is quite a bit going on but taken on its own each sub-system of the game is (unsurprisingly, again: 8-bit) simple.

Then late last year I watched this excellent YouTube video on the game and that was the final push I needed. I started off just experimenting to see if I could render the ships and the answer to that was a fairly resounding yes:

From their I started to build out basic systems like movement. I’ve tried, where it doesn’t make for a world of pain, to stick to the way the original game works.

And on from there to additional systems leading me to where the homage is today:

As I write this the game is still a work in progress but a good number of key systems are up and running:

Rendering (pretty much complete)
Procedural generation of the galaxies
Dashboard
Short range system chart
Hyperspace
Trading
System details
Player details
Jumping / warping (the original game does a “jump” to help you get to planets faster, I’ve replaced it with a warp effect)
Docking computer (needs a bit of work when engaged on longer distances)
“Retro” style effects like CRT and green screen monitors (I used to play it on a tiny green screen monitor)

I’m literally about to start on combat which is the last major system to implement.

Check back soon for updates.

Wolfenstein 3D

Sun, 28 Jan 2024 09:04:13 +0100

You can play the game online here.

Back in early 2022 I’d been making one of my regular revisits to 90s videogaming and spent a fun couple of hours playing Wolfenstein 3D by iD Software. I still have vivid memories of downloading and playing this back in 1992 from a BBS. I lived with my parents at the time (I’d have been 16) and I remember running round the house proclaiming “this changes everything, this changes everything”. Nobody cared!

Inspired by the game I had a crack at figuring out what it was doing and writing a raycasting engine using Turbo C. I got something working but it ran at a snails pace and had a strange fisheye effect.

For whatever reason while playing Wolfenstein 30 years later the itch started to itch and I decided I have to have another go. I didn’t set off with the intention of recreating the game and first I just tried to write the simplest raycaster I could:

Just plain walls, nothing clever. The source for this can be found on GitHub: https://github.com/JamesRandall/fsharp-simpleraycaster

Next I moved on to adding textures:

Again the source for this can be found on GitHub: https://github.com/JamesRandall/fsharp-simpleraycaster-textured

It was at this point that I decided to go a lot further and recreate the game for which the full source can also be found on GitHub: https://github.com/JamesRandall/fsharp-wolfenstein

If you want to learn more about how it works, including how to avoid a fisheye effect, I did a talk at JetBrains .NET Day 2023 which you can watch on YouTube:

I also began, but didn’t quite finish, a C# version using Blazor. There are a number of blog posts on this very website about that and you can find the source for that here: https://github.com/JamesRandall/csharp-wolfenstein

Sprite Packer

Fri, 22 Dec 2023 10:04:13 +0100

You can download the app from the App Store or view the “official” SprEd store linked page here.

Sprite Picker is a simple, free and easy to use texture and sprite packer for the Mac. It will pack your source images into a single image and create a JSON file containing the offsets of the image in absolute co-ordinates and as texture co-ordinates making it ideal for use with Metal apps. I put it together fairly quickly to get icons into my MetalUI project for my starship tactics game.

You can download the desktop app from the App Store or install the command line version from GitHub:

https://github.com/JamesRandall/spritePacker/releases/tag/v1.0.3

Its OSS and you can also grab the source on GitHub. MIT License so I can’t stop you but all I ask is that you don’t upload other versions to the App Store as that would be a bit shit. If you want to add something submit a PR.

The CLI is self describing, after installing run:

sprite-packer --help

SprEd

Fri, 01 Dec 2023 10:04:13 +0100

You can download the editor from the App Store or view the “official” SprEd store linked page here.

I should say up front that SprEd is not an open source project, rather its available on the App Store for the cost of a couple of coffees. And please don’t email me asking me to make it open source (I might at some point but its not going to be because people want a free sprite editor).

I wrote it because I was using AESprite on my Mac and a different (I forget which now) editor on my iPad. I wanted to work seamlessly across my devices via iCloud and I also had an itch to learn Swift and SwiftUI as I’d not done any native iOS development for some time.

The result was SprEd which I actively use myself.

I’ve got plans at the back of my head to expand it out to also include a level editor and that’s likely to happen if and when I remake an old tile based game.

In any case as there’s a dedicated page on the site I won’t ramble on about it here but wanted to include it for completeness as a recent project.

Oh and it turns out I really enjoyed working with Swift and SwiftUI - I might write a series of posts about it at some point. Pop it on the backlog!

Give By The Mile: Setting up

Sat, 28 Oct 2023 08:30:00 +0100

In 2022, according to Strava’s annual “state of strava” report 24 billion, yes billion, miles were recorded on their platform. Imagine if you could convert 5% of those miles into 1 pence (GBP) and donate it to charity. That would be £12 million collected even before you factor in (in the UK at least) gift aid.

That, basically, is what Give By The Mile is about. A platform for connecting athletes, both aspiring and experienced, with sponsors to collect ongoing recurring donations based around the amount of miles a cyclist covers or ascent they gain, meters a swimmer swims, or miles run by a runner each month.

I’d like it to be a positive contribution on all sides: the donations to the charities and a motivational tool to those, of all levels of fitness, trying to reach their goals. It, in and of itself, is hopefully a public health good.

In practice I see this working as follows:

Fundraisers sign up and pick a charity and set up a donations page. Ideally I’d like to be able to do all this directly and with recurring billing but for the initial MVP I’m looking to make use of the JustGiving API. That means I can notify people about how much they need to donate but can’t directly collect the money.
Fundraisers connect Give By The Mile to their fitness platform. I’m starting with Strava as they have an easy to access API. I’ll then look to move on to things like Garmin (who you have to apply to to gain access the API and seem to want you to already have your software before they’ll commit to you - very chicken and egg), Apple HealthKit (probably need an app), Wahoo etc. I’ll also support the upload of FIT files for folk who would rather do things that way.
Sponsors sign up and find an athlete - either someone they know, someone through a search on the site to find compatible athletes (charity and probably donation range). They then pick how they want to sponsor that athlete and optionally set a maximum donation.
At the end of each month the totals are tallied and the sponsors and athletes notified. Along the way their will be some graphs and things like that so people can see progress. And eventually you can imagine building a reward system in.

And this, here, is the developer diary that I’m going to try and maintain while I build this platform out. Partly because hopefully there will be some interesting things to talk about but also because the difficulty won’t be in building the platform: it will be getting attention and traction. So I’ll be using every outlet I have to promote this!

First a bit of history. Give By The Mile is actually an idea I had probably about 15 years ago. I wasn’t really a cyclist then but I had started riding my heavy commuter bike longer and longer distances as I’d entered a London to Paris charity ride. It was really hard work! And I kept thinking to myself: this is the hard bit! Back then the ecosystem wasn’t really their - I looked into building it but there were just too many pain points on all sides to make it feasabile for me to do as a tiny project and so I shelved it. I’d registered the domains back then but for some reason had let them go fallow - thankfully no one had grabbed them in the interim so they are mine again!

However its stuck in the back of my mind and a few things have come together to really bring this to the front of my mind:

I’ve got really stuck into training for a couple of charity endurance events I’m hoping to do next year. Spent soooo much time on a turbo trainer going up virtual mountains that I could use that bit of extra motivation!
I don’t know if its because as I get older I notice it more or if its actually the case but there seems to be so much struggling and suffering around and I’d like to do something about it. Sure I can do individual events but being a moderately talented software developer what I can really do is build things that act as multipliers.
My mum is quite ill and it is absolutely shocking how little support there is available from the National Health Service. I’m not going into the politics of all that here, the subject is complex to say the least, and I’m certainly not suggesting there aren’t hard working people in the NHS but essentially support (what little their is) comes from the various charities in the space. This sort of thing really brings things into focus.

I’ve spent time over the last couple of weeks talking to people who ride bikes, who run charities, and folk who’s broad view on sectors I respect and I’ve had nothing but encouragement. I figure the absolute worst that can happen is that it fails, it costs me a little time (but likely I’m having fun in that time!), and I move on. But best case - it takes off and makes a real difference to peoples lives. How awesome would that be!

So that’s the history and my motivations out of the way. On with what I’ve been up to over the last week or two.

As its gestated for over 10 years in my head how the system works is pretty well explored in my mind so I’ve been focused on picking the tools and technologies I’m going to be using and doing some proof of concept work where they are new to me. I always start a new project by thinking about my obvious constraints. For this project the two big ones are fairly obvious.

I’m working on this on my own. I need tools, and an architecture, that supports a tiny team in being productive. Even though its not a huge project there is a lot of ground for one person to cover.
It needs to be cheap to run. To begin with I’m funding this myself and I’d like to be able to do that for some time. But even if I get to the point where I’m funding it externally or more directly the lower the overhead the more money goes to the charities.

I’m going to give my thoughts on the first point here and we’ll pick up (2) in a future post.

If you’ve followed me for a while or seen me present you’ll know I’m a big fan of using Fable with F#. This lets you write end to end F# on both the server and the client - it transpiles the F# to JavaScript and their are bindings for React and other libraries. And you can get fairly seamless interaction between the server and the client by using Fable Remoting.

However I’m not using F# for this project. But I am using some of the key takeaways I learned from that. They were:

Using the same language end to end is a massive productivity boost. The obvious benefit is that you can share code (models for example) but the real, and massive, benefit is the increase in “flow state” for a developer. I’m a pretty comfortable polyglot but not having to context switch between, say, C# and TypeScript is a huge productivity boost. Transformative.
For small to medium projects dispensing with as much ceremony as possible makes things far more maintainable and quicker to iterate on. That’s not to say your code should be chaos and carnage. Absolutely not. You need a structure. But bringing things closer together rather than decoupling to the nth degree makes it a lot easier to get stuff built. Heresy to some I know but a lot of the patterns people habitually use are there to support testing and large or multiple teams. There are other ways to achieve the former and if you’re not a large or multiple team organisation…

So why am I not using F#? Doesn’t it tick those boxes? Yes. But…. I am almost certainly going to open source this project once I’ve got enough of a foundation in place and with a bit of luck perhaps I can get some help in the development. That’s far more likely to happen if I’m using a more mainstream language and runtime. Additionally there has been some really interesting things happening in the JavaScript/TypeScript space that, after doing some research, I want to take advantage of.

If I know .NET (I also know TypeScript and JavaScript so its not really a deciding factor for me but anyway) why not C# and Blazor? Every time I’ve looked at Blazor its felt unfinished in some way. And its very much in its own little world. I like ASP.Net Core (and they’ve made strides in reducing ceremony for sure) but the UI options just don’t jive with me. I don’t know what it is about Microsoft and UI technology but I always find it…. grim. That’s a personal thin sure. But I’m a person. And I have to use this stuff to write a lot of code and stay engaged. So for all those reasons that stack is out….

I feel I’ve written a lot here. And I have some more code to write! And so I’m going to leave this on a bit of a cliffhanger. Stay tuned for the next update where I’ll talk about where I’ve headed (hint: React is in the mix but its not React).

Featured photo by Aditya Wardhana on Unsplash

GPU Mandelbrot

Thu, 11 May 2023 09:04:13 +0100

If, like me, you grew up coding in the 1980s you’ll probably have fond memories of the Mandelbrot Set - it, and other fractals, were everywhere.

I could be wrong but I think I first came across them in a copy of BeeBug, a magazine that I read avidly! In any case I vividly remember watching one slowly, oh so slowly, render on my BBC Model B.

I’ve always found them fascinating and, as simplistic code for rendering for one is pretty straightforward, I’ve implemented them several times. As part of the Game Engine book I’ve been spending a lot of time recently coding shaders and a weekend or two back I suddenly had the urge to implement a Mandelbrot on the GPU in a shader. You can try the results for yourself online. It works best on a laptop with a trackpad with inertial scrolling (like a MacBook) but also works with a mouse wheel quite well.

Mandelbrot’s are really, really, well suited for parallelised number crunching. Essentially to render a Mandelbrot you visit visit each pixel in the frame, figure out which complex number is associated with it, and then perform an iterative / recursive calculation until an escape threshold is reached: either the resulting value exceeds a given threshold or a defined maximum number of iterations has been reached. In the former case the colour is calculated (how this is calculated is completely arbitrary - it has nothing to do with the actual Mandelbrot mathematics) and in the latter case the colour is deemed to be black.

The important thing, from a parallelisation point of view, is that the calculations for each pixel are independent of the calculations for the other pixel. This is perfect for a GPU and even without doing any tricks simply loading this onto a GPU will result in something that performs like that in the video. As an aside you can do many tricks to optimise the calculation of a Mandelbrot - this absolute genius has one rendering in 12 seconds on a BBC and explains how.

So how does it work?

There’s a really nice explanation over here but for our purposes I’m going to try and describe it really concisely and get into the shaders.

The Mandelbrot is the result of the aforementioned iterative calculations performed on a series of complex numbers. Complex numbers extend real numbers to include what is known as an imaginary number usually donated as i. An imaginary number is any number that satisfies the equation i * i = -1 (as in i squared equals - 1). No real number can satisfy that equation.

Complex numbers can be visualised on a plane where, if z is a complex number, then it can be said that z = x + iy. You can probably see where this is going now - the Mandelbrot lives in a range of values on that plane and so to create our visualisation we’re going to set up a range on this plane and feed that to the GPU and, by mapping that plane onto our screen / window (which is what a vertex shader does) we’ll iterate over the plane running our calculations in the fragment shader.

If you want to know more about shaders and how they work you can find an overview in the book currently being serialised on my Patreon: Game Engine Development with C#.

The code I refer to below can be found in GitHub. The host for it is just some pretty basic HTML and JavaScript that wires up some input events, sets up a canvas, gains access to the WebGL context, and kicks off our render.

Our vertex shader (shader.vert) is incredible simple:

#version 300 es
precision mediump float;
in vec4 vertexPosition;

uniform mat4 uModelViewMatrix;
uniform mat4 uProjectionMatrix;

void main(void) {
  gl_Position = uProjectionMatrix * uModelViewMatrix * vertexPosition; // - vec4(0,-0.5,0,0);
}

Even though its simple there are a couple of things worth noting.

Firstly, we’re using version 3 of GLSL ES. This is important and we’ll see why in the fragment shader. Secondly, our projection matrix is an orthogonal matrix - we want our Mandelbrot to be projected in a 2-dimensional manner and our model view is set up such that the two triangles we render form a rectangle that covers the whole canvas. As such when our fragment shader runs its essentially iterating over every screen co-ordinate.

And so onto our fragment shader which is a bit more complex:

#version 300 es
precision highp float;
uniform vec2 uScale;
uniform vec2 uMin;
uniform float maxIterations;
out vec4 fragColor;

const vec3 baseColor0 = vec3(0.0,7.0,100.0) / 255.0;
const vec3 baseColor1 = vec3(32.0,107.0,203.0) / 255.0;
const vec3 baseColor2 = vec3(237.0,255.0,255.0) / 255.0;
const vec3 baseColor3 = vec3(255.0,170.0,0.0) / 255.0;
const vec3 baseColor4 = vec3(0.0,2.0,0.0) / 255.0;

vec3 interpolate(vec3 color1, vec3 color2, float fraction) {  
  return color1 + (color2 - color1) * fraction;
}

// Colour picking could do with some work
vec3 rgbColorFromIteration(float iteration) {
  float fractionalIteration = iteration / maxIterations;
  if (fractionalIteration <= 0.16) return interpolate(baseColor0, baseColor1, fractionalIteration / 0.16);
  if (fractionalIteration <= 0.42) return interpolate(baseColor1, baseColor2, (fractionalIteration - 0.16) / (0.42-0.16));
  if (fractionalIteration <= 0.6425) return interpolate(baseColor2, baseColor3, (fractionalIteration - 0.42) / (0.6425-0.42));
  if (fractionalIteration <= 0.8575) return interpolate(baseColor3, baseColor4, (fractionalIteration - 0.6425) / (0.8575-0.6425));
  return baseColor4;
}

vec3 mandelbrot() {
  vec2 scaled = vec2(gl_FragCoord.x * uScale.x + uMin.x, gl_FragCoord.y * uScale.y + uMin.y);
  vec2 c = vec2(0.0,0.0);

  for (float iteration=0.0; iteration < maxIterations; iteration++) {
    if (dot(c,c) > 4.0) return rgbColorFromIteration(iteration);
    c = vec2(c.x*c.x - c.y*c.y + scaled.x, 2.0 * c.x * c.y + scaled.y);        
  }
  return vec3(0,0,0);
}

void main(void) {
  fragColor = vec4(mandelbrot(), 1);
}

For us to be able to run our calculations we pass a few parameters into the shader:

uScale - the current zoom level uMin - the top left position on the complex plane we need to render maxIterations - the maximum number of iterations before stopping our calculations

The top half of the shader handles the colour selection - essentially we use the number of iterations to select a colour from a pre-determined palette.

The Mandelbrot calculation is handled in the mandelbrot() function and this is the reason we’re using GLSL ES 3.0. Previous versions of GLSL required for loops to have a constant as their terminator - this is because GPUs like to unbundle the loops. GLSL ES 3.0 added the capability to use none-constant terminators as we have here. Note - you can write a Mandelbrot on an older GLSL version, you simply can’t pass the maximum number of iterations in as a value and have to restructure the code slightly.

Again, this calculation is going to run for every pixel on the screen - and we don’t need a uMax as an input because that’s essentially defined by uMin + screenSize * uScale. We just need to know where to start. We can determine which pixel is being rendered by the fragment shader by using glFragCoord which is a global that tells us exactly this. And by combining this with uMin and uScale we know where on the complex plane we are.

There are just a couple of things worth noting about the JavaScript wrapper. To support touch gestures (you can pinch on a touch screen) I used a handy library called ZingTouch and the vector and matrix maths used alongside WebGL come from the glmatrix library.

And that’s it really. Pretty simple. A GPU powered Mandelbrot.

That said… I couldn’t help but implement the same algorithm on a BBC (I used an emulator, though I do have a real BBC Master 128) using BBC BASIC to see how long it would take. I left colour selection out and used a low resolution mode (160x256) and you can see the code below:

10 MODE 2
20 VDU 23,1,0;0;0;0;
30 GCOL 0,1
40 XMIN = -2.1
50 XMAX = 0.9
60 XSTEP = (XMAX-XMIN)/1280.0
70 YMIN = -1.0
80 YMAX = 1.0
90 YSTEP = (YMAX-YMIN)/1024.0
100 FOR X=0 TO 1280 STEP 8
110     FOR Y = 0 TO 512 STEP 4
120         MX=0
130         MY=0
140         SCALEDX = X * XSTEP + XMIN
150         SCALEDY = Y * YSTEP + YMIN
160         CX = 0.0
170         CY = 0.0
180         ITERATION = 0
190         PCOLOR = 0
200         REPEAT
210             IF ((MX*MX) + (MY*MY)) > 4.0 THEN PCOLOR = 1
220             MXTEMP = MX*MX - MY*MY + SCALEDX
230             MY = 2*MX*MY + SCALEDY
240             MX = MXTEMP
250             ITERATION = ITERATION + 1
260         UNTIL PCOLOR <> 0 OR ITERATION > 50
270         IF PCOLOR <> 0 THEN PLOT 69,X,Y : PLOT 69,X,1023-Y
280         MY = MY + YSTEP
290     NEXT
300     MX = MX + XSTEP
310 NEXT

Which resulted in the following Mandelbrot:

Even though I cheated a little (I knew I wouldn’t be zooming and that the Mandelbrot is symmetrical and so I only calculated half the height of the screen and mirrored it) and is running in such a low resolution it took over 1 hour to generate this.

That said as I mentioned earlier someone has done far far far better than this (12 seconds for a coloured Mandelbrot). Its still remarkable though as a sense of how much faster hardware has got: on my M1 Max MacBook the GPU was rendering this at 60fps+ in basically 4K resolution without skipping a beat.

Incredible really.

3D Spectre Maze

Sun, 30 Apr 2023 20:04:13 +0100

Way back in 1981 a genius named Malcolm Evans managed to coax a 3D game out of a Sinclair ZX81 (an 8-bit micro with a Z80 CPU and 1Kb of RAM). It randomly generated mazes and used low resolution “character block” graphics to display them in 3D complete with a monster that chased you. The game was called 3D Monster Maze and it really was amazing to see back then and remains an impressive feat of coding.

Maze generation algorithms are a fun rabbit hole to go down and rendering the view using similar block graphics in a console window is a kinda fun and neat trick and so I figured this might make for a neat little project.

The source code for this project can be found on GitHub and you can see the video attached to this post.

We’re going to take a fairly functional approach to this code. C# isn’t perfect as a functional language, unsurprising given its roots, but its passable and I find this kind of project lends itself well to a functional approach. If anything its always interesting to explore an approach that is different (for example rather than use interfaces, such as IAlgorithm, I’ve used function signatures here).

If you want to spin it up and give it a go then I recommend setting your terminal to 100x48 characters in size as a minimum - this is the size of the canvas we use to render the maze. The keys are:

Up - move forwards Down - move backwards Left - rotate left Right - rotate right M - show the overhead map Escape - quit the game

Maze generation

We’re going to explore two maze generation algorithms and these can be found in the Algorithms sub-folder of the solution.

Recursive Backtracking

Our first algorithm is possibly the simplest maze generation algorithm you can implement. It has the following flow:

Prefill the maze grid so that its entirely “solid”
Choose a random starting point in the grid and mark it as “empty”
Pick a random direction to an adjacent cell that hasn’t yet been visited and mark this new cell as “empty”
If we can’t pick a new direction because all the cells have been visited then back up the chain until you reach a cell that has new directions for us to move in.
Repeat until all cells have been visited - you can recognise this because the back up will go all the way to the starting cell and it will have no new directions to go in.

A worked example is the best way to illustrate this. In the below the blue represents the current path accumulated across the recursion with the light blue being the tip (or current cell) of the path. Dark grey are unvisited cells while white cells are cells that have been visited and completed. At the end of the animation you can observe the path completely unwinding back to the starting point:

As an aside this animation has been created by a tool called MazeGenerationAnimationGenerator (a bit of a mouthful I realised after creating it) that uses the observer approach we’ll discuss later to inspect the steps of the maze generation and generate a animated GIF file. The same observer approach is used to display the larger maze shown below. This involves over 8000 frames of animation (I hadn’t really built the tool to create animations of this size so it ended up consuming about 18Gb of memory to do this!) and gives a sense of how the number of steps grows significantly as the maze size increases (the 6x6 example shown above is about 130 steps):

The code for the algorithm is really quite simple:

void Walk(MapVector position, ImmutableList<MapVector> path)
{
    path = path.Add(position);
    observer(map, path);
    foreach(var direction in Directions.All.OrderBy(_ => random.Next()).ToArray())
    {
        var next = position + Directions.Vector[direction];
        var oppositeDirection = Directions.Opposite[direction];
        if (next.WithinBounds(width,height) && map[next.y,next.x] == Direction.None)
        {
            map[position.y,position.x] |= direction;
            map[next.y, next.x] |= oppositeDirection;
            Walk(next, path);
            if (trackPath) observer(map, path);
        }
    }
}
Walk ( position: new MapVector (x: random. Next(width), :random.Next(height)));

We store our maze as a two-dimensional grid of bitmasked directions, those directions describe which way the player can move within the cell and therefore the inverse of this represents the walls (if a player can’t move in a given direction its because their is a wall there).

Beyond that there’s just a couple of things to note in the code:

We use some basic bit twiddling to combine the directions.
When we move to the next cell we mark the current cell as being able to move in the direction of the next cell, and we mark the next cell as being able to move back to our current cell (the opposite direction).
We randomise the directions on each walk otherwise we’d end up with a maze with a very specific bias:
We combine a “stay within the bounds of the grid” constraint with our untouched check to prevent the maze generator meandering out of the bounds of the array.

Hunt and Kill

If recursion isn’t your thing (it could be problematic if you have large mazes and limited stack space) then an alternative algorithm is the hunt and kill algorithm. It’s a little more complicated to both explain and implement but here we go.

Pick a random starting location
Walk in a random direction to any untouched cell
Keep walking randomly until there are no untouched cells to move to
Now “hunt” - search the maze for an untouched cell that is next to a touched cell then start walking again (step 2)
Repeat until hunt cannot find a cell, at which time the maze is done

I’m never quite sure where the kill comes from in the name, perhaps it was added to make it sound cool. Walk and hunt doesn’t have quite the same ring I guess.

Again a worked example is shown below:

And again the same algorithm working on a bigger maze - this took far fewer frames, just over 4000, and consequently less memory (partly because there is no backtracking but also because the hunt steps are not illustrated):

The code is a little more involved here, I don’t think its particularly complicated but there are a number of moving parts and we introduce some helper functions so we don’t repeat ourselves as hunt and walk share a number of common components. Firstly we have our core loop that basically maps onto the steps above:

var position = new MapVector(random.Next(width), random. Next(height));
while (position.IsValid)
{
    observer (map, ImmutableList<MapVector>.Empty);
    position = Walk(position);
    if (Iposition. IsValid) position = Hunt();
}

Simple enough! Then we have our walk method:

MapVector Walk(MapVector position)
{
    var possibleDirections = GetPossibleDirections(position,LookingFor.Untouched);

    if (possibleDirections.Any())
    {
        var direction = possibleDirections.MinBy(_ => random.Next());
        return UpdateMap(position, direction);
    }

    return MapVector.Invalid;
}

This makes use of a simple helper method, GetPossibleDirections, that can return an array of directions we can move in based on whether we are looking to move to an untouched (during walk) or touched (during hunt) cell:

Direction[] GetPossibleDirections(MapVector position, LookingFor lookingFor)
{
    bool IsValid(Direction value) =>
        lookingFor == LookingFor.Touched ? value != Direction.None : value == Direction.None;
    var cx = position.x;
    var cy = position.y;
    
    var north = cy > 0 && IsValid(map[cy - 1, cx]) ? new[] {Direction.N} : new Direction[] { };
    var east = cx < (width - 1) && IsValid(map[cy, cx + 1]) ? new[] {Direction.E} : new Direction[] { };
    var south = cy < (height - 1) && IsValid(map[cy + 1, cx]) ? new[] {Direction.S} : new Direction[] { };
    var west = cx > 0 && IsValid(map[cy, cx - 1]) ? new[] {Direction.W} : new Direction[] { };
    var possibleDirections = north.Concat(east).Concat(south).Concat(west).ToArray();
    return possibleDirections;
}

Finally if we manage to walk to an untouched cell then we update the map and return the new position, we do this using another little helper function called UpdateMap:

MapVector UpdateMap(MapVector mapVector, Direction direction)
{
    var nextPosition = mapVector + Directions.Vector[direction];
    var oppositeDirection = Directions.Opposite[direction];
    map[mapVector.y, mapVector.x] |= direction;
    map[nextPosition.y, nextPosition.x] |= oppositeDirection;
    return nextPosition;
}

This is very similar to what we saw in the recursive backtracker - when we open up a direction we open it up in both directions.

If walk can’t move to an untouched position then we enter our hunt phase. Hunt essentially iterates over our array and looks for a touched cell with an untouched cell next to it:

MapVector Hunt()
{
    for (var mapY = 0; mapY < height; mapY++)
    {
        for (var mapX = 0; mapX < width; mapX++)
        {
            if (map[mapY, mapX] != Direction.None) continue;
            
            var position = new MapVector(mapX, mapY);
            var possibleDirections = GetPossibleDirections(position, LookingFor.Touched);
            if (possibleDirections.Any())
            {
                var direction = possibleDirections.MinBy(_ => random.Next());
                UpdateMap(position, direction);
                return position;
            }
            
        }
    }

    return MapVector.Invalid;
}

We’re using the same helpers as walk but we reverse the “polarity”, so to speak, when we look for possible directions.

And that’s it. If hunt fails to find a valid position then we’re done and our maze is generated.

Projecting the maze

I find it fascinating to watch the two algorithms side by side. The recursive back tracker feels really quite random in the route it takes whereas the hunt and kill algorithm broadly fills the maze in from top to bottom due to how our hunt for loops are indexed.

In any case at the end of either algorithm we have a two dimensional array that tells us in which direction you can move from any given cell. However the maze in 3D Monster Maze is constructed on a grid from square blocks and so it would be handy for us to project our algorithm output into this format. Despite the code being quite simple strangely I found this the most mind warping part of the project! The code for this projection can be found in the TransformToGrid method in the MapFactory class:

public static ImmutableArray<ImmutableArray<Block>> TransformToGrid(Direction[,] map)
{
    var topRow = Enumerable.Repeat(Block.Solid, Width * 2 + 1).ToList();
    var rows = new List<List<Block>>();
    rows.Add(topRow);
    for (var y = 0; y < Height; y++)
    {
        var row1 = new List<Block>();
        var row2 = new List<Block>();
        // our rows always start with a wall otherwise the maze would be open
        // because we are checking eastwards we don't need to terminate with a
        // wall, the maze generation algorithm itself terminates and all last columns
        // will have no eastward openings
        row1.Add(Block.Solid);
        row2.Add(Block.Solid);
        for (var x = 0; x < Width; x++)
        {
            row1.Add(Block.Empty);
            row1.Add((map[y, x] & Direction.E) > 0 ? Block.Empty : Block.Solid);
            
            row2.Add((map[y, x] & Direction.S) > 0 ? Block.Empty : Block.Solid);
            row2.Add(Block.Solid);
        }
        rows.Add(row1);
        rows.Add(row2);
    }

    var result = rows.Select(row => row.ToImmutableArray()).ToImmutableArray();
    return result;
}

What we’re doing in this code is essentially turning the walls into blocks. Put another way we’re turning each cell in our source, direction based array, into four cells in our grid based array - two across and two down. We’re only really interested in one horizontal direction and one vertical direction from our direction based array and we’re looking to see if we can move east or south.

Every cell in our source directionally based array becomes an empty cell in our target array and that is our top left cell in the new quadrant. If we can travel east then an empty cell is the next cell on the row, if we can’t travel right then a solid block is the next cell on the row - the top right cell in our quadrant. We then apply the same logic going sout but add the cells to the next row: if we can travel south then we add an empty cell to the next row, if not then a solid cell. The next cell on the row is always a solid block. Hopefully the example below helps make this a little clearer:

Rendering

To render to the console we’re going to make use of the excellent Spectre.Console NuGet package. It contains a class called Canvas that essentially lets us “draw” pixels and it also contains a neat little live update mechanism so that things can update in place.

The title screen

The main feature of the title screen is the retro style pixelated font and the code for this can be found in RetroFont.cs. I’ll cover this in more detail in the Game Engine Development posts but essentially each character is defined as a set of bits and then to render them we look for a set bit and if found draw a pixel. The letter R is defined like this, for example:

new byte[]
{
    0b01110,
    0b10001,
    0b10011,
    0b10101,
    0b11001,
    0b10001,
    0b01110
}

And the key rendering code looks like this:

for (var y = 0; y < Layouts[index].Length; y++)
{
    var row = Layouts[index][y];
    for (var x = 0; x < Width; x++)
    {
        if ((row & (1 << x)) != 0)
        {
            canvas.SetPixel(currentPosition.x + (Width - 1 - x), currentPosition.y + y, color);
        }
    }
}

The overhead view

Rendering the overhead view is as simple as iterating over our maze and drawing a light pixel where we have an empty space and a darker pixel where we have a wall. We add the player in as a red square over the top. This code can be found in Renderer.cs:

public static void RenderOverhead(
    Canvas canvas,
    MapVector playerPosition,
    ImmutableArray<ImmutableArray<Block>> map)
{
    DrawRectangle(canvas, 0,0,canvas.Width,canvas.Height,Color.Black);
    for (var y = 0; y < map.Length; y++)
    {
        var row = map[y];
        for (var x = 0; x < row.Length; x++)
        {
            if (playerPosition.x == x && playerPosition.y == y)
            {
                canvas.SetPixel(x, y, Color.Red);
            }
            else
            {
                canvas.SetPixel(x, y, row[x] == Block.Solid ? Color.Grey : Color.White);
            }
        }
    }
}

The 3d view

Before we can render the view we need to grab the slice of the map that the player is looking at based on their orientation. The player can see the edge of the walls alongside them and 5 grid squares in front. The nature of our maze, their are only corridors and no room, mean that the player can never see move than one square either side of them and so we form the player view up from a slice of the map that is 6 grid squares long and 3 wide as shown in the example below:

The code for creating this array can be found in GetPlayerView.cs in Game.cs:

private ImmutableArray<ImmutableArray<Block>> GetPlayerView()
{
    var viewDirection = Directions.Vector[Facing];
    // As we build up the view for the player we need to look at the cells to the left and right of them
    // and the vector for this is based on the direction they are facing
    var strafeDirection = GetPlayerLeftAndRightOffsets();

    var view = new Block[Renderer.DrawDepth][];
    var position = PlayerPosition;
    for (var depth = 0; depth < Renderer.DrawDepth; depth++)
    {
        var leftPosition = position + strafeDirection.left;
        var rightPosition = position + strafeDirection.right;
        view[depth] = new[]
        {
            IsValidPosition(leftPosition) ? _map[leftPosition.y][leftPosition.x] : Block.Solid,
            IsValidPosition(position) ? _map[position.y][position.x] : Block.Solid,
            IsValidPosition(rightPosition) ? _map[rightPosition.y][rightPosition.x] : Block.Solid
        };
        position += viewDirection;
    }

    return view.Select(row => row.ToImmutableArray()).ToImmutableArray();
}

With that done we’re now able to draw the 3D view. To give a sense of perspective the size at which we draw each wall reduces the further away from us it is and the walls next to the player are somewhat special in that we can only see the edges of them. We also want to shade the walls differently the further away from us that they are. We capture this information in another array (which can be found in Renderer.cs):

private static readonly ImmutableArray<(int depth, Color color)> Walls = new []
{
    (2, Color.Black), // walls alongside the player - they can just see the edge of them
    (8, Color.Black),
    (6, new Color(32, 32, 32)),
    (4, new Color(48, 48, 48)),
    (2, new Color(64, 64, 64)),
    (1, new Color(80, 80, 80))
}.ToImmutableArray();

Now, to draw our view, all we need do is walk down the two arrays in parallel drawing our side walls and any facing walls and stoppiig if we reach a block directly in front of us:

public static void Render(Canvas canvas, ImmutableArray<ImmutableArray<Block>> playerView)
{
    DrawRectangle(canvas, 0,0,canvas.Width,canvas.Height,BackgroundColor);
    for (var depth = 0; depth < playerView.Length; depth++)
    {
        var row = playerView[depth];
        var startOffset = Walls.Take(depth).Sum(f => f.depth);
        var endOffset = startOffset + Walls[depth].depth - 1;
        var color = Walls[depth].color;
        
        DrawSidewalls(canvas, startOffset, endOffset, row, color);
        DrawFacingWalls(canvas, row, startOffset, endOffset);

        // Stop drawing if their is a block in front of us
        if (row[PlayerMiddle] == Block.Solid) break;
    }
}

The actual rendering using our canvas is fairly simple. For the side walls we simply draw increasingly short vertical lines for each line of the wall:

private static void DrawSidewalls(Canvas canvas, int startOffset, int endOffset, ImmutableArray<Block> row, Color color)
{
    for (var drawOffset = startOffset; drawOffset <= endOffset; drawOffset++)
    {
        if (row[PlayerLeft] == Block.Solid) DrawVerticalLine(canvas, drawOffset, color);
        if (row[PlayerRight] == Block.Solid) DrawVerticalLine(canvas, canvas.Width - drawOffset - 1, color);
    }
}

And for the facing walls we draw rectangles, they are slightly tricky to position but again fairly simple:

private static void DrawFacingWalls(Canvas canvas, ImmutableArray<Block> row, int startOffset, int endOffset)
{
    if (row[PlayerMiddle] == Block.Solid)
    {
        // Draw facing wall
        DrawRectangle(
            canvas,
            startOffset,
            startOffset,
            (canvas.Width - startOffset * 2),
            (canvas.Height - startOffset * 2),
            HorizontalWallColor
        );
    }

    if (row[PlayerLeft] == Block.Empty)
    {
        // Drawing facing wall of corridor to the left
        DrawRectangle(
            canvas,
            startOffset,
            (endOffset + 1),
            (endOffset - startOffset + 1),
            (canvas.Height - endOffset * 2 - 2),
            HorizontalWallColor
        );
    }

    if (row[PlayerRight] == Block.Empty)
    {
        // Draw facing wall of corridor to the right
        var wallWidth = (endOffset - startOffset);
        DrawRectangle(
            canvas,
            (canvas.Width - startOffset - wallWidth - 1),
            (endOffset + 1),
            wallWidth + 1,
            (canvas.Height - endOffset * 2 - 2),
            HorizontalWallColor
        );
    }
}

And that’s it. That will render our maze in delightyfully chunky three dimensions.

Bringing it all together - the game loop

We bring all this rendering together in a super simple game loop that also lets the player move around the maze in a class called Game which, go figure, can be found in a file called Game.cs. The key part of the class is the Run method shown below:

public void Run(Canvas canvas)
{
    var isOverhead = false;
    AnsiConsole.Live(canvas).Start(ctx =>
    {
        
        var quit = false;
        while (!quit)
        {
            if (isOverhead)
            {
                Renderer.RenderOverhead(canvas, PlayerPosition, _map);
            }
            else
            {
                Renderer.Render(canvas, GetPlayerView());
            }
            ctx.Refresh();
            var key = Console.ReadKey().Key;
            switch (key)
            {
                case ConsoleKey.UpArrow: Move(MovementDirection.Forwards); break;
                case ConsoleKey.DownArrow: Move(MovementDirection.Backwards); break;
                case ConsoleKey.LeftArrow: RotateLeft(); break;
                case ConsoleKey.RightArrow: RotateRight(); break;
                case ConsoleKey.M: isOverhead = !isOverhead; break;
                case ConsoleKey.Escape: quit = true; break;
            }
        }
    });
}

The most notable part of this is the use of AnsiConsole.Live which allows us to update our canvas in place. Without this each render of the canvas would cause the console to scroll as normal behaviour is to append console output. Its a really neat feature of Spectre and you can do some super cool stuff with it!

But otherwise all we are doing here is responding to key presses and updating the display and that’s it: a simple maze game. Well. Its not much of a game, all you can do is wonder around. Interactive experience perhaps?

Simple C++ Voxel Engine

Thu, 08 Apr 2021 20:04:13 +0100

I originally wrote this piece on conclusion of the project in early January 2017. It remains one of my favourite and most fun projects. I went on to do some more demos with it and I’ve attached a video from that at the bottom of the post

Happy New Year everyone - I hope everyone reading this had a great end of year break and has a fantastic 2017.

I suspect I’m not alone in that I like to spend a little time over the Christmas break working (in the fun sense of the word) on something a bit different from the day job. This year I took about 4 days out to work on a really simple voxel engine as both the look and constructible / destructible feel of voxels have always appealed to me, perhaps as a result of a childhood playing with Lego. Though bizarrely I’ve never played Minecraft.

The code for the engine along with a couple of demonstrations can, as ever, be found over on GitHub.

I didn’t want to feel like I was writing glue code and so rather than use an existing library I started with a blank C++ file, OpenGL, and an awful lot of ignorance. Now to be fair I do have a reasonable background in C, C++, graphics and systems programming - before this web thing came along I was working with embedded systems and 2d graphics engines using C, C++ and 68000 assembly - but that was back in 1994. I continued as a commercial C++ developer for 4 more years but then found myself working with C# and the first .Net beta via a brief foray with Delphi.

So I was rusty. Very rusty. However I had enthusiasm on my side and persevered until I had a couple of demo’s and some code that I wasn’t too embarrassed to share. The video below is me navigating a voxel “landscape” created using a black and white self portrait as a height map:

https://www.youtube.com/watch?v=aETUvjQp-yc&t=2s

First step was some early research and I quickly discovered some really useful resources:

GLFW - a great library for abstracting away the underlying hardware and OS and getting you a window to draw in
Glad - OpenGL is a strange, strange, place and chances are you will need to use a “loader” to get access to the full API. This web service makes it really easy.
GLM - A header only mathematics library based on the OpenGL shader specification
Learn OpenGL - tutorial series
OpenGL Tutoral - another OpenGL tutorial series

Being conscious C++ had changed a fair bit since my youthful glory days I also skim read [Accelerated C++](http://Accelerated C++) and Effective Modern C++. I’ll be returning to the latter and reading it in some more depth as I’m sure my code is still pretty stinky - but it works!

Day 1 - I know nothing

Armed with my new found expertise I set myself a goal of generating and rendering a landscape based on Perlin Noise but given I couldn’t yet draw a cube I thought I’d better bootstrap my way up. This first day was the toughest and involved a fair amount of staring at a blank screen, cursing, and feeling extremely thankful for the safety of managed environments. However at the end of the day I managed to get not only a single cube on the screen but a set of voxels arranged into a chunk rendering (a chunk is an organisational concept in a voxel engine - collections of voxels) and you can see that below:

I didn’t yet have any lighting so to help me process what I was looking at I did a simple adjustment of the colours around each vertex.

The next step was to display several chunks together. My first effort at this went… badly. Only one chunk was ever displayed. After spending an hour looking for obscure OpenGL problems I realised I’d done something more basically dumb with C++ (we’ve all copied something we thought we were passing by reference right?), pounded my head into the desk a few times, corrected it and hurrah. 4x4 chunks!

Flush with success wine may have been consumed.

Day 2 - Algorithms and structures

Sitting at the desk with a slightly groggy head - which the wine had nothing to do with, nothing, not a damn thing - I started to ponder how to arrange and manage chunks. The memory requirements for voxels can be huge. Imagine that each of your voxels takes 16 bytes to store it and that your landscape is a modest sized 1024 voxels wide, 32 voxels high, and 1024 voxels deep - that’s 536,870,912 bytes, better known as 512Mb, of storage needed before you even account for rendering geometry.

It’s clear you’re going to need someway of managing that and for practical usage compressing and/or virtualising it.

I came up with, and by came up with I mean I’d read somewhere and recalled it, the concept of a chunk manager (this came up somewhere in my research), chunk factories (this didn’t come up in my research but seems a logical extension) and a chunk optimiser (not yet implemented!).

The main decision here was how low to go - so to speak. The most optimal route likely involves getting the STL out of the way, pre-allocating memory and organising it in a very specific manner. However that also seemed the route most likely to feel like having your teeth pulled. In the end I decided to go with the path of least resistance and mostly used the std::vector class with pre-allocated sizes where known.

Nothing to see from my efforts yet except the cube still shows but using the new code. Which while not worth a screenshot was a result!

With that out the way I needed a perlin noise generator to implement as part of one of my new fangled chunk factories. I’ve written one before for a lava type effect at some point back when you had to find the algorithm in a book and figure out how to write it yourself. Having no wish to repeat that painful experience I quickly found a great post and gist on GitHub written in C# and converted it to C++.

I hit F5, Visual Studio whirred away for a few seconds, and to my utter amazement my good run of luck continued and I had an ugly but working voxel landscape.

Good times. And good times when you’re on your Christmas break deserve wine.

Day 3 - This is far from light speed

Without any lighting it was hard to really get a sense of the terrain in the landscape that I could see but before I could do something about that I needed to address some performance issues. Rendering was fine - I was cruising at a vertical refresh locked 60 frames per second. When rendering started. Problem was that even on my 4.5GHz 6700K i7 it took about 90 seconds to generate the voxels and the initial geometry.

Normally I’d advocate measuring before going any further but the issue was self evidently (famous last words…. but not this time) in a fairly narrow section of code so step 1 was a code review which quickly highlighted a moment of stupidity from the previous day: I was calling the perlin noise function 16 times more than I needed to.

I could see from Visual Studio that memory allocation was also sub-optimal as it was occurring on an “as needed” basis but as previously noted I’m favouring clarity and simplicity over gnarly. However Visual Studio was also highlighting another issue - my CPU was only being used at around 15%. The code is single threaded and I’ve got 4 cores capable of supporting 8 threads.

Haha thinks me with my C# head on. This is eminently parallelisable (the clues being in the names “chunk” and perlin noise “function”) and C++ must have a decent task / parallel library by now. Oh yes. Futures. They’ll do it.

Oh boy. Oh boy oh boy. That hurt. Converting the code to use lambda’s and futures was straightforward but then the issues began - turns out there is not yet an equivalent for something like Task.WhenAll in the C++ standard library. I got there in the end after a bit of a deep dive into modern C++ threading concepts (I really didn’t want to use the OS primitives directly as I want to make this multi platform) and solved this with locks and condition_variables.

I’ve tested it on a variety of systems (with different performance characteristics and cores available) and it hasn’t crashed or done anything unpredictable on a variety of different systems but I’m sure there is something wrong with this code so if any C++ experts read this I’d love some pointers.

So now its quicker, about 6 or 7 seconds to generate a respectably sized landscape, but it looks the same and most of the day has gone.

Fortunately adding basic lighting proved much simpler. Simple voxels, cubes, are pretty simple to light as the normals are somewhat obvious and there is plenty of documented examples of using vertex normals inside vertex and fragment shaders to apply the appropriate colouring. A couple of hours later I had ambient, diffuse, and specular lighting up and running and could turn off my dodgy half shading.

A great way to go into New Years Eve and definitely earning of a celebratory brandy. Slightly warmed and in an appropriate glass of course.

Day 4 - This code stinks

Old Man Randall (me) fell asleep long before midnight and so I woke up fresh and eager on New Years Day to do some more work. I’d had the brainwave a few days ago to use photographs as the source for landscape height maps using the brightness (whiteness in black and white photographs, calculated perceived brightness in colour photographs) of each pixel to build an appropriately high stack of voxels.

However before I could do anything else the code really needed some work. It had the distinctive whiff of a codebase in which many new things had been tried with little idea of what would work or not. Structure had become scrambled, inconsistencies were everywhere, and commented out attempts at different approaches abound. Not to mention I’d built everything into a single executable with no attempt to separate the engine from it’s usage.

A few hours later and although still not perfect I had something that was workable and set about implementing my voxel photographs starting with black and white. Being a supreme narcissist I selected a photograph of myself from my flickr library and busied myself trying to load it. This proved to be the hardest part - I’d forgotten how painful C++ and libraries without package managers can be (is there a package manager for C++?) with chains of dependencies.

In the end I realised that cimg could load bmp files without any dependencies and implemented a new chunk factory that used that to scan the pixels and create voxels based on their whiteness.

This worked a treat and I captured the video of me moving around the “landscape” that appears at the top of this post.

A great way to finish off and in a burst of enthusiasm I quickly sent the link to my fans. Or fan. By which I mean my mum. No celebratory brandy sadly as structured cycling training has restarted but happiness abounds.

Conclusions and what next?

A few things struck me throughout this short project that I think are worth collecting and reflecting on:

The modern Internet truly is a wonderful thing. The last time I was coding in C++ (about 1998) it wasn’t the Internet of today and things were so much harder. It’s an amazing resource.
The development community is amazing. There are so many people giving their time and expertise away for free in the form of blog posts, articles, and code that unless you’re doing something really on the bleeding edge there is someone, somewhere, who can help you.
Wow C++ has changed - for the better. It’s still complicated but there’s a lot more available out of the box to help you not make simple mistakes.
GPUs are incredible number crunching machines. I’m fortunate enough to have a pretty top notch GPU in my desktop (a 980Ti) but the sheer number of computations being performed to render, in 60 fps, some of the scenes I threw at this code is astounding. I knew in theory the capabilities of GPUs but didn’t “feel” it - I’m now interested where I can apply this power elsewhere.
Iterative approaches are great for tackling something you don’t know much about. I just kept setting myself mini-milestones and evolving the code, not being afraid to do something really badly at first. By setting small milestones you get a series of positive kicks that keeps you motivated through the hard times.
Coding, particularly when it involves learning, is fun. It really is. I still love it. I’ve been coding for around 34 years now, since I was 6 or 7, and it still gives me an enormous thrill. My passion for it at its core is undiminished.

As for this project and what I might do next. I’ve got a couple of simple projects in mind I’d like to use it with and a small shopping list of things I think will be interesting to implement:

Mac / *nix support
General optimisation. I’ve only done the really low hanging fruit so far and there is scope for improvement everywhere.
Voxel sprite support
Shadows
Skybox / fog support
Paging / virtualisation - with this in mind this is one of the main reasons that scenes are constructed using the chunk factory
Level of detail support
Simple physics

Whether or when I’ll get time to do this I’d rather not say, I have a big product launch on the horizon and a React book to write, but I’ve had so much fun that I’m likely to keep tinkering when I can.

Addendum (2021)

Following this post I did some work on collision detection and created a few more demos. I rather liked this city building demo that I recorded at the time.

Mon, 01 Jan 0001 00:00:00 +0000

VoxEd - Elegant voxel sprite editing

A loving homage to the classic golf games of the 1980s with simple gameplay and period visuals

Choose from a variety of rendering styles for maximum nostalgia

PC (EGA)

BBC Micro

Archimedes

Commodore 64

Simple gameplay with 3 built in courses, or use the editor to recreate your local holes

Archimedes

Map

Clubs

Editor

Frequently asked questions

- Will you make the game available on other platforms?
  Maybe. I wrote it for fun but if people enjoy it on iOS and Mac I'll certainly consider it.
- I think I've found a bug or have an idea for an improvement, what do I do?
  You can send an email to me at support@accidentalfish.com and I'll see if I can help.
- Are you planning on adding GameKit support?
  Yes probably, scoreboards and online multiplayer would be neat.
- How about AI players?
  Not sure - I always played these games multi-player but I'll think about it for sure.

What about Privacy?

Our privacy policy is really simple. We don't think you should be spied upon and tracked all over the web or on your devices and so we don't collect any information about you, or your usage of the app, at all.

If you contact us by email then we will never share your email address with a third party or use it for any purpose other than responding to your email.

And finally this website contains no tracking cookies or analytics of any kind. We don't want to know who you are or what you do on the web. We just want you to enjoy using VoxEd.

Mon, 01 Jan 0001 00:00:00 +0000

CSharpWolfenstein

An unhandled error has occurred. Reload 🗙

Mon, 01 Jan 0001 00:00:00 +0000

CSharpWolfenstein

An unhandled error has occurred. Reload 🗙

Mon, 01 Jan 0001 00:00:00 +0000

CSharpWolfenstein

An unhandled error has occurred. Reload 🗙

Mon, 01 Jan 0001 00:00:00 +0000

CSharpWolfenstein

An unhandled error has occurred. Reload 🗙

Mon, 01 Jan 0001 00:00:00 +0000

GPU Mandelbrot

Mon, 01 Jan 0001 00:00:00 +0000

VoxEd - Elegant voxel sprite editing

Satisfying sketching on graph paper for your iPad, iPhone and Mac

Download the app and start creating sketches

Graph Paper is completely free and has a simple design for creating sketches.

Frequently asked questions

- Why isn't there an eraser?
  Deliberate design choice - you can't erase ink! I'm still on the fence on this one, I'll probably put one in
- I think I've found a bug or have an idea for an improvement, what do I do?
  You can send an email to me at support@accidentalfish.com and I'll see if I can help.
- Are you planning on adding more features?
  Yeah probably, a few more simple ones but I don't want this to become a complex app.

What about Privacy?

If you contact us by email then we will never share your email address with a third party or use it for any purpose other than responding to your email.

And finally this website contains no tracking cookies or analytics of any kind. We don't want to know who you are or what you do on the web. We just want you to enjoy using VoxEd.

Mon, 01 Jan 0001 00:00:00 +0000

SprEd - Retro sprite editing brought up to date.

Retro sprite editing for your iPad.

Download the app and start creating pixel art

The standard version of SprEd is free and comes packed with features for editing single sprites.

Use a wide variety of drawing tools and configure the editor in a way that works for you with control over the grid, tool placement and the background.

Use custom palettes or choose from a selection of pre-made classic palettes to get started.

Editing tools include a pencil, spray can, eraser, flood fill, a variety of shapes and cut, copy and paste.

Either create an image with a blank canvas or import an image from Photos, Files or the clipboard.

Upgrade to the Premium version for more advanced features

Unlock a set of advanced features by upgrading to the Premium version with a one-time In-App Purchase.

Preview animations that update in real-time as you edit the frames and control the playback speed and animation source in your spritesheet. You can export your animations as video to share with others.

Use the repeating sprite / texture preview tool to ensure that your repeating sprites will look great when tiled.

Work on sprite sheets that contain multiple related sprites and tiles - great for use in level editors and tile based games.

Import and compose spritesheets from multiple source images or slice from an existing single image

Use layers to structure your images and apply lighting and color effects.

Frequently asked questions

- How do I scroll without drawing?
  You can use one finger to draw and two fingers to scroll. If you're using an Apple Pencil then you can enable Pencil Only Mode and use a single finger to scroll.
- How do I change the pencil width?
  Hole your finger (or the pencil) on the width indicator and move it left and right.
- How do I access the RGB / HSL color picker?
  Tap and hold the color indicator.
- Why do my pictures appear blurry in the Photos app?
  Images are scaled for viewing in the Photos app and this scaling results in the blurry appearance. Exporting them from Photos should result in a clear image, alternatively (and this is how I work) I recommend exporting directly to Files.
- How do I select and use a colour in my image?
  You can long press at any time in the editor and it will pick up the colour under your finger or pencil and set it as the current colour. You can also use the palette options to pick up all the colours in the image and place them in the palette.

What about Privacy?

If you contact us by email then we will never share your email address with a third party or use it for any purpose other than responding to your email.

And finally this website contains no tracking cookies or analytics of any kind. We don't want to know who you are or what you do on the web. We just want you to enjoy using SprEd.

Where do the cool sprites on this website come from?

Its a combination of things drawn by the author and things either purchased or available for free. I can generally tweak artwork to suit my purposes or work from a reference but I'm definitely more a developer than an artist so I tend to look for great affordable artwork that I can use directly or as a base. There are some links below to some of the resources I have used:

Game Art 2D - some great quality artwork, with a super clear license, and very affordable

Where the artwork indicates it is commercial an appropriate license has been purchased.

Mon, 01 Jan 0001 00:00:00 +0000

Fable

Mon, 01 Jan 0001 00:00:00 +0000

VoxEd - Elegant voxel sprite editing

Voxel sprite editing for your Mac and iPad

Download the app and start creating pixel art

VoxEd is completely free and comes packed with features for creating and editing voxel based artwork.

Use a wide variety of drawing tools to create your models.

Use custom palettes or choose from a selection of pre-made classic palettes to get started.

Either create an model with a black canvas or create from an image to generate including using the image as a height map.

Work seamlessly across your iPad and Mac with iCloud

Work seamlessly across your iPad and Mac with iCloud.

Export your models as JSON for use in your own projects or as an image.

Configure the Editor to work the way you want with a range of settings.

Frequently asked questions

- How do I navigate around my model?
  You can use the dedicated cemera controls (the eye icon) but also a wide range of gestures are supported. A single finger drag in empty space will rotate or move the camera (depending on your last choice in the camera tools), two finger dragging will pan, while pinching will move in and out.
- How big can my models be?
  VoxEd is really designed for working on models up to around 128x128x128 voxels. It can handle larger models but performance may be impacted.
- How do I add a colour to the palette?
  Tap and hold the palette button
- I think I've found a bug or have an idea for an improvement, what do I do?
  You can send an email to me at support@accidentalfish.com and I'll see if I can help.
- Are you planning on adding more features?
  For sure, I'm using VoxEd myself to design models for a city builder game and have a roadmap of items. Check my blog for details.

What about Privacy?

If you contact us by email then we will never share your email address with a third party or use it for any purpose other than responding to your email.

And finally this website contains no tracking cookies or analytics of any kind. We don't want to know who you are or what you do on the web. We just want you to enjoy using VoxEd.

Mon, 01 Jan 0001 00:00:00 +0000

webGLite

> Game started

Mon, 01 Jan 0001 00:00:00 +0000

F# Wolfenstein 3D