DoozleB
Systems developer
I build systems software — emulators, engines, simulation — in C++.
The layer underneath the apps, where you own the memory, the timing and the correctness. I measure it against public test suites that were not written to be kind, and publish what breaks.
Currently
FourShades
A Game Boy emulator written in C++20, spec-first and test-first, measured against the public Game Boy test ROMs. It finished at 155 of 165 — and the ten still failing are published with their evidence, several of them failing on purpose, because passing would have meant contradicting a hardware-verified test.
Latest Posts
Done is where the evidence runs out
FourShades finished at 155 of 165 test ROMs. The ten that are left cannot be fixed without evidence that does not exist, and saying so is the interesting part.
The screen works. The scoreboard barely moved.
The emulator can draw now, and you can play it. Fixing one systematic error corrected 44,000 wrong pixels and flipped exactly one test.
Two ways a scoreboard can lie
The emulator went from 0 to 85 passing test ROMs. The interesting part is the two ways it nearly claimed more than it had earned.
499 out of 500, on purpose
The CPU passes every SingleStepTests instruction but one. The one it fails, it fails deliberately.
About
I write low-level code — the layer underneath the apps, where you own the memory, the timing and the correctness. Then I measure it against something that cannot be argued with.
This layer is unforgiving in a specific way: a defect is not a wrong pixel, it is a wrong cycle, and nothing about the code looking correct will tell you. Only a test written against real hardware will.
Most projects like this publish a demo and a screenshot. This one publishes the pass rate — including the parts where it goes badly.
Projects
A 2D sandbox engine written from scratch, with a simulation core that runs headless.
How I Work
Spec first
Every feature starts as a written spec, then a plan broken into tasks small enough to review one at a time. The implementation answers to that document, not to a vague idea of it.
Tests are the contract
Write the failing test, watch it fail for the right reason, implement, watch it pass. Code that looks right and does not work is the normal case down here. Reading it will not tell you which it is.
In public, failures included
Every claim ships with its artefact — the spec, the diff, the commit, the test output. If a number goes down, it gets published going down.