Andras Schmelczer

Turning Linear Search into the Most Performant Data Processing Engine

Andras Schmelczer — Thu, 01 Jan 2026 00:00:00 GMT

The pitch

There’s an immense amount of publicly available, highly granular data on the UK, especially England and Wales: the price of every property transaction¹, floor areas and construction years², all with full addresses; street-level crime³; noise levels at a 10m by 10m granularity⁴; the full schedule of every public transport option⁵; the location of all trees and woodlands⁶; conservation areas, council houses, listed buildings⁷, schools⁸; and detailed demographics⁹ on education, renting, and so on. When I was looking to buy property, these came in really handy for deciding where to move and knowing what to expect.

There are numerous websites, like StreetCheck¹⁰ or CrystalRoof¹¹, which give you some of this data for a given postcode. My problem was that I only moved to London four years ago, and London has way too many areas for me to have the full picture of all its neighbourhoods. So I wanted to flip the lookup: instead of going from a postcode to its attributes, I wanted to go from the description of my ideal area to the postcode. That’s why I created perfect-postcode.co.uk¹².

Perfect Postcode has found me multiple hidden-gem areas that I’d never even heard of, then fell in love with when visiting in person. It became an easy way to leave the comfort zone of well-known places and get a holistic picture of London instead. On top of this, the site gave me a reality check on what my expectations would cost, and how the equation changes with a compromise or two.

In short, users can filter properties by setting a minimum and a maximum for each attribute. For instance, I can say: only show me properties at most a 10-minute walk from a station, with a noise level of less than 56 dB, and 85 more filters like these. The result is a heatmap of which areas have the most matching properties (based on past sales), suggesting where the criteria are most likely to be satisfied. From there, the next step is to narrow the search to those areas, contact estate agents, get access to off-market properties, and keep an eye on Rightmove and Zoopla.

Rough architecture

The filtering happens on a per-property level: all the public data is projected onto the 25M or so properties, and the results are shown as a heatmap of H3 hexagons of varying granularity, then as postcode boundaries at the highest zoom.

Given the spec, it’s easy to come up with a simple architecture: download all the data, normalise, join, add a filtering UI, and write a backend that applies the filters and returns the matching areas. But then we have to consider one big non-functional requirement: the filtering has to be snappy, so that it’s easy to get an intuitive sense of the cause and effect of changing filters.

The backend has to filter the 25M-row dataset for every query. Given that this is actually a fairly small number, and it’s not expected to grow exponentially over time, I figured we could just keep the full dataframe in memory and see how far brute-force linear search takes us. Effective brute-forcing requires some preparation. So most attributes are quantised to 16 bits, as things like the number of crimes committed or the number of rooms don’t justify anything larger. There’s only a single index: a spatial grid for pruning all but the addresses roughly overlapping the user’s viewport. The data is stored in a row-major format, as queries often filter on a few dozen attributes at once. And the rows are sorted by their spatial position, so the linear search touches contiguous chunks. This makes the scanning incredibly cache-friendly, especially with each chunk iterated over in parallel.

The actual evaluation logic is as simple as:

let base = row * num_features;
filters.iter().all(|f| {
    let raw = feature_data[base + f.feat_idx];
    raw != NAN_U16 && raw >= f.min_u16 && raw <= f.max_u16
})

In the end, it takes around 12 GB of memory to run the server, which is very much justified by the P99 latency it enables: less than 100 ms.

Still, 100 ms plus network latency is too long for proper real-time feedback on the UI. Fortunately, the filters always apply in an AND fashion, and users can only adjust one at a time by changing an attribute’s min/max bounds. This leaves room for a simple trick to make the map more responsive: when a user starts adjusting a filter, the frontend requests that attribute’s min/max values for every visible hexagon or postcode. From then on, the colour coding and filtering can happen on the frontend, without a round trip. You can see both the backend and frontend optimisations in action here:

Of course, there’s a bit more to it, especially around the coarser H3 hexagons: they’re the most expensive to filter on, so they get cached. A lot more data is kept outside the hot path too, such as the history of individual properties, or the travel times: those are pre-rendered for every combination of postcode and destination under different constraints, complete with the full itinerary. But the short version really is that brute force can sometimes be the best solution when applied in a smart way.

Derived data

Besides the open data, the data pipelines powering the app create interesting derived values, like:

Tree canopy density percentile: based on the dataset of all trees and woodlands within the UK
Price growth percentile: to help understand the expanding and shrinking parts of the market
Public transport travel time: calculated for every single station and neighbourhood using R5¹³

What’s next?

Going to viewings and scouting areas in person for six months gave me the perfect feedback loop: whenever the numbers and my impression of an area differed, a feature was missing. Now that the product has been perfected for me, it’s time to iterate on user feedback.

Originally, the app’s main target audience was my partner and me. However, as we added more features, it became apparent that there’s no similar offering on the market, and others could get value out of it too. That’s why I’ve started focusing on Perfect Postcode’s user experience: to appeal to users, it needs convenient features, like saving and sharing filters, explanations, and an actually usable mobile experience, plus a payment flow and some marketing.

