Joc is an R-Type style shooter I wrote at university on top of my own OpenGL 4.3 engine. Four years later I compiled the whole thing to WebAssembly and WebGL2, which mostly meant discovering every place the engine had been quietly getting away with something. Playable in the post, plus the three bugs that were worth the trip.

An old libGDX sandbox where you click to spawn blocks and watch them fall. Porting it to WebAssembly went fine until I hit the part where the physics engine is C++ and the browser backend has no idea what to do with it.

I dug up an old libGDX project where the entire game is: here's a scrambled adjacency matrix, unscramble it by swapping vertices until it matches the original graph. It's graph isomorphism as a puzzle, and it's stranger and more fun than it sounds.

Growing an island in the browser by gluing together the two things I already wrote about, a branching random walk for the mountains and an inverse FFT for the fine detail, plus one new trick for the coastline.

Gaussian random fields, fBm, midpoint displacement and spectral synthesis. What the theory actually says, why one exponent controls everything, and three demos you can drag.

A small C++ handle that is a shared_ptr, a future, and a scheduler dependency node all at once. You dereference it and it just waits for you. Here is how it works and where it bites.

I built a spreadsheet engine from scratch for a university project — complete with its own formula language, a dependency graph, and higher-order functions that would make Excel engineers uncomfortable.

A collection of low-level C++ Unix experiments: RAII file descriptor wrappers, composable process pipelines, AES stream encryption, UDP sockets, automatic UPnP port forwarding, and a background job scheduler. This is what happens when you spend a weekend in the man pages.

I built Koala to scratch a specific itch: I wanted interactive math and graphics demos embedded directly in blog posts, without reaching for a heavy library or fighting a general-purpose game engine. The result is a small TypeScript framework that sits on top of the browser Canvas API and gives you a pannable/zoomable 2D stage, a few drawing utilities, a GUI system, and some linear algebra helpers. It compiles to a single koala.js bundle.

Adrian is a small demo I made inside Detramotor to play with curl noise. Named after the planet Adrian from Project Hail Mary, a greenish gas giant. The original plan was to recreate that swirling atmospheric look, but I couldn't quite get there, so it ended up as more of a lava planet. This was my first crack at curl noise, so the implementation is more "looks about right" than mathematically rigorous, but I'm happy with it as a first version. I plan to do a proper gas giant version in a future post.

I wrote a particle generator called the Sunflower algorithm, then found out it is not a sunflower at all. It is a branching random walk with geometric decay, and that turns out to be much more interesting.

So I built a particle system for Detramotor (my Vulkan engine) and I think it turned out pretty neat. The idea is simple: keep all the particle data on the GPU, simulate it there with compute shaders, and render it without the CPU ever touching individual particles. It also has a CPU fallback for when you want manual control. Here's what it looks like in action:

I built a LibGDX puzzle game where you navigate a snake across a grid, and the only way to score is by visiting checkpoints when your body length is a prime number. Here's how it works and why prime numbers make surprisingly good game design.

I built a small functional language that takes math expressions and spits out LaTeX. Here is how the grammar, the AST, and the LaTeX printer work together.

Netflix suggests your next binge. Spotify fills your playlist. Amazon tells you what to buy next. I built one of these from scratch in Java for a university project — K-Means, KNN, Slope One, and all.

A few weeks ago, working on a Diligent project, I needed something fairly common in graphics rendering that many people have run into: using multiple textures.

Traditional approach

If you have used OpenGL you probably think this is straightforward. Your textures end up as uniforms in the shader like this:

This is an intermediate chapter to show you the basic structure of a CUDA program for path tracing. It covers uploading the necessary data to the GPU (models, textures, etc.), rendering to a framebuffer, and downloading the result back to the CPU. Think of it as learning how to write custom fragment shaders in pure C, but running on the GPU.

Programming a ray tracer is a classic exercise to learn both GPU programming and the fundamentals of light simulation. It only requires some knowledge of C++ and basic linear algebra, so it is a great entry point into CUDA graphics programming.

For those who do not know Ray Tracing or CUDA

This is a concurrency problem I found interesting while working with multi-threaded C++. I would say it sits at an intermediate level (easy enough to reason about, but subtle enough that a naive solution breaks under scrutiny).

The Setup

You have a shared resource accessed by two kinds of threads: readers and writers. The rules are simple:

I built a statics simulator in high school that solves equilibrium problems by running a real physics engine and doing binary search. Here is how it works.