price of every property transaction: https://www.gov.uk/guidance/about-the-price-paid-data ↩
floor areas and construction years: https://epc.opendatacommunities.org/↩
street-level crime: https://data.police.uk/↩
noise levels at a 10m by 10m granularity: https://environment.data.gov.uk/dataset/562c9d56-7c2d-4d42-83bb-578d6e97a517 ↩
full schedule of every public transport option: https://www.bus-data.dft.gov.uk/↩
location of all trees and woodlands: https://www.forestresearch.gov.uk/tools-and-resources/national-forest-inventory/↩
listed buildings: https://opendata-historicengland.hub.arcgis.com/↩
schools: https://get-information-schools.service.gov.uk/↩
detailed demographics: https://www.ons.gov.uk/census ↩
StreetCheck: https://www.streetcheck.co.uk/↩
CrystalRoof: https://crystalroof.co.uk/↩
https://perfect-postcode.co.uk/↩
R5: https://conveyal.com/↩

Compounding Self-Hosting

Andras Schmelczer — Thu, 01 Jan 2026 00:00:00 GMT

A small e-ink photo frame for our home. It pulls from a self-hosted Immich¹ library, checks a self-hosted Home Assistant² to see if anyone is home, and puts a photo on the PhotoPainter³ for everyone to enjoy.

Why

Most digital frames offer a choice between two bad options: preprocess photos onto an SD card yourself, or hand your library to a cloud service like Google Photos. Realistically, the SD card gets updated once a year. And I’d rather not give a cloud provider access to my most cherished memories, or let it hold them hostage.

Yet, coming home to a photo from earlier that day, or one from five years ago, hits differently when it’s inside a real picture frame instead of buried in your phone. So I decided to spend a weekend building with Claude Code. After some experimenting with dithering and post-processing, and some fine-tuning of the photo-picking algorithm, I ended up with this project.

A weekend was enough only because of how much came for free: Immich had already run face detection on every photo, already reverse-geocoded the place names shown on the overlay, and already knew our favourites; Home Assistant already knew who was home. That’s the compounding return of self-hosting: every service exposes an easy-to-integrate API, and each new project gets to stand on all of them. I’m now looking for more ways to leverage this.

How it works

The frame is driven by a Raspberry Pi Zero 2W, which is fast enough that I could write plain Python and mostly ignore performance, a luxury after counting individual bytes on an ATtiny85⁴. Cron triggers a script every 15 minutes. Each run:

Quits if it’s between midnight and 7 am. The e-ink display holds its image at zero power, so the last photo of the evening simply stays up overnight.
Asks Home Assistant whether anyone in HA_PRESENCE is home. If not, it quits; no point wasting power and straining the display.
Picks a random photo from Immich, drawn from four overlapping pools: “on this day” memories, favourites, the last 30 days, and the whole library. The weights work out to roughly a 25% chance for a memory (10% if only the ±3-day fallback has matches), 15% for favourites, and 30% for each of the other two. A 7-day rolling history prevents repeats, photos matching the frame’s orientation get 4× the weight, and any candidate whose crop would clip a head is rejected (more on that below).
Crops around any detected faces, boosts contrast and saturation (e-ink is short on both), dithers down to the six-colour palette, and pushes the result to the panel. The photo’s age and EXIF location are painted into the bottom corners as white text with a black stroke, so the dither can’t smear the edges.

Image pipeline

Two choices matter most for how the result looks: the face-aware crop and dithering.

Cropping

The frame stands in one orientation, but I didn’t want to limit it to photos that happen to match. So a face-aware algorithm resize-crops the image to fill the panel, biasing the crop window towards the faces Immich has already detected. A landscape shot with some room around the subject usually crops cleanly to portrait this way. If the crop would cut into any heads, the photo is instead rejected and the picker moves on to the next candidate.

The examples below show how the head bounding boxes steer the final crop, and which candidates get rejected.

Dithering

The panel shows exactly six colours: black, white, red, yellow, blue, and green. There’s no intensity control like on an LCD, so every pixel is one of the six. Anything photo-like has to be dithered, and the candidate algorithms differ wildly in both output quality and running time. Here’s how a few of them compare:

I settled on Atkinson dithering⁵, which keeps the most contrast without too many visible artefacts. Unlike its alternatives, it only diffuses 6/8 of each pixel’s quantisation error, so highlights stay bright instead of getting dragged grey by their neighbours. Dithering was also the first place pure Python became unusably slow on the Pi Zero. So the inner loop, including the perceptually weighted nearest-colour matching, runs through numba which makes it roughly two orders of magnitude faster once the JIT cache is warm.

Learnings

The Pi Zero 2W is overkill. It drains the battery way too quickly if you try to run it cordless, and it spends most of its life idle, waiting for the next cron tick. An RTC wired to an interrupt pin plus deep sleep would have fixed that, but the Waveshare board doesn’t come with one soldered on and I couldn’t be bothered to hack it in. For a battery-powered build I’d reach for an ESP32 with deep sleep instead; with 15 minutes between refreshes, even a slow chip has all the time it needs for the image processing and dithering.

A few reliability quirks worth knowing: the Zero 2W’s Wi-Fi drops when power-save kicks in, so a separate cron job runs wifi-check.sh every 5 minutes to reconnect. I also ensured that swap is masked and journald is set to volatile, because SD-card wear is the only thing likely to slowly kill this build.

I’d also like to try an Inky Impression⁶ in a custom-made frame: a larger display, and perhaps integrated lights, because the e-ink looks a bit muddled in evening light. A dedicated light source would be the greatest improvement by far.

But all in all, the frame already does its job. It stands in the living room as a pleasant speck of curiosity, subtle enough that most visitors never notice it (until I inevitably point it out). But once you know it’s there, catching the panel mid-refresh comes with a small rush of excitement: you’re about to be pulled into a memory, distant or very recent.

Immich: https://immich.app/↩
Home Assistant: https://www.home-assistant.io/↩
PhotoPainter: https://www.waveshare.com/wiki/PhotoPainter ↩
counting individual bytes on an ATtiny85: https://schmelczer.dev/articles/ad-astra-attiny85-game-engine/↩
Atkinson dithering: https://en.wikipedia.org/wiki/Atkinson_dithering ↩
Inky Impression: https://shop.pimoroni.com/products/inky-impression?variant=55186435244411 ↩

A 3-Way Text Merger That Never Shows Conflict Markers

Andras Schmelczer — Wed, 01 Jan 2025 00:00:00 GMT

reconcile-text merges two conflicting edits of the same text into one, without asking a human to sort it out. Where a traditional 3-way merge stops and writes <<<<<<< markers, it applies both sets of changes using an algorithm inspired by Operational Transformation, and repositions any cursors and selections along the way. It’s a Rust library with WebAssembly bindings for JavaScript and native bindings for Python; the interactive demo¹ shows it merging as you type.

The whole API is one call. Give it the common ancestor and the two versions that drifted from it:

import { reconcile } from 'reconcile-text';

// the version both sides start from
const parent = 'Hello world';

// one user added "beautiful"
const left = 'Hello beautiful world';

// the other changed the greeting
const right = 'Hi world';

// "Hi beautiful world"
reconcile(parent, left, right).text;

All three packages expose the same function with the same semantics: cargo add reconcile-text, npm install reconcile-text, or pip install reconcile-text, depending on where you need it.

Why

Merging concurrent edits is a solved problem, provided you control the whole editing stack. CRDTs and Operational Transformation both work by capturing every individual operation as it happens, which is fine when you own the editor, the transport layer, and the storage format. Many workflows aren’t like that: an Obsidian vault gets edited by everything from Vim to VS Code, and all a sync engine ever sees is the final state of each file. That’s a Differential Synchronisation scenario: the last synced parent plus two divergent children, with no record of the keystrokes that produced them.

It’s the same problem Git addresses, except Git hands the hard cases back to you as conflict markers. That’s the right call for source code, where an incorrect merge is a bug and a human has to verify the result. reconcile-text bets that human text is more forgiving: a slightly imperfect sentence is usually better than conflict markers interrupting the flow of a document. (Not every kind of text qualifies: in a legal contract, two edits that combine into a double negation quietly change the meaning. And for code the problem runs the other way: a merge can be semantically wrong even with no syntactic conflict.)

So the library does exactly one thing: three strings in, one string out, every time. It’s the merge primitive underneath VaultLink, my Obsidian sync engine; differential sync only feels right if the merge step never needs a human.

How it works

It starts off like diff3, then adds the conflict-resolution step diff3 refuses to take. Given the parent and the two modified versions:

Tokenisation. The texts are split into the units the merge will operate on: words by default, or characters, lines, or a custom tokeniser. This is a bigger lever than it looks: at word granularity, most prose “conflicts” dissolve into adjacent edits that can both survive.
Diff computation. Myers’ algorithm produces two edit scripts, parent → left and parent → right.
Diff optimisation. The operations are reordered and consolidated so related changes chain together.
The weave. The two scripts are combined using OT principles: each side’s edits are transformed over the other’s, so every modification lands, and cursor positions are carried through each transformation.

I never set out to implement OT for its own sake; transforming batched diffs just happens to be an elegant way to merge two Myers outputs. The same could be achieved with a CRDT. But when all you can observe is end states, merge quality is capped by the quality of the underlying 2-way diffs, whichever machinery does the merging. A moved paragraph, for instance, reaches the merger as an unrelated delete and insert, because that’s all Myers’ algorithm can say about it.

The whole pipeline handles Unicode properly: full UTF-8, with grapheme clusters kept intact so complex scripts never get split mid-character.

Where it sits among the alternatives

Every nearby tool stops short of this job in a different place.

diff3 and Git

diff3 and git merge-file do the structural work, then write <<<<<<< markers whenever both sides touch the same region; so do the libraries that reimplement them: diffy and merge3 in Rust, node-diff3 in JavaScript. reconcile-text shares their diff3-like foundation; the difference is the resolution step that eliminates markers entirely.

diff-match-patch

diff-match-patch is Neil Fraser’s widely used library from his time at Google: character-level Myers diffing, fuzzy matching, and patch application, powering his Differential Synchronisation protocol. It’s the closest tool in spirit, and it differs in four ways that matter here:

2-way, not 3-way. It diffs two texts and applies the result as a patch to a third. There’s no concept of a common ancestor, so it can’t reason about what the left and right sides each intended.
Character-level only. Word- or line-level diffing requires encoding tokens as single Unicode characters first; reconcile-text tokenises natively.
Patches can fail. patch_apply reports per-patch success, and failed patches are dropped. Inside a sync loop, that failure self-corrects on the next cycle, but in a one-shot merge, the edit is simply lost. reconcile-text always produces a complete merged result.
No cursor tracking or provenance. It won’t reposition cursors or tell you which side made which edit; reconcile-text does both.

The repo carries a runnable comparison² with concrete inputs where diff-match-patch garbles adjacent edits and silently drops an entire sentence; reconcile-text merges both correctly. When you genuinely have no common ancestor (two texts that diverged through an unknown sequence of edits), diff-match-patch is the right tool; with an ancestor, the 3-way merge wins.

CRDTs

Yjs, Automerge, Loro, cola, and diamond-types guarantee convergence by construction: every operation commutes, so application order stops mattering. They capture each operation with a unique identity, work peer-to-peer, scale past two concurrent editors, and never lose an edit. The trade-off is state: an operation log or internal structure that grows with the document’s history. You can’t hand a CRDT library three plain strings and ask for a merge; that’s exactly the gap reconcile-text fills. The advice cuts both ways: if you do control the whole editing stack, a CRDT gives you stronger guarantees, and it handles N editors natively where reconcile-text merges exactly two forks at a time (though merges can be chained).

Operational Transformation

OT libraries like ot.js and ShareJS transform live operations against each other, typically with a central server deciding the canonical order. reconcile-text borrows the transformation concept but aims it at a different problem: instead of individual keystrokes in real time, it transforms the consolidated diffs of two complete edits. No server, no operation capture, fully offline. If you need sub-second real-time collaboration and can run a coordination server, use the real thing; this library is for merge points, not keystroke-by-keystroke sync.

One core, three registries

The Rust core compiles to WebAssembly through wasm-bindgen for the npm package and binds natively to Python through pyo3, so all three languages run the same merge logic. The strangest target is React Native: Hermes, its default engine, exposes no WebAssembly global at runtime, so the package’s react-native entry point ships a pure-JavaScript build of the same core, transpiled from the WASM by Binaryen’s wasm2js. Slower, but it behaves the same anywhere JavaScript runs.

If you’d like to poke at the merge behaviour without installing anything, the demo¹ runs that same WASM build directly in your browser.

interactive demo: https://schmelczer.dev/reconcile/↩
runnable comparison: https://git.schmelczer.dev/andras/reconcile ↩

A Fleeting Garden on Your GPU

Andras Schmelczer — Mon, 01 Jan 2024 00:00:00 GMT

Watching millions of independent agents converge into art is fascinating for a while, but really not that long. My favourite art pieces make the viewer part of the work, so this project had to be interactive to live up to my expectations. That was the hard part. The rest was a slime mould simulation inspired by Sebastian Lague’s video¹, of the kind Sage Jenson has taken furthest². I built it while the WebGPU spec³ was still a moving target, because I’d felt WebGL’s limits while ray-tracing 2D scenes⁴ and wanted compute shaders as a first-class concept.

Architecture

The agents’ lifecycle is managed by a compute shader updating an agent array in place. Each individual follows a simple decision-making loop: on every iteration it takes three samples, one ahead of its position and one to each side, then chooses between going straight, turning left, or turning right. Each theme of the app carries a matrix specifying how the agent types relate to one another, either attracting or avoiding each other, or staying indifferent:

The samples come from a map that keeps the history of the agents’ paths and slowly diffuses over time. It’s a texture where the R, G, and B channels each correspond to one agent type’s deposits. I considered using the fourth channel too, but three colours already end up busy enough, and a fourth would’ve made colour theory a fair bit harder for my colour-blind brain.

Make it good

My first experiment let the user draw over the diffusion texture, swaying the mould into changing direction. It turned out to be one layer too detached: it barely changed the behaviour unless the weight was so high that the strokes looked thick. In the end, drawing only spawns new agents on the pen’s path. When there are too many agents on the canvas, old ones get removed as new ones arrive.

Drawing was really fun, but I can’t draw well, and there isn’t enough line smoothing in the world to change that (though adding some did improve my work a bit). So I also added mirroring, a fairly popular tool in drawing programs for turning scribbles into artsy kaleidoscopic symmetries.

Then, to deepen the immersion and give drawing more weight, I added procedurally generated piano sounds that reward more drawing with more complex note progressions.

A lot of minor touches give the app its polish. Theme changes go through the history stack, so the back button works as expected. The toolbar reads the pixels behind it, a 13×7 grid of them, and adjusts its own opacity so it stays legible against any background. And of course, the first thing a visitor sees is 180,000 agents drawing the word Fleeting out of their own trails, then wandering off as the simulation takes over and the letters come apart.

Then make it fast

The simulation is split across six compute-and-render stages, spread over ten WGSL files: agent step, diffusion and decay, brush, eraser (one variant clears the trail, the other kills agents), agent generation with resize and compaction, and the final palette render. A calm frame only touches three of them (agent step, diffusion, and render), and the whole frame goes into a single command buffer with one submit.

The code is kept simple and mostly branch-free; three larger decisions do the rest. Agents write their deposits without blending, because concurrent compute writes to a storage texture don’t blend anyway: when two agents land on the same pixel, one write simply wins. The next diffusion pass smears the survivor across its neighbours, so the lost one is impossible to spot. Keeping the agents contiguous took more thought: each workgroup prefix-sums its own survivors, so compaction costs one atomic per workgroup rather than one per agent. And the agent count follows the frame rate. It starts at a million, sheds 200,000 a second whenever the smoothed rate drops below 90% of 60 FPS, and never falls below 50,000, so a weaker device gets a thinner garden instead of a slideshow.

Give it a try

There’s only so much a blog post can do to describe an immersive art experience. Ultimately, the best way to learn more about it is to give it a try, recommended with the sound on: fleeting.schmelczer.dev⁵.

Sebastian Lague’s video: https://www.youtube.com/watch?v=X-iSQQgOd1A ↩
Sage Jenson has taken furthest: https://cargocollective.com/sagejenson/physarum ↩
WebGPU spec: https://www.w3.org/TR/webgpu/↩
ray-tracing 2D scenes: https://schmelczer.dev/articles/sdf-2d-ray-tracing/↩
https://fleeting.schmelczer.dev/↩

Simple, Sophisticated Backup Strategy

Andras Schmelczer — Sun, 01 Jan 2023 00:00:00 GMT

The more critical a system is, the simpler it should be. In practice, that means building on battle-tested foundations, and adding only the thin layer of logic that you absolutely must have.

My home server’s backup is a good example. I aim for SQLite wherever I can, but reality has added multiple Postgres instances, Redis, message queues, and so on to my self-hosted stack. I still wanted time-machine-style backups with granular file history, which means backing up often (hourly, in my case). But shutting down the stack every hour would’ve greatly inconvenienced my only user (myself), so the only solution was to back up everything live.

I could have gone down the rabbit hole of coordinating each database’s dedicated backup tooling: one bespoke method per service, each with its own failure modes. That would have been anything but simple. Instead I rely on serious databases having a battle-tested crash recovery path.

With this assumption, the backup container turns out to be just a short shell script. Every container volume lives on a btrfs¹ subvolume, so the script can take an atomic snapshot of each. The snapshots are then fed into borg², which handles incrementality and deduplication across local and SSH backup targets. To a database restored from this backup, the state is indistinguishable from a power cut. My backup script’s contribution is just the plumbing: configuring btrfs and borg, handling failures gracefully, and maintaining a healthcheck status for when human intervention is needed.

I’ve been using this since 2023; I’ve restored various files and folders and done two full disaster recoveries. Nothing builds confidence like a restore that works: borg, btrfs, and this little script have earned their keep, and I don’t expect to migrate away any time soon.

btrfs: https://btrfs.readthedocs.io/en/latest/↩
borg: https://www.borgbackup.org/↩

A Real-Time 2D Ray Tracer That Runs on Phones

Andras Schmelczer — Tue, 01 Dec 2020 00:00:00 GMT

My BSc thesis needed two things: a renderer, and something to render. The renderer became SDF-2D, a 2D ray tracer for the browser built on signed distance fields; the something became decla.red, a multiplayer space shooter that proved the renderer could survive a real game loop. This article is about the renderer.

The motivation was mild dissatisfaction: modern 2D games mostly ship flat sprites and no lighting while sitting on ever-faster GPUs. Ray tracing is how you get lighting worth staring at, and in 2D it’s almost cheap enough to run on a phone. Most of my thesis was about the “almost”.

Circle tracing

Sphere tracing renders shapes defined by a signed distance field: it marches along each ray in steps equal to the field’s value at the ray’s current end. Circle tracing is its 2D simplification. The pleasant surprise of 2D is that the geometry needs no rays at all: evaluate the field at every pixel, and a negative value means the pixel is inside an object (values near zero hand you antialiasing for free). Rays are only needed for lighting, so performance is all about how often the field gets evaluated.

Scenes are described in plain TypeScript; a minimal animation of a circle orbiting a light looks like this:

import { CircleFactory, CircleLight, hsl, runAnimation } from 'sdf-2d';

const canvas = document.querySelector('canvas');
const Circle = CircleFactory(hsl(180, 100, 40));

const draw = (renderer, time) => {
  renderer.addDrawable(
    new Circle([150 + 50 * Math.cos(time / 1000), 75 + 50 * Math.sin(time / 1000)], 25)
  );
  renderer.addDrawable(new CircleLight([150, 75], hsl(270, 100, 40), 0.1));
  return true; // flag that more frames are coming
};

runAnimation(canvas, [Circle.descriptor, CircleLight.descriptor], draw);

The descriptor list at the end looks redundant (surely the library can see what I’m drawing?), but it’s load-bearing; I’ll come back to why.

Two passes and a grid

The naive renderer evaluates the field pixels × lights × steps times per frame. Deferred shading fixes most of that: a first pass renders the distance field itself into a texture, the lighting pass reads the memoised values back, and the field gets evaluated once per pixel. The distance pass can even render at half resolution with barely any visible difference.

The second fix borrows from tiled renderers: the screen is split into an 8 by 8 grid, and each tile receives the short list of objects near it before the fragment shader runs, so its pixels never consider the whole scene. In my test scene of 200 objects, the average tile needed to know about 23 of them.

Measured on that scene (200 objects, two lights, 2560 × 1080, a desktop RX 590), with identical lighting code throughout:

Optimisations enabled	FPS	GPU draw time
None	7.5	130 ms
Memoised distance field	60 (capped)	5 ms
Memoised field and tiles	60 (capped)	1.85 ms

That’s a 70-fold speed-up, and the difference between a tech demo and something a mid-range phone can run.

Shadows in 16 steps

The textbook route to soft SDF shadows is Quilez’s ray-marched penumbra technique¹: lovely, but it wants 64 to 128 steps per light and an exact field rather than a lower bound. I ended up with a blunter instrument: march towards the light for 16 steps, divide how far the ray got by how far the light is, and raise the ratio to an arbitrary power to smooth it.

float shadowTransparency(float lightDistance, vec2 lightDirection) {
  float rayLength = 0.0;

  for (int j = 0; j < 16; j++) {
    rayLength += max(0.0, getDistance(uvCoordinates + lightDirection * rayLength));
  }

  return min(1.0, pow(rayLength / lightDistance, 0.3));
}

The closer the ray gets to the light, the less shadow lands on its starting point; that’s the whole theory. There is no physical justification for it. It just runs several times faster than the principled version, tolerates lower-bound fields, and looks right. It also has one known bug: an object standing in another object’s shadow casts a second shadow from the same light. I know it’s there; nobody ever noticed it during testing.

Shaders written by a program

WebGL1 requires loop bounds to be known at shader compile time, but a library can’t know ahead of time how many circles you’ll draw. So SDF-2D writes its own shaders at runtime: it generates a program from GLSL templates for every combination of the object counts each drawable type declares. Each frame then runs the smallest program that fits the scene. Keeping the combinations to a couple hundred programs wasn’t hard. Compiling them all before the first frame is why the library leans on parallel shader compilation (JavaScript is single-threaded; the driver doing the compiling is not). It’s also why runAnimation demands those descriptors up front: the generator has to know every type you’ll ever draw before it can write the shaders.

Surviving the browser

The library also supports WebGL1 alongside WebGL2 (in 2020, iPhones left no choice), degrades gracefully when extensions are missing, and even survives the browser yanking the GPU away mid-frame. I debugged that last failure mode with a simulator that killed and restored the rendering context at random intervals until nothing broke any more.

Field testing in an electronics store

“Runs on phones” is an empirical claim, so the demo page² anonymously logs frame rates. Gathering the data was the fun part: beyond organic visitors and pestered acquaintances, I walked through an electronics store running the demo on every device on display, because the companies that rent out real hardware for testing charge more than a student can afford. Across 37 unique devices, 33 held 30 FPS or better, most sat pinned at the browser’s 60 FPS cap, and the strangest row in the data was a 4K TV running a four-year-old Chrome. The numbers fed straight back into the autoscaler that trades render resolution for frame rate: I lowered its target to 30 FPS and added motion blur so weaker devices still feel smooth. Fleeting Garden³ got the same treatment years later, shedding agents instead of pixels.

Limitations

Objects reach the GPU as uniforms, and uniform counts are capped by the GPU, the driver, and the browser, so a sufficiently complex scene hits a wall. The planned fix was a non-uniform tile grid, finer where the scene is busy.
There are exactly two light types and no way to plug in a custom lighting model.
The banding around lights bothers me to this day. Dithering would fix it; it looked too expensive at the time.

The library is still on npm and gets a hundred-odd downloads a week, which may not be much, but I like to imagine that somebody, somewhere, is actually using it. The demo scenes are still up too. The game half of the thesis deserves its own article, and it will get one.

Quilez’s ray-marched penumbra technique: https://iquilezles.org/articles/rmshadows/↩
demo page: https://sdf2d.schmelczer.dev/↩
Fleeting Garden: https://schmelczer.dev/articles/fleeting-garden-webgpu-drawing/↩

A 50 FPS Game Engine on an 8-Bit Microcontroller

Andras Schmelczer — Sun, 01 Mar 2020 00:00:00 GMT

I grew up playing with little widgets: fake Tamagotchis, Game Boy imitations with 100+ built-in games, and the like. It was only natural that I wanted to make my own.

The game

You keep a broken spaceship alive. Asteroids drift past, you mine them and spend the points on upgrades, each of which unlocks a new station to tend or a new crewmate who does the tending for you.

The hardware

I settled on the ATtiny85¹, driving a common 128×64 1-bit OLED². To keep the footprint small I skipped a built-in controller and used an IR receiver instead, which works with almost any remote; mine was a generic hi-fi remote I got on AliExpress for pennies. Connecting the components was quite simple, even if my breadboard might’ve led you to believe otherwise:

Routing the PCB from this design was also straightforward; the real hard part was the firmware.

Reality check

I had aspired to build a game with an open world, “advanced” AI, and so on, but I quickly got a reality check: even after bitpacking, the framebuffer alone would take up twice the microcontroller’s 512 bytes of RAM. The 8 KB of program memory wasn’t generous enough for grandiose ambitions either. I still made it work though.

Rendering engine

To achieve 50 FPS, rendering happens at quarter resolution (64 by 32 pixels). The OLED’s zoom mode doubles the image vertically on its own, and horizontally each byte is simply sent twice, so the engine doesn’t have to store extra pixels for the upscaling.

The screen’s pixels are either on or off, so 1 bit per pixel should be enough. But compositing is a basic expectation of any rendering engine, and it costs each pixel a second bit: transparency. That’s what lets the black pixels inside the spaceship’s sprite hide the stars behind it, while the black pixels outside it stay transparent and let the stars show through.

We should realise that 2 bits per pixel is wasteful, since the valid states are only black, white, and transparent black: there’s no difference between transparent and opaque white, as both end up as a white pixel regardless of what’s behind.

Keeping the entire framebuffer in memory would be impossible: 64 × 32 × 2 bits is exactly the amount of RAM the microcontroller has, leaving zero bytes for everything else. The pragmatic choice at this point would’ve been to just get a bigger microcontroller. But hobby projects are allowed to be non-pragmatic at times. So I carried on and optimised the renderer to work in a streaming manner, 8 bits at a time, processing 8 pixels simultaneously in a SIMD fashion.

Sprites are stored as 16-bit columns (matching the word-size of the EEPROM): the high byte is an inverted mask, the low byte the fill bits. Compositing eight vertical pixels of a sprite onto the framebuffer is a single expression:

newColumn = oldColumn & transparencyMask | fill;

The sprites are C arrays injected into the source code by a Python script, so the somewhat strange layout doesn’t leak into the art workflow. Lastly, the ATtiny bit-bangs each byte out to the display, as it has no dedicated SPI peripheral.

Game logic

For scripting the game engine, I took inspiration from JavaScript’s prototype system and Unity’s object model. Of course, the size constraints only allowed for a lite version. The final design is a single array of game objects, where each object holds a union of the possible object states and a pointer to its prototype: a special struct, essentially a virtual function table, pointing to the object’s tick and draw functions. Even though simulation and rendering follow the same 50 Hz tick, the two functions are separate because draw has to support rendering an 8-pixel stripe of the object, and thus may get called multiple times per frame. This quasi-vtable approach doesn’t become a performance bottleneck either; the beauty of the ATtiny is that it only deals with SRAM, so there’s no complex caching and there are no line faults so jumping around in memory doesn’t bring a penalty.

In the end, the game does have “AI” too, in the form of a finite state machine (FSM): your astronaut crewmates have a priority list of activities to attempt, based on the player’s current activity.

Saves

The program memory is only 8 KB, so the sprites have to live in the EEPROM. However, there’s still enough space in there to cram in a few dozen bytes for a save file too, which is just the serialised state of the game-object list. To avoid corrupting the saved state on an unexpected shutdown, the EEPROM holds two save buffers, along with a flag telling which one was completed last. The flag only flips once the data has been fully written into the older buffer, which makes saves atomic. It all happens in the background through interrupts, to avoid jitters in the rendering loop.

Was it worth it?

Absolutely. Don’t get me wrong, the gameplay gets old after 15 minutes: you spend the first 5 completing the game, and the rest just watching your crewmates operate the spaceship autonomously as their FSM logic converges.

It was incredibly fun to read the datasheets cover to cover and actually understand the limits, and how to push them. On the one hand, this is as full-stack as it gets, and it allowed me to think about performance on a very different scale than usual. On the other hand, by the end of the project the game and the UART logging code no longer fit into program memory together, so I had to pick which parts of the game to disable.

If I were to redo it, I strongly believe writing a simulator for the console would be the right call: it would allow faster iteration by skipping the flashing step, and it would make it easier to debug the “there’s no output, what now?” type of issue. A simulator would also mean E2E testing in CI. Fortunately, in this case, there’s only so much complexity an 8 KB program can hold, but anything bigger would’ve been prohibitively expensive to develop without a better testing setup.

ATtiny85: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf ↩
128×64 1-bit OLED: https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf ↩

A City Where Bad PLC Code Made Cars Crash

Andras Schmelczer — Sun, 01 Jul 2018 00:00:00 GMT

While I was working at CrySyS, my first university’s cybersecurity research group, I got a fun opportunity: simulating a small city. The lab was preparing a hacking challenge whose targets were PLCs operating traffic lights, so the result of a successful attack was mayhem on the roads.

I quickly got building in Unity¹: C# scripts gave the drivers their AI, the driving model was tuned to look realistic while staying precisely controllable, and a REST API exposed the traffic lights for remote control. The drivers obeyed the lights unconditionally, tunnel vision and all, which is the whole point: wrong control logic ends in disaster on screen.

The art was on me too, so I ended up watching a bunch of Blender Guru² tutorials and modelling everything in a low-poly style. Far too much of that time went into trying to get the animations right; they didn’t turn out the best, but zoomed out they were passable.

The venue was quite large, with screens dotted around it, which added one final complexity: netcode. The whole simulation runs server-side, and each screen is a thin client that merely extrapolates from the latest state it received.

Unity: https://unity.com/↩
Blender Guru: https://www.youtube.com/@blenderguru ↩

A 3D Voxel Game in C

Andras Schmelczer — Fri, 01 Dec 2017 00:00:00 GMT

Update: I haven’t used Windows for a long time now, and I’ve been wanting to revive this game, but couldn’t be bothered to migrate it to SDL2. Now, in 2026, I could finally just one-shot this migration with an AI agent. So my game from 9 years ago is playable again at schmelczer.dev/platform-game¹.

I titled my first proper university project Platform game. I’ve clearly come a long way since then, yet one thing hasn’t changed: I’m still bad at naming things. Back in 2017, I created an actually fun 3D game written in pure C with the help of SDL² 1.2.

I’d been wanting to build it ever since I first downloaded GameMaker³ and realised that I could build a video game. I’d tried already with Avoid⁴, and Platform game is essentially its 3D rewrite.

The maps are randomly generated, but always so that the jumps between platforms stay possible given the user-adjustable gravity and jump-strength settings. And the map is fully destructible, voxel by voxel! This lets you build structures to hide from the flying enemies chasing you, although once the enemies have merged and grown larger, they can destroy the terrain too. After collecting enough power-ups, you can shoot back, and even slow down time in exchange for losing some points: a strategic trade-off.

One feature I distinctly recall is the save file format. Initially, it dumped the entire procedurally generated map into a file, so a single save could reach hundreds of megabytes. I ended up discovering run-length encoding; as I later learnt, I wasn’t the first person to come up with it. It exploits the spatial similarity of the map, mainly air on top and ground at the bottom, and it massively reduced the file sizes. One thing I didn’t end up discovering during this project is how to do computer graphics properly: I settled on a software renderer that’s only capable of drawing cubes, and derived its 3D-to-2D projection using trigonometry and a lot of post-it notes. Doing it properly had to wait a few more years, for a 2D ray tracer⁵.

I’ve made the source code publicly available, though more as a reminder for myself than as something for others to learn from. Even if this project is far from elegant or efficient, it resulted in a genuinely fun game, and it made me fully realise my passion for programming.

https://schmelczer.dev/platform-game ↩
SDL: https://www.libsdl.org/↩
GameMaker: https://gamemaker.io/↩
Avoid: https://schmelczer.dev/articles/avoid-early-web-game/↩
a 2D ray tracer: https://schmelczer.dev/articles/sdf-2d-ray-tracing/↩

Avoid

Andras Schmelczer — Sun, 01 Jan 2017 00:00:00 GMT

My first browser game. You’re a dot; other dots pour in from the edges and chase you. Your only defence is to out-manoeuvre your enemies until they crash into each other. That’s the entire game, and it’s genuinely fun for the first few minutes: a decent return on so little code.

It was also my first time touching the <canvas> element. I didn’t know it then, but that one API started an obsession with graphics programming that hasn’t let go since.

A few months later the game got a second life as the handout for our design society’s web workshop, where we rebuilt it step by step with people who’d never drawn a pixel from code before. It turned out to be exactly the right size for that: small enough to finish in a few hours, alive enough to feel worth finishing. The handout’s one piece of process advice (get it working first, make it pretty after) is still roughly the only process I follow.

Photo Site Generator

Andras Schmelczer — Thu, 01 Dec 2016 00:00:00 GMT

I bought my first proper camera, a Nikon D3200¹, at fifteen with my first summer job’s salary, and I’ve been photographing whatever captures my imagination or sparks aesthetic joy ever since. I wanted a personal way to share the results without going through social media, which was all the excuse I needed to build a photo portfolio site.

It started off with PHP running on a Raspberry Pi in my room. To keep maintenance simple, it has since evolved into a small Vite script generating static HTML and variously sized photos from a folder.

The only rule for good tech is that it has to give me more value than the effort it takes to use it. The part of photography I enjoy is taking photos, so the website itself is just a nice-to-have: publishing has to cost me almost no time. Committing a JPEG into a Git repo and pushing it is the right amount of effort to expect in this case. It’s still one more step than the PHP version asked for, but I have taste in tech too, not just photography.

Nikon D3200: https://en.wikipedia.org/wiki/Nikon_D3200 ↩

A Physics Practice App for the Hungarian Érettségi

Andras Schmelczer — Thu, 01 Sep 2016 00:00:00 GMT

Producing value is the ultimate test of software. Users don’t care about the cool tech or the clever architecture; most often, they don’t even care about half the features. Users have a problem they wish your software could solve for them.

The problem

My problem, and my classmates’, was the Hungarian physics érettségi, a university entrance exam. We were advised to start preparing two years ahead by solving questions from past exams¹. But the questions are randomly sampled from the whole curriculum. That makes it tedious to practise a single topic, and hard to tell whether a question you can’t answer is simply material you haven’t learnt yet.

The evolution of the solution

The solution was to manually extract the questions (and their diagrams) from twenty years of exam PDFs, a perfect way to procrastinate on studying. Then, together with the project’s main stakeholder (my physics teacher), I went through every question and categorised it by topic. Finally, I built a small interface over this database, and the site still runs at fizika.schmelczer.dev²: it makes the questions searchable and generates mock exams drawn only from the topics a student should already have mastered.

It’s one of my earliest projects, built with a rudimentary understanding of full-stack application development, yet for years it was my most popular app by both active users and time spent per user. It has stood the test of time, too: more than nine years on, it’s still moderately popular, and generations of students at my old school (PTE Babits Mihály Gyakorló Gimnázium) have used it to prepare for the same exam.

The app has gone through a few iterations. It started as the most spaghetti PHP one could imagine, coupled with a real (and absolutely unnecessary) MySQL database. But it worked. I got a really good score on the exam and left the site running for future students.

Eventually, hosting a full-blown database became too expensive to justify, so I migrated everything to a static site served through Firebase. Then, year after year, students would write in asking how to add the latest questions, and walking each of them through the GitHub workflow got tiresome. So this year, I vibecoded a small CRUD admin interface that edits a JSON file on disk. The file is under version control, so nothing is lost should an edit go wrong. We’re back to running a backend server, but self-hosting compounds³: I already had an established self-hosting setup, so the marginal cost was negligible. Happy users, happy maintainer.

Conclusion

There are two takeaways here. First, data can be vastly more important than the app wrapping it: Fizika’s wrapper has been replaced twice without changing the core value it provides. Second, there’s building software for the thrill of the engineering challenge, and there’s building it to create value at little cost. This project taught me both.

past exams: https://www.oktatas.hu/kozneveles/erettsegi/feladatsorok ↩
https://fizika.schmelczer.dev/↩
self-hosting compounds: https://schmelczer.dev/articles/frame-eink-photo-display/↩

My First Real Project: LEDs Driven by an FFT

Andras Schmelczer — Tue, 01 Mar 2016 00:00:00 GMT

My first ever project, and the one that paved the way to the ATtiny85 handheld¹ four years later.

Back when I bought my first Raspberry Pi (a Raspberry Pi 1 Model A², to be exact), I had no idea what I was doing. After burning myself both figuratively and literally trying to drive a 12 V RGB LED strip, I understood how to wire up MOSFETs, and then how to control them with PWM. The obvious next step was to make the LED strip do something. I’d seen LEDs react to music before. Then I stumbled upon an article on the FFT³, thoroughly arcane to me at the time, and with that, I had all the building blocks to do it myself.

Without quite meaning to, I’d started with a real full-stack application: I learnt about Ajax and XMLHttpRequest, got fascinated by CSS, and saw that programming is like magic in real life. I wish more kids got a similar first impression of programming, one that sparks their curiosity for building.

ATtiny85 handheld: https://schmelczer.dev/articles/ad-astra-attiny85-game-engine/↩
Raspberry Pi 1 Model A: https://en.wikipedia.org/wiki/Raspberry_Pi ↩
an article on the FFT: https://betterexplained.com/articles/an-interactive-guide-to-the-fourier-transform/↩