We are 1.23× faster than mGBA and 1.92× faster than SameBoy, each against the engine of its own granularity. PyBoy does not belong in that table — it has a switch for its sound chip and we have no chip to switch — so it gets its own pairing, APU-free on both sides: PyBoy 0.0156 against our 0.0297, which is 1.90× ahead of us.

mGBA with its renderer off reads 0.0555, and that row is not in the table because it is a different machine from the one SameBoy and our identical are running.

The ordering is the accuracy ordering, upside down

The GB Emulator Shootout publishes 24 DMG rows from the Mealybug Tearoom suite, which is the test set that separates the two or three most exact PPUs in the world from everyone else. SameBoy takes 15 of them. bgb takes 2. PyBoy takes 0. Eleven are pixel-exact here on the per-dot engine, against the same DMG references; on the whole 79-row suite that engine takes 29 where our fast engine takes 3.

So the slowest emulator measured above is the most exact one in the field, and the fastest is the one that scores nothing on the suite that matters most. PyBoy is the fastest Game Boy emulator on this machine, and what it buys that with is not being cycle-accurate.

The cleanest reading of the trade is not between projects at all. It is between our own two picture engines, where the binary, the cartridge, the core and the frame count are the same and only the PPU changes: 0.0666 against 0.2126, a factor of 3.2, and 3 Mealybug rows against 29. Twenty rows of the Shootout's 264-row manifest sit in that gap too — 223 on the fast engine against 243 on the exact one, which is 5th of 19 on the board as it stood in June, behind SameBoy's 253 and ahead of mGBA's 150.

Nothing about the cost of exactness needed a second project to demonstrate. What the second project settled is that there is no faster native emulator here to catch, which is what everyone had assumed there was. There is a design to catch, and its price is already on the books.

RosettaBoy is measuring something else, and the something else is real

RosettaBoy is one emulator design implemented in twenty language-and-build combinations, and its table is the cleanest measurement of language overhead anyone has for this workload. Its own run, --headless --silent on an M1 MacBook Pro:

Read across a row and you learn something true and useful: the same program, written the same way, costs a hundred times more in CPython than in Rust, and a little over three times more in Go than in Nim. That is the question RosettaBoy asks and it answers it well.

Read a single cell as a ceiling and you learn nothing. Its Rust row is 1,603 fps; the same configuration here — headless, silent — is 33,700, and the M1 it ran on is not twenty-one times slower than this box. Its Python row is 16 fps and PyBoy on this box is 64,100, four thousand times apart; its Cython row of 361 is RosettaBoy's own Cython port and not PyBoy's core either. Neither difference is language. RosettaBoy's author says plainly that readability, consistency and idiomatic style come before hardware accuracy, and that the implementations are not in sync with one another; a shared simple design is the whole point of the exercise and it is not what any shipping emulator is. The valid comparison in that table is between its own rows.

GameRoy priced the accuracy tax, and the price is not the JIT

GameRoy is a high-accuracy Game Boy emulator in Rust that grew a JIT, and its author wrote the result up honestly enough to be worth more than the code. The compiled code is around 4× the raw speed of his own interpreter and takes 30–40% off the execution time of a real game — real, and short of what a JIT usually promises. What eats it is exactly the constraint we live under: a cycle-accurate emulator has to update its peripherals before every memory access, so a compiled block cannot simply run. His answer is to predict whether an interrupt lands inside the block and fall back to the interpreter when it does, which keeps the accuracy and keeps an interpreter in the build forever.

The line worth quoting is the one about somebody else: BGB is more than twice as fast as GameRoy, and he attributes the difference to frameskip rather than to code generation. A throughput figure that includes frameskip and one that does not are two different measurements wearing the same unit.

mGBA wrote the technique down in 2017

endrift's Emulation Accuracy, Speed, and Optimization is the clearest statement of why cycle accuracy is expensive, and it is not about arithmetic: hardware does every step of a cycle at once, software cannot, so it swaps between them, and the swapping is the cost. mGBA's Game Boy core divides instruction emulation into per-clock-cycle tasks and emulates the other hardware between them — then batches those operations instead of running them one at a time, splitting a batch whenever two things genuinely interact.

That is our own idle batch, arrived at independently and from the other end, and the same idea has now paid twice here. The halted CPU's batch used to stop at every PPU mode boundary, three or four a scanline, when what a halted CPU can observe of the PPU is two bits of IF and nothing else. Asking whether a STAT interrupt could actually be taken at that edge took the batch from 38 M-cycles to 505. The identical argument, applied inside the per-dot engine, is worth 29.3% of a default-mode frame on its own — and a cartridge that arms a STAT source keeps the old behaviour exactly, which is why no accuracy row moved. The right number of peripheral steps to take is the number a program can tell you took, and both projects got there by asking what the program can see.

What is left of the gap, with a number rather than an argument

Profiled at the 0.0382 accurate frame this round started from, bus_tick was 28.7% of it and the MMU's per-cycle entry point another 16.1%. That 44.8% is precisely the per-access peripheral work PyBoy does not do, and taking it off lands where you would expect: 0.0211, PyBoy's neighbourhood once its own horizon bookkeeping is allowed for. Closing it in the default mode means giving up what Blargg's mem_timing and fourteen Mooneye instruction-timing ROMs measure.

In speed mode the shape changes and what is left is the interpreter: roughly 55 host cycles an emulated instruction against PyBoy's 33. A build with every accuracy liberty in the ledger applied at once — OAM DMA bus conflicts, the work-RAM address override, the OAM-page hook, the link cable, the per-access APU and PPU hooks, the interrupt folds — measures 3.1% better and is still 1.60× behind. Beating 0.0156 from there is a different execution model, not another pass.

Which is a better place to stand than the one we were standing in a week ago, where the target was a number somebody measured on their laptop. The full record, every negative result included, is on the throughput page, and the accuracy those milliseconds buy is on the TerminalGB project page.

Nine decisions

He crosses from the Viridian Forest south gate into the forest on decision 4094 and lands on tile (17,47). The emulator's own map data lists that tile as one of four exits back to the gate he just came through — it is the doorway.

He never leaves it. Two decisions later a text box opens: Hey, wait up! What's the hurry? Four decisions after that the screen goes to the battle wipe, and on decision 4103 he is in a fight. Between crossing the boundary and the fight he pressed up, a, up, b, up, b, up, a, a, and his coordinates did not change once.

It is a trainer, and the cartridge says so

measured Read at decision 4110: wIsInBattle ($D057) is 2, which the atlas names as a trainer battle and not a wild one. wCurOpponent ($D059) is 202 — at or above 200 it is a trainer class plus that offset, so class 2, a Bug Catcher. wTrainerClass ($D031) is 2 and agrees. The opponent is a WEEDLE at level 9.

There is nowhere for a Bug Catcher to be standing. The doorway tile is an exit; the fight started with the player one tile inside a map he had entered nine decisions earlier, and forty-five tiles — sixteen columns and twenty-nine rows — from where he last fainted.

The same tile, one visit earlier

This was his third visit to Viridian Forest. On the second he crossed the same boundary and stood on the same tile (17,47) for two decisions and walked on. Nothing happened. His first battle of that visit came ninety-eight decisions later, at (6,12), and it was wild.

Between the second visit and the third, one thing happened to him.

measured $D618 is wViridianForestCurScript — how far through Viridian Forest's own map script the game is. It is 0 on both earlier visits, goes to 1 two decisions into the blackout, stays 1 through the warp, the Pokémon Center, Route 2 and the gate, and is still 1 when he steps back onto the doorway tile. The battle takes it to 4.

What survived the blackout

Comparing the same eight bytes at four moments answers which of them carries the fight across.

measured Every one of those bytes is 0, or holds an unrelated value, on the last decision of the wild battle. They are set on the next one — the decision the cartridge writes $FF into wIsInBattle, which the atlas names as the player blacked out and which is not a battle. wEngagedTrainerClass reads 202 and wEngagedTrainerSet reads 3 — a Bug Catcher, roster three — and the fight that started at the door was a Bug Catcher leading a level 9 WEEDLE.

$CD60 bit 0 — the flag that says a trainer has spotted the player — is cleared by the time he is awake in Viridian City. So is the engaged-trainer pair, by the time he reaches the gate. What is not cleared is the map's own script index, and the sprite slot and header pointer that tell that script which trainer it is about to run. Viridian Forest's script is left at step 1, which is a trainer is waiting to fight you, and the map runs it the moment the map is loaded again.

inferred Sprite slot 4's stored map coordinates read 22 and 6, and under Gen 1's four-tile bias on sprite coordinates that is tile (2,18) — one step east of (1,18), where he fainted. That is consistent with a Bug Catcher standing directly beside him at the moment the wild encounter started, and it is an inference from the sprite table, not a reading of the trainer's tile.

This one has a name, and it is not ours

The community found and documented this long before we walked into it. It is the trainer escape glitch, also called trainer-Fly, and the variant we hit is the death-warp one: faint to a wild encounter inside a trainer's field of vision, and, in the Glitch City Wiki's words, "the trainer will notice the player on that frame, advancing the meta-map script ID just before the player warps away." Returning to the map gives an instant encounter. The same wiki page names $CD60 bit 0 as the byte set when a trainer spots the player, which is the byte our own read agrees with.

Its wider significance is theirs too. Escaping a trainer battle rather than blacking out is what makes the glitch dangerous: it leaves an encounter staged from stale battle memory, and that is the foundation of the Mew glitch and a component of the arbitrary-code-execution routes speedrunners use in Red and Blue.

What we hit is the tame end of it. Our student blacked out rather than escaping, so the cartridge staged a real Bug Catcher with a real WEEDLE rather than a corrupted one, and nothing about the run afterwards is corrupt. The interesting part is not the mechanism. It is that an agent nobody told about any of this walked into it on its own, and that we can put a rate on it.

How often it happens to us

Every trainer battle a run starts in Viridian Forest is logged with the tile the player was standing on. Across every recorded episode we hold, those tiles cluster hard.

One row is a tile you cannot fight anybody on. Following it out:

measured Thirty-two recorded runs across five separate run roots start a trainer battle on a Viridian Forest exit tile. Every one of the thirty-two is seed 4200126. None of the thirty-two finished the chain.

That seed has been re-run under six different goal configurations in one day, scoring between 91 and 96 whole chains out of 100 between them, and it failed in all six. Only one other seed in the hundred does that. Changing what the student believes about battle screens, about items, about catching, does not touch this one, because none of it is about the student.

What it cost him

He won the forced battle on decision 4251. Three decisions later, on the same tile, BUG CATCHER wants to fight! again, and the same level 9 WEEDLE. That fight ran to 4377.

Then the run stops being a run.

The exit he needs is on row 0. On his first two visits he reached row 3, twice, having walked over a hundred distinct tiles each time. On the third he walked twenty-eight, never got above row 35, entered no battle at all after the two at the door, pressed down 2,358 times, and ran out of budget at (16,38) with the gate goal still latched: the goal that walks him back towards the door he came in through.

What we cannot say from this recording

• When the sight line actually fired. Every trainer byte is clear on decision 3708, the decision that prints BLUE blacked out!, and set on 3709. One decision is thirty-two emulator frames, so this recording cannot separate the trainer noticed him as the wild battle began and the write happened later from the trainer noticed him as the battle ended. The community describes the first; we measured the write, not the notice.
• Which trainer the second battle was. No state was saved inside it. It was a Bug Catcher with a level 9 WEEDLE, from the screen, and that is as far as our recording goes.
• How many other runs black out inside Viridian Forest. Answering that needs per-decision traces for episodes we only hold summaries of. The doorway signature above is what the recorded data can carry on its own, and it is a lower bound: a run that hit the same fault and then died before the goal fired would not appear in it.
• wTrainerNo ($D05D) proves nothing here. It reads 3 from the first probe to the last and never changes, so its agreeing with roster three is a coincidence, not evidence. The identity comes from wEngagedTrainerSet, which changed.

What it changes

For the student: nothing to fix. He walked a legal route, took a legal encounter, lost it, and was warped away by the game's own rules. Everything after that was the cartridge running a script it should have reset. There is no observation he could have made and no button he could have pressed that would have avoided the second battle, because the fight was already staged before the map was drawn.

For us it changes how one number should be read. Every recorded run of seed 4200126 that reaches the doorway battle fails, thirty-two out of thirty-two, and each one has been counted as one more run that got confused in the forest. It is not that. It is one run that met a documented fault in Pokémon Blue, and none of the six configurations tried on it so far makes any difference, because none of them is about the cartridge. A 96-out-of-100 with this seed inside it is really a 96 out of 99 plus one cartridge bug, and the honest way to report a sweep is to say which of its failures are the agent's.

It also raises the price of a blackout. The healing chamber added last week treats a faint as a cost in decisions — you lose the walk back. It is not only that. Faint on the wrong tile and the map keeps a fight for you, and it will be waiting at the door.

Nothing was retrained

Worth stating plainly, because everything after it depends on it.

The collapse compiles the base network, every recogniser and adapter the running config needs, and the control flow itself — the sticky chain's latch and successor walk, a transient goal's scope and eligibility, a chamber's arm and disarm, a battle hold's patience counter — into one graph. src/agentgb/artifact_driver.py is the only place either runner touches it: build the observation, hand it over with the previous decision's state, take back the action and the next state. No latch logic left in the runners at all.

The weights file is untouched. Same sha256 before and after. It is a compile of what already existed, not a rebuild of it, and the guard that proves it picks the same buttons runs a thousand paired decisions of synthetic noise across five seeds — three greedy, two sampled with the production confidence gate and decay — with zero disagreements, latch state and held stage included.

So: two paths, provably identical on every decision anyone had checked, one of them winning eight runs and the other winning none.

New does not mean guilty

The runs were all dying in the same place, so the frame they were dying on was the thing to look at.

battle-on-screen-recognizer — the shared network that answers "is a battle still happening" — reads 0.608 on an ordinary shop purchase-confirmation box. Not a near-tie against its threshold. A confident, wrong yes, on a screen with no battle anywhere in it. The dialogue box in a shop confirmation is a black-bordered text box, and so is the one in a fight.

That reading was taken by calling the real, native network directly on the real frame, with no ONNX runtime involved in the measurement at all. The compiled graph is not in the picture. The fault is in the shared control flow both paths run, and it was in there before the collapse was written.

Two thresholds on one network, and the loose one is the one that gets fooled

The battle wheel asks that recogniser two different questions with two different bars.

To enter a hold, the entry gate wants 0.999. To release one, the end condition checks the same network against 0.5, holding while it stays above, with a release patience of 24 decisions. Both battle-hold-trainer and battle-hold-wild share that gate.

A phantom battle at 0.608 can never start a hold. It clears 0.5 comfortably, and 0.999 not at all. What it can do is keep a dead one alive.

A real rival fight around decision 201 leaves the trainer hold latched with its miss counter climbing normally — 606, 608, and onward to 630 by decision 1092, far past a patience of 24. It never expires, because every time the run walks back into a shop and reads a confirmation box, the same shared gate says 0.608, the counter resets to zero, and the stale hold re-arms. The trainer battle's adapter — not the walking adapter the chain has long since moved on to — keeps pressing through the shop's confirmation screens, buying one item at a time until the wallet is empty and the chain stalls.

Every part of that is reachable by the old path too. It is one recogniser, one threshold and one counter, all of them shipped and certified long before this task started.

A difference too small to fail a check, and large enough to change the route

The graph is verified against a numpy reference that re-implements the same control flow, and the check it has to pass is a maximum absolute difference in the logits below 1e-3. It passes. onnxruntime and native numpy do not compute a convolution to the last bit, and sub-0.001 is a reasonable place to draw the line.

It is also enough to flip a near-tied argmax, which was confirmed directly at decision 546 of a real run: up against right, the pick depending on which backend did the arithmetic, with no goal latched on either driver. No control-flow machinery active. Just the base network, two backends, and a tie broken two different ways.

From there the trajectories are simply different runs. The artefact's route revisits the shop while that stale hold has not yet expired far more often than the flexible driver's route does, on these ten seeds. Same map, different walk. Sharing the RNG stream between the two drivers was tried and removes one source of divergence; the identical N=10 comparison with it enabled still returns 0/10, because the argmax flip is not an RNG question.

A faithful copy is a measuring instrument

The useful thing here is not the bug. It is what the pair of paths turned out to be good for.

Two implementations that provably agree on every decision in isolation diverged completely in practice, and the divergence carried information. The synthetic checks could not have found this, and it is clear why once you look at them: random noise never triggers a real battle, and the graph's own verification forces a handful of degenerate frames, never a multi-thousand-decision sequence with a real fight followed by a real shop visit. Neither check is weak. They answer a different question from "safe to drive a long chain run with".

The 8-out-of-10 was the misleading number. Eighty per cent looks like a spread of ordinary bad luck, and it was concealing a specific trap that the winning route happened to miss most of the time. It took a harmless numerical nudge — small enough to pass every tolerance the project sets — to make the trap show up ten times out of ten. A rate that good can hide a fault this sharp, and the way it stopped hiding was a second implementation walking a slightly different line through the same map.

--use-artifact is an explicit flag rather than the default because of that measurement. The first design routed to the artefact automatically whenever the goal set and the policy matched what it was compiled for. A plain run today is byte-for-byte what it was before any of this.

What is still open

The fix is not written. There are two candidates and they are not the same fix.

The first is that the recogniser never learned what a shop confirmation box looks like — it was trained to tell battle screens from the rest of the game, and a black-bordered dialogue in a shop is a negative it apparently never saw enough of. That is answered with frames and a retrain.

The second is that the hold is wrong to re-arm off a single frame at all, whatever the recogniser says. A patience counter that resets to zero on one reading above a loose threshold has no memory of having climbed to 630, and a mechanism that can be revived by one frame of noise is fragile even when the network under it is right.

A crew is deciding between them on evidence now. Until it lands, the collapsed path stays behind its flag and out of the promotion workflow, because promoting it would mean shipping a route that walks into this reliably.

Five rounds, and the one that made it worse

agentgb trainscene refuses by default. It sweeps both bars at every threshold — the pooled false-alarm rate over real play, and how many genuine occurrences are still caught, counted as episodes rather than frames — and if no threshold satisfies both it ships nothing and prints the areas it is confused by. Five rounds of that:

Every reported round caught 1,500 of 1,500 genuine occurrences. Round 4 is the one to look at: thirteen more areas of corrections, seven times as many rows each, and it came out worse than round 2.

So the residual got dumped as a montage and looked at. Ninety-two per cent of it was one screen — the nickname naming grid, map 40 at tile (5,3). A grid of dark glyphs on a light field, which at 40×36 is a town. Four rounds of arithmetic had not said that, and no aggregate was ever going to.

The Viridian fix was the same move. Positives narrowed from every frame on map 1 to map=1,mode=0 — the town outdoors, with a menu drawn over it no longer counting as the town. 94,409 frames over 527 tiles.

That took it to 12 false alarms in 1,383,924 frames, 1,500 of 1,500 occurrences still caught, weakest genuine fire at p=1.000000. Eleven of the twelve are on one link and the twelfth is inside the Viridian Mart. Threshold 0.999 rather than the command's recommended 0.99, which is a deliberate departure: the take-the-lowest rule exists because the Game Boy draws text letter by letter and a tight trigger goes blind on a half-drawn line, and a town is not drawn progressively. Twelve frames against 251, identical recall.

The tool poisoned its own round

Round 3 is missing from the table because it was killed rather than reported.

When trainscene refuses, it names the areas that fired and prints a ready --negatives flag listing them. Pasting that flag back in is the obvious next move, and here it was the wrong one: --negatives takes whole episodes, with no selector. Three of the links it named are Viridian City almost end to end — into-the-viridian-mart is 99.0% map 1, north-out-of-viridian 98.8%, into-the-pokemon-center 98.7%.

So the scene being recognised went into the no pile. About 18% of that round's negatives were the thing itself. Held-out balanced accuracy fell 1.000 → 0.927 and stalled, and the round was abandoned.

The probe was not wrong to name those links — it scores them only on their out-of-scope frames, correctly. The advice it prints from that is what does not survive contact with a link whose corpus is mostly the scene. Check a patch link's own map distribution before pasting.

Zero false alarms, then 41 in a town

The forest-entry trigger, built the day before, had the cleanest numbers on the project: 150 of 150 real crossings caught at 0.999, and zero false alarms pooled over 495,902 frames across 23 corpora — including a shard of cross-map door fades collected on purpose, because a link's corpus stops at its map change and the next one starts after it, so the states a run passes through in between exist in no ordinary corpus at all.

Then a 30-run cold-boot arm came back with forest-walk-npcbox firing 41 times on map 1, Viridian City. It was the last goal driving in 16 of the 18 failures, and 15 of the 18 ended inside the Viridian Mart at the full 8,660-decision budget, pressing left.

That reads exactly like a false positive, and the structural argument above says a probe cannot rule one out. Two crews landed on that goal independently on the same day.

It was innocent

The way to check is to stop probing corpora and score the recogniser on every decision of real play instead. harvest_goal_false_positives.py replays a sweep's recorded attempts through the same functions a measured run uses, wraps the driver, and writes out the stacks a named goal's recogniser actually fires on outside its own maps. Eighteen replayed failing attempts, 155,880 decisions:

On the one traced seed, the two Viridian decisions it was recorded as "firing" on read 7.7e-17 and 8.9e-08. All 30 episodes' first fire is on map 51, and no episode fires outside the forest before entering it.

The recogniser never fired in the town at all. A fired event in the run record cannot tell a threshold being cleared from a persisted hold resuming, and that one ambiguity is what made a mechanical bug look like a perception one. A retrain would have changed nothing.

One real risk did fall out of the harvest, and it is worth naming. The only readings above 0.5 anywhere outside the forest are fifteen, all in Oak's Lab, peaking at 0.9576. Dumped and looked at, they are the same shape as the entry positives: a solid black transition frame in the oldest channel of the stack, beside a light textured region and a text box. Which is what that positive class is made of — 150 near-identical frames of one tile, (17,46), with the camera clamped at the forest's southern edge so the lower half of every one is black. It is safe today because the threshold is 0.999 and not 0.95. That is a thinner margin than anybody knew they had.

The fault was mechanical

end_condition.persist_through_other_goals exists because a hold that spans a long stretch of play loses the wheel the moment anything else wins a single decision; without it the forest crossing scored 0/30. As first written it made a hold survive the decisions it does not drive, and left its ending observable only on the ones it does.

Lose a Bug Catcher fight inside Viridian Forest. The cartridge blacks the party out to Viridian City while the battle hold is driving. The forest hold is asked nothing, the battle hold releases at map 1, the forest hold resumes — and the forest's own walking adapter drives the run around a town it has never seen for the rest of its budget. The event immediately before every single non-forest fire is a battle hold releasing at map 1 or 0: fourteen trainer battles, one wild.

The version this trigger replaced was gated on wCurMap and was immune by construction. It re-asked memory every decision, so a teleport stopped it on the next one. Moving to the screen removed the memory read and quietly removed that property with it. When a mechanism replaces a memory read, check which properties the memory read was silently providing.

The replacement needs no weights. release_on_text sweeps a list of phrases at the top of every decision, before selection, for every persisted hold. A list rather than one phrase, because a decision samples one frame in 32 and the game draws a line letter by letter: BLUE is out of / useable POKéMON! is up for two sampled decisions, BLU for one mid-draw, and BLUE blacked / out! fully drawn for about one. Two phrases give roughly four decisions of cover instead of one.

Paired on the identical 30 seed pairs, cold boot, seed 42:

Thirteen gained, none lost, McNemar exact p = 0.00024. Milestones 1 to 24 are 30/30 in both arms, and the change is provably inert where no blackout happens: all 12 runs that already finished reproduce their exact decision count, 12 of 12, median 2,165.5 either way. Fires on map 1 went 41 → 0; all 270 fires are on map 51; the first fire is on map 51 in 30 runs of 30. The trigger everybody suspected was never touched.

Of the five that still fail, four are stuck in a forest battle — no PP left, no running from a trainer battle — which is a known gap in fighting competence and not this bug. The fifth released correctly at the blackout and then wandered into the Mart under a different latched lesson.

What the day cost

The give-back that started all of this measured a null, and it is recorded as one. Seven recorded knockout seeds: 2/7 through the forest with no clear, 2/7 clearing, 2/7 clearing and handing back — the same two seeds every time. Thirty cold boots, paired: 12/30 both arms, zero gained, zero lost, every one of the 25 milestones identical.

The mechanism itself is clean. Fifteen of the 30 runs got the lesson handed back, every restore on map 1 and on that stage alone, zero false hand-backs, zero runs ending still-held. It fires correctly, costs nothing, and rescues nothing at this sample size, because the thing ending the runs was three maps away in a branch of code with no weights in it.

Five training rounds bought a recogniser that works and does not currently matter. Finding that out is what made the next fix a one-line declaration.

The sequence

This is now the written procedure rather than something the crew happens to do.

1. Dump the positives and look at the montage before training. Not a description of them — the actual four-frame stacks, in a picture, in front of a person. It has now caught a poisoned pile three times where every number said clean.

2. Small cheap tests first. A tile distribution, a map histogram, one probe over one link. An hour of training is a bad way to discover a bad idea.

3. Let the tool refuse. A trigger that fires where it should not is not a trigger. The default false-alarm bar is 0.0 because a trigger behind a hold strands the whole run on one false positive — relax it deliberately, on evidence, and say so. This one was relaxed to 0.0005, on the argument that the exposure is bounded by where the code can ever ask.

4. Narrow what it learns from before piling on corrections. Rounds 2 and 4 added 28 links of negatives between them and left 5,257 false alarms. Adding mode=0 to the positive selector left 12. Every correction teaches the network another place it is not; a narrower positive teaches it what it is.

5. Two aimed rounds, then stop and report the trade-off. Round 4 was the third and it went backwards. The stopping condition is not "it passed", it is "the next round has a reason".

6. Measure in a real run, paired, and report what was gained and what was lost. Both numbers. 13 gained and 0 lost is a result; 8 gained and 4 lost, which is what an earlier change on this same chain produced, is not.

And a seventh that only exists because of today: check who is driving before blaming what recognised. Forty-one fires in a town, sixteen of eighteen failures ending under that goal, and the recogniser's own peak reading there was 0.0408.

What a recogniser is

A recogniser is the smallest thing this project trains. Two classes, one question — is this the screen? — over the same observation the student gets, or a crop of it. You give it a pile of frames that are the scene, a pile that are not, and hold some back to score it on.

Size follows the crop, and the crop matters more than anything else here. A full-frame recogniser is 118,290 parameters. Cropped to the band under the opponent's name it is 28,178; to the lead's HP bar, 24,082; to the top half of a text box, 6,954.

None of them touch the student. models/pixel-student.npz is 122,330 parameters and was not retrained once during any of this — same file, sha256 b2bb79082c88c486…, before and after.

Held-out accuracy lies

The first forest attempt was a single classifier for is this Viridian Forest. It scored 1.0000 balanced accuracy on frames it had never seen, and then fired on 37% of 1,705,090 real play frames. Raising the bar did not save it: 15.5% still fired at 0.999.

This is structural, not bad luck. A closed two-class network puts everything it has never seen into whichever class is broader, and the held-out split is drawn from the frames it was shown — so it cannot contain the failure by construction. For a question like "which place is this", the broader class is the positive one, and the recogniser converges on yes.

The fix is not a better classifier. It is a different question. A place is a scene, and a scene has no edges. A doorway is an event, and an event has a beginning. Recognise the event.

The probe lies too

So you probe: run the trained recogniser over every corpus on disk and count how often it fires where it should be silent. The forest-entry trigger came back with zero false alarms across 1,705,090 frames of 19 links.

It then fired inside the player's own house, at p >= 0.999, in 19 of 20 live cold-boot runs. Because that goal holds until an exit trigger clears it, one such fire strands the run for good: a paired N=20 read 0/20 against 11/20 for the version it was replacing.

Both numbers were correct. A link's corpus stops at its map change, because that is when its goal fires, and the next link's corpus starts after it. The cross-map stack — three frames of the old room, one of the new — is exactly what a door produces and exactly what this recogniser was trained on, and it exists in no ordinary corpus at all.

A check cannot find a fault in a place it was never shown. Anything whose subject is a transition has been measured against data that structurally cannot contain its worst confusion. The repair was a shard of 4,825 cross-map door fades from six other doors in the opening chain, collected on purpose and used as a probe target.

The stack drags the last room in with it

Look at the right-hand frames. They are indoors.

The observation is four frames, so "the first frame of the forest" physically carries three frames of the room before it. Measured on the crossing shard: of 600 rows labelled map 51, the oldest channel is the gatehouse in 450, and only 150 are forest in all four. Three quarters of what the first recogniser was taught to call forest entry was mostly indoor-building pixels — which is precisely why it fired in a house.

The fix is to keep only frames whose four channels are all the target map. Three steps into the forest is the first decision with no gatehouse anywhere in the stack, and across 150 runs it produces just four distinct pictures. That is a fixed shot, not a spread, which is what makes it worth recognising.

The exit is the same trick pointed the other way — the north door, on the way out.

Its threshold is 0.99, not the 0.999 the entry uses, and the difference was measured rather than chosen. At 0.999 the exit misses 37 of 152 real exits. A trigger tuned only for silence goes blind; this project has already lost 11 of 27 runs to one that only ever saw a fully drawn line of text.

A screen-only trigger, taught by a memory read

This is the one worth the whole page.

The battle gate was trained on every frame where the cartridge byte wIsInBattle said a battle was happening — --positive-select "battle=1". It reads nothing but pixels when it plays. Its positives were chosen by reading memory.

The byte and the screen do not agree. On a wild encounter the byte flips a decision before the screen changes; on a trainer battle it flips about six decisions after the entry wipe has started. So the pile contains frames that are not battle screens.

Chosen by the byte · poisoned

Chosen by the phase · honest

Across the whole pile: 1,572 of 3,632 selected rows are the entry wipe, and 1,130 of them — 31.1% — contain at least one entirely black frame. The gate was being taught that a battle is on screen includes the screen is black, which is also every door fade in the game.

The numbers never showed it. Held-out balanced accuracy 1.0000, every one of 227 genuine battles caught at every threshold, and a stubborn floor of a handful of false alarms per half-million frames that four rounds of patching, a wider patch budget and more epochs all failed to move: 8, then 2, then 5, on different links each time. Not a threshold problem, not a capacity problem. The label.

The repair was a new per-frame field recorded at collection time, marking the first run of decisions after a battle begins on which the game has something to say — <NAME> wants to fight! for a trainer, Wild <SPECIES> appeared! for an encounter. One rule, symmetric, nothing to edit as the game world grows.

Honest labels: 2,060 rows, zero containing a black frame. That took the gate from refused after four rounds of patching to passing with no patched negatives at all — 0 false alarms in 549,918 frames at 0.999, all 227 battles still caught.

There is a cost. The gate is now shut during the entry wipe, so the battle pair does not take the wheel for those few decisions. That is the right answer: nothing on screen says battle yet, and a gate that opened on a black screen would open on every door in Kanto.

This generalises. Every screen recogniser in this project selects its positives on a cartridge label. Where the label and the picture agree frame for frame that is free. Where they can disagree — a transition, a fade, a warp, a battle start — the bug is waiting, and nothing on the training side can see it, because the network learns the wrong label perfectly.

Crop to the thing itself

Telling a trainer battle from a wild one by sight comes down to one band of the screen. A trainer's party is drawn as a row of Poké Balls under their name while the challenge line is up. A wild encounter never draws one.

Two decisions later the row is gone and the same band carries the enemy HP bar, which reads identically in both kinds of fight. The signal exists only at the start: 346 of 346 recorded trainer battles show it, for a median of 2 decisions, range 2 to 2.

Cropped to that band, the recogniser fires on 0 of 1,019,244 probed frames at 0.95 while catching all 346 — and the probe deliberately includes three wild-battle corpora, where a fire would be a real mistake rather than an unseen scene.

The same argument, put more sharply, produced the heal trigger. The design note is worth quoting:

That crop is 24,082 parameters and cannot see the name or the level, by construction rather than by hoping.

It also cannot be trusted on its own. Ungated, it reads 33% of 1,898,768 real play frames as low HP — every one an overworld frame whose bar region is a patch of grass. The HP bar is only drawn during a battle, so the bar reading is only ever taken inside the battle gate above. Gated, twelve of twenty-four probe links contribute no frames at all, because none of them contains a battle.

Gated and measured against frames whose recorded HP already settles the answer: 42 false alarms in 71,482 frames across 24 links, 0.059%, with 1,035 of 1,035 genuine occurrences caught.

One thing that measured worse is worth the space, because it points the other way. Looking at the pile showed 84.1% of its 67,935 positives were gate-shut — the intro wipe, the stats sub-screen, the move list, none of them drawing a bar at all. Cutting them is obviously the right thing to do. Paired at the same seed and epochs, it takes held-out accuracy up, 0.9946 to 0.9997, and the false-alarm rate on the frames the trigger will really be asked about the wrong way, 0.48% to 1.73%. Held-out accuracy lied about the fix for held-out accuracy lying.

A trigger that holds must latch

The battle pair does not just fire; it holds the wheel until the fight ends. The first wiring asked the entry recogniser again every decision.

That cost the chain 9/30 down to 2/30. The rival fight fell to 19/30 and eleven runs of thirty ran out their budget standing in Oak's lab.

The reason, measured over real fights: the gate reads under its own entry bar on a large minority of a battle's frames — the attack flash, the move menu, the damage animation. Over 20,000 sampled battle frames it clears 0.999 on 31.4% of them in the rival fight and 41.6% on Route 1. Swept all the way down to 0.005, only 79–95% clear the bar; there is a hard core it reads as near-zero at any threshold. Its longest run of readings below 0.5 while the battle is genuinely still on is a median of 5 to 9 and a maximum of 16 consecutive decisions, which no single-frame bar can tell apart from a real ending.

So the marker fires once, latches, holds, and is released by a separate condition. Three changes, no retraining and no new weights: a latched group keeps the wheel whatever the gate currently reads; the release has to disagree 24 decisions running, half again beyond the worst observed 16; and entry and release are different numbers, 0.999 and 0.5. Using one number for both is what caused it.

The rival fight went back to 30/30 and stuck_in_battle from 26 to 1.

The entry recogniser only has to be good at the entry frame. It already was.

What actually worked

Crop tight. Every trigger cropped to a band — the text box, the ball row, the HP bar — passed on the first or second attempt. The two aimed at whole screens fought back for a night each.

Prefer the game's own words. Where the cartridge announces something out loud, match the text and train nothing. The heal cycle disarms on Nurse Joy saying fightin — a seven-character prefix, chosen so it catches the line while it is still being drawn, and chosen over Thank you! because the shop clerk says that too.

Train simple, probe broad, patch narrow. Start with the scene's own non-scene frames as the negative class and nothing else. Probe everywhere. Add only the areas measured to be confused. The alternative is mapping the entire game as no.

Refuse. If no threshold satisfies both bars, ship nothing.

Where it stands

Nothing in the config the student now runs reads cartridge memory. Of its twelve goals, eleven fire from pixels through a recogniser and one fires on a line the game prints on screen; two of the eleven also stand down on a printed line. No map reads, no battle byte, no HP struct.

The forest crossing over the two days, all N=30 cold boots on the same config, seed 42:

The last row carries its own caveat: paired over the same 30 seeds the heal change gained 8 runs and lost 4, which at this sample size is not a proven improvement (McNemar exact p=0.39). What it did establish is that the trigger now fires when it should — go-heal-center went from firing in 20 of 30 episodes to 29, and every one of those 29 ended at Viridian's own counter.

The third row is the one to notice. A trigger firing where it should not does not just misbehave locally — the heal trigger was firing 383 times inside Viridian Forest, a room with no Pokémon Centre counter in it, and evicting the forest walking lesson 22 times. It was the single largest cause of the crossing failing, and the fix was in a different goal entirely.

And the honest comparison: the same 25-link config with all five cartridge reads still in place crossed the forest in 41 of 60 agents. Screen-only currently costs ground.

That is not a like-for-like measurement — 60 agents against 30 runs, and the two seed their attempts differently — so read the direction and not the size. The direction is clear enough, and it is the price of the constraint rather than an argument against it. A trigger that reads the cartridge cannot leave the building.

Every figure here is N=30 or smaller against a project convention of 3,000 attempts. These are screens, not certifications.

One command

All of this is now agentgb trainscene: select the positives, train, probe real play, sweep the threshold on both sides, and print a registry entry — or refuse.

It refuses by default if a trigger fires even once where it should be silent, because a trigger behind a hold strands the whole run on a single false positive. It refuses if any genuine occurrence is missed, counting occurrences as episodes rather than frames, so a long fully drawn tail cannot carry a trigger that misses every half-drawn entry.

It refuses in practice and not only in principle. The first trigger it was ever pointed at in anger — the Pokémon Centre counter — came back refused on round one, with 21 of 22 probed areas firing.

Rebuilding the forest-entry trigger with it, natural negatives alone: held-out balanced accuracy 1.0000, and 21,295 false alarms in 1,751,142 frames, 1.2% even at 0.999. Refused, with 21 of the 23 probed areas named and the flag to paste back printed underneath. With those negatives added: zero false alarms at every threshold from 0.8 to 0.999, all 150 crossings still caught, the weakest at p=0.999974. Three and a half minutes.

The other half is not a command. Dump the positives, look at the montage, and ask whether every row is the thing you meant. It has now caught three poisoned piles where every number said clean, and a person spotted each of them by eye.

Don't ban the action. Let the belief in it decay.

The obvious fix is a blocklist — once an action has done nothing N times running, take it off the table. It works, and it's also exactly the kind of hard rule that breaks the next time the situation looks a little different. The fix that shipped instead doesn't forbid anything. It penalises belief.

Every time an action fires and the frame doesn't change, a flat amount is subtracted from that action's logit — its pre-softmax score — before the next decision. Nothing else on the board moves. The other five actions keep whatever scores the network gave them; only the one that just proved it does nothing gets docked.

The exactness is in the arithmetic. Subtracting a flat amount D from a logit divides that action's odds against every alternative by e^-D on every repeat — the same shape as an exponential backoff, arrived at from the opposite direction. A backoff grows the wait after a failure; this shrinks the confidence after one. Repeat the no-op enough times and the action that looked certain a moment ago stops being the argmax at all, sampling opens back up, and the agent tries something else — not because it was told to, but because it stopped believing the thing it was doing was working.

Whole-chain result: 594 of 600 to 600 of 600. The specific failure mode the record calls stuck_in_battle — an agent locked in a real fight, repeating an action combat wasn't accepting — went from 4 occurrences to 0.

The same machinery, pointed at healing

Once an agent can notice that repeating something isn't working, the next question is obvious: can it notice a good reason to go do something else entirely, mid-chain, without derailing the chain it's already following? The answer shipped the same day, as a second mechanism: chambered goals.

A chambered goal has two conditions, decoupled in time. An arm condition, read from cartridge memory — the agent has taken damage. A fire condition, read from the screen, checked only once armed — the agent is looking at a Pokémon Center. Take damage, and the chamber loads. Later, whenever a Center actually comes into view, it fires: walk in, heal at the counter, walk back out, resume whatever the chain was already doing.

Satisfaction doesn't have to come from the direction the design expects. A blackout heals the party too, so it discharges the chamber on its own, with no Center visit at all — the condition the mechanism exists to detect stopped being true, and the mechanism notices that as readily as it notices the Center. And because the fire condition's recogniser is never even consulted while the chamber is unarmed, it is the least-exposed recogniser anywhere in the system: arming isn't just a trigger, it's a safety property. A screen can only fire this goal at the one moment the agent is actually carrying damage.

Across the current 600-run certification, 306 runs take that detour — walk to a Center, heal, walk back out — mid-chain, at zero cost to the chain itself.

How badly hurt he is decides how sure the recogniser has to be

A chambered goal still needs to know how confident is confident enough, and that threshold isn't fixed. It's a gradient against how much the arm condition actually hurt: barely scratched, the recogniser has to be almost certain the building in front of it is a Center before it fires. Badly hurt, a glimpse is enough — the cost of a false negative goes up as the party's health goes down.

Where that gradient's floor sits was measured, not guessed, one value at a time:

0.92 is the measured last safe rung, and its margin is one notch: drop one more click to 0.91 and the chain loses a run it wasn't losing before. Every floor from 0.945 down to 0.92 fires more heals as it loosens and still lands the chain clean — the gradient buys more coverage for free right up until the exact point it doesn't.

The honest bits

The gradient shipped in its measured, governed form. It didn't start there. The first version of the confidence threshold was tuned too hot — loose enough that the recogniser it gated fired 13,673 times over the course of testing it, and five runs got trapped standing at a door, chambering and re-chambering a heal that kept almost-firing. At the floor that actually shipped, 0.92, the same recogniser fires 591 times. The difference between those two numbers is the entire reason the floor sweep above exists instead of a single value picked once and trusted.

A separate change tried to make the Center recogniser more precise by narrowing what it was allowed to look at — cropping the frame down to just the POKé sign over the door, instead of the wider shot that includes the building around it. It scored worse: 77.7% against the wider crop's 79.6%. The pixel observation the tighter crop produced was correct; the classifier simply had less to work with than the wider one gave it. That result didn't get deleted for not helping. It's in the record as a negative, because the next person tempted to crop tighter for the same reason should be able to find out it already didn't work.

And once, earlier in this same stretch of work, a chain got certified, reported and merged while four of the weight files it depended on existed only in a scratch folder — real on the machine that ran the certification, absent from everything committed. The build didn't catch it because nothing was checking. It does now: tools/test_studentconfig_guards.py test 10 fails the build if any registered goal points at a path that isn't tracked.

A blank stage, no map, no cartridge room

pixellivingart is a third swarm mode alongside AgentGB's existing teacher-run and custom-run films, and it throws out everything a Game Boy map usually provides. No walkable-tile graph, no room, no live emulator beyond one one-time read of the character's own sprite pixels straight out of VRAM and OAM — the sprite doesn't depend on the room, so any saved state serves. Everything else on screen is synthetic: a target shape, an assignment of agents to points on it, and a path from wherever each one starts to the point it was given.

A shape is one flag — pokeball, text:WORDS, or image:path.png — and the tile grid it gets sampled onto sizes itself to the shape's own ink and the requested crowd, rather than a fixed resolution regardless of either. A filled disc needs a much smaller grid than thin letter strokes for the same agent count to read as a crowd instead of a speckle: the Pokéball, 59.3% foreground at a cheap probe resolution, sizes to a 96×96 grid for 3,000 agents at 55% target occupancy. Every agent is then handed its nearest still-free point on a KD-tree, walks there on the same grid path AgentGB's other swarm films already use, and — the whole point of the exercise — does not stop once it arrives. It jitters in place, or the whole shape slowly turns, or agents trade places with their neighbours on the shape itself. A formation that freezes the instant it forms was the one thing rejected outright.

Six bugs, and only the last one hid

The render above is not the first take. The first three were rejected, and the reasons kept turning out not to be about the thing that looked wrong.

1. Standing on the TV

The spawn tile itself was right — map 38, tile (3,6), verified against a live screenshot. What wasn't right was how the room got drawn under it: the background image was anchored by centring the whole room on the spawn point, rather than aligning that one named tile within the room art. The TV sits near the room's own centre, so the character appeared to be standing on it. The fix aligns the tile, not the room's midpoint.

2. Facing built backward

Every render's first decision had every agent facing "down," hard-coded. This isn't a shortcut around a hardware constraint the way a forced facing on a real cartridge run is — this stage has no cartridge and no button ever pressed, so a starting facing is free synthetic data. It had simply never been given a real one. The fix threads through the same "up" already verified against a live screenshot of that tile.

3. Walking four times too fast

Every agent glided into formation at four times normal walking speed. AgentGB's own convention for one decision of real game time is fixed — 32 frames at a documented, un-adjustable 59.7275 frames a second — and this stage's default substep count fell short of it: 8 drawn per decision instead of the 32 the convention calls for. Set to 32, three thousand individually-timed approach paths produce a steady, staggered arrival with no further tuning; nobody needed to be slowed down by hand once the base pace was honest.

4. The camera chasing its own crowd

Early passes built the camera's keyframes by re-centring on wherever the crowd's bounding box happened to sit at that instant. As the crowd dispersed unevenly toward the shape, that centre visibly crept sideways — the frame kept pulling out from a point that was quietly moving. The fix: every keyframe now shares one fixed centre, the crowd's own position at the very first frame, and only ever grows the framing's size around it. Because every shot's centre is identical, the interpolation between any two of them has nothing left to pan across. Not a smaller drift. No pan at all.

5. A shape that was never centred on anything

Fixing all four of the above produced a render that still looked wrong: the Pokéball sat in a corner of the frame, a wide band of pure white on one side that no amount of camera tuning could close. By this point the camera was genuinely correct — a fixed centre, a pure zoom. The fault was one level down: the shape's own target points were sampled in a coordinate space with no relationship to wherever the render's one spawn point happened to land, so nothing in the shape's own geometry was centred on anything a camera could anchor to. The fix shifts every target point once, before spawns or bounds are derived from them, so the shape's true centroid lands exactly on the origin — which is also where the lone starting character now stands, so the crowd visibly erupts outward from the one point the camera never lets go of.

6. The whole crowd stepped in unison, once

The approved render still had one visible fault: for several seconds, the whole crowd appeared to take one slow step together, hold, then step again — thousands of independently-timed paths moving in lockstep. Two plausible causes were tried and discarded before the real one turned up under direct measurement: binning the render's own frame-to-frame pixel difference by decision showed every single decision, everywhere in the film, split cleanly into a near-zero-change half and a large-change half. Every agent was gliding for the first half of a decision and standing frozen for the second, simultaneously, for the entire 112 seconds — the freeze was just usually invisible, because a compression pass quietly collapses long runs of near-identical frames. The one place that collapse couldn't hide it was the few seconds where the background art itself was continuously fading, which stopped the frozen frames from matching each other closely enough to be thrown away. The cause was one shared "how far into this glide are we" value, computed once a frame rather than once an agent, and clamped to finish at the halfway point instead of the end. Making it progress across the whole span removed the frozen half everywhere, not just where it happened to be visible.

A camera that cannot lose the crowd

An earlier attempt at this shot picked keyframes by hand, and it produced a render with several seconds of pure white in the middle: the room had faded, the keyframes were still centred on the old spawn tile, and by then the crowd had already walked far enough away that neither the room nor a single agent was inside the crop. A hand-guessed keyframe is a bet against how fast the world's own content moves, and a wrong bet produces exactly this — a camera looking at empty floor.

The fix doesn't re-tune the guess. The render now logs, for every output frame that actually survives deduplication, the true pixel bounding box of every agent's own drawn position — one manifest entry per real frame that ends up in the finished file. A separate tool reads that manifest and derives camera keyframes from it directly, then verifies its own output by re-implementing ShowReel's own camera interpolation in Python — the same geometric zoom, the same eased pan, the same easing curve — and checking that every single logged frame is actually contained in the resulting viewport at that frame's own moment in the film. Wherever one isn't, it inserts a corrective keyframe exactly there and checks again, until every frame passes or it refuses to ship at all.

For this shot that's 13 keyframes covering 6,496 logged frames, every one sharing the identical fixed centre — (1584.0, 1584.0), to the decimal, confirmed directly from the film's own keyframe file rather than a log claiming it. The same pass also caught a smaller fault in the opening hold: the camera sat as frozen as the crowd during it, when only the crowd was supposed to. A small camera ramp through the hold fixed that without touching how the world itself holds. A blank frame in the middle of this shot isn't unlikely now. It's checked, on every render, against what the render actually drew.

What it actually took

The crowd's own arithmetic: a 96×96 grid, 3,000 agents, a mean walk of 40 tiles to each one's assigned point, the longest single approach 64 decisions — plus the 140 decisions every agent spends alive and moving once it arrives. At 32 sub-frames a decision that's 6,528 canvases composited, about 29.6ms apiece, roughly 193 seconds of drawing before ffmpeg ever starts; the encode itself took another 187 seconds, peaking at 5.5GB resident. The finished master: 6,735 frames, 3136×3136, 112.25 seconds at 60fps, with 0.5% of the canvases coming out as exact duplicates of the one before and dropped rather than written twice.

None of it needed a second cartridge running anywhere — the per-agent cost here was never "run a Game Boy 3,000 times," it was "paste one already-decoded sprite into a canvas, once a frame," the same shape of work this project's other swarm films had already measured as cheap. A host-wide out-of-memory event did take out a later render pass mid-flight once — forty-five processes killed machine-wide, an ffmpeg encoder among the largest. The recovery was to resume from whichever of the render's own segments had already finished rather than start over, capped at three workers running at once so it couldn't happen the same way twice.

The obvious question

The captain saw it and asked the question that actually mattered: if a generator times its own output to a video and plays inside that video, why does it live next to a blog asset instead of inside the renderer built to time things to pictures? Should it not be a feature, in Rust?

It now is. ShowReel's own commit for it calls the Python file what it was — "the devlog's throwaway chiptune.py" — and ports the idiom faithfully rather than treating it as a spec to improve on: the same pulse bass, the same arpeggio lead, the same noise drums, none of it reinvented.

What shipped

A track's source can now be generated music instead of a file. A Music spec resolves to a synthesised WAV at exactly the point a file track's asset resolves to a path, so from there it is an ordinary audio input — placement, gain, fades, multi-track mixing and the mobile cut all compose for free rather than through a second audio path built to match the first.

Authoring is one word in the film file, mirroring the shorthand the colour grade already uses:

The timing is the point

With no duration given, the tune sizes itself to exactly the film's length, so it never needs trimming and never hard-cuts to silence. fit: "film" goes further: the authored tempo is treated as a target and nudged so a whole number of bars spans the film exactly, landing the final downbeat on the last frame. Space scene cuts a whole number of bars apart and every cut becomes a chord change, generated to fit rather than hand-aligned after the fact.

The self-contained demo film proves it: four bar-aligned scenes at 128 BPM, and its three hard cuts land within about 7 ms of a downbeat in the rendered audio.

Checked against the thing it replaced

The Rust port was checked honestly against the Python original rather than assumed faithful: envelope and spectrum correlation of roughly 0.9997 and 0.9999. The one deliberate difference is a seeded random generator in place of the Python script's global one, which means renders now reproduce — same film, same audio, every time. That's a real improvement on the thing it replaced, not just a port of it.

Back where it started

The feature went straight back into the video that caused it. The AsciiWorldEngine lift film's soundtrack is arranged to its own cuts, not laid under them: sparse under the opening terminal, a riser through the bar before the reveal, the full band dropping in with a crash on the cut to the city, driving through the street and the ride, and a one-bar resolve to the tonic at the end so it lands rather than getting chopped. The ShowReel feature landed at 19:03; the recut using it landed at 19:21. Eighteen minutes.

The technique with real evidence behind it

Cut a flat screenshot — a tweet, a channel page — into two or three depth planes, space them apart, and push a camera across the stack. It reads as looking into the image rather than at a picture of it. Both tutorials that clone his shots build entire videos around exactly this move.

ShowReel already had every piece the shot needs, just not assembled into one move. A scene already holds an ordered stack of layers, each with its own camera. A still with transparency, layered over a background and given an independent camera rate, already is a parallax composite — nothing new to render, just nothing that composed it in a single call.

The one that got built

Content::Parallax takes a handful of depth-plane images and one authored camera move, and gives every plane its own fraction of that move — depth: 1.0 follows it exactly, 0.0 sits still, anything else scales the departure, which is what actually reads as depth: nearer things moving more.

Measured directly, single-threaded: a three-plane stack at 1920×1080 over 4000×2500 source planes costs about 45 ms a frame, against about 15 ms for one ordinary still-plus-camera layer at the same size — close to linear in the plane count, as it should be. The worked example — three 3200×1800 planes, threaded — averages 15.0 ms/frame across the whole clip, because most of it sits at the wide end of the push, where every plane's own mip pyramid picks a small, cheap level.

The one that didn't

Confirmed by reading the render pipeline, not assumed: there is no global grade pass anywhere in the crate. Compositing and blurring happen; nothing tone-maps a finished frame. That's the one technique on the list ShowReel genuinely cannot do.

It's real, and it's small — a single lift/gamma/gain or contrast-and-saturation pass, one more stage in the per-frame pipeline, touching nothing about text, camera or transitions. It's also ranked last of everything on the list, on purpose: a correctly graded film with no parallax evidence shots in it looks less like this genre than an ungraded one that has them. The parallax convenience shipped the same day the study did. The grade pass is still just a line item.

What actually separates the two

It isn't a missing feature. It's that his channel applies one trick — split the evidence into depth planes, time the push to the voice — with total consistency across an entire catalogue. Building the grade pass closes what's left of the capability gap. Nothing closes the craft gap except someone actually cutting a film that way, every time, on purpose.

The plumbing was already there

The surprise is how little of this turned out to be new. The frame buffer has carried a per-cell background plane — three bytes a cell — since registration plates needed one: a plate is black characters on yellow, which a foreground colour alone can't say. Every way the engine turns a frame into a picture already reads it — the terminal writer emits the colour run, the evidence SVG draws a filled rectangle under the text, the wasm bridge hands the whole plane to the browser's own painter. None of that is new code. It's been wired end to end since the plate work landed, and on every frame that wasn't a registration plate it painted nothing, because nothing ever set it.

That made the fill a rendering change, not a data one. Every place the renderer already picks a glyph's colour already has the hue in hand — Grid::put just also writes a flat 0.30 downscale of that same colour into the background plane and raises a flag saying the cell is filled. One factor on all three channels keeps the hue exact and keeps the per-cell lightness variation that gives a wall its depth: a brighter wall cell gets a brighter, still-dark fill. The world model needed nothing new — no field on a building, a car or a cell — because the fill is derived at the moment it's drawn, not stored anywhere.

Why a view, not a flag

Because the background plane costs nothing while it's black, turning the fill on could be gated behind a single per-frame check — the same check that already made the plate work free on every frame without one. That's what let this ship as --view classic|blocks|middle, read the same way --weather clear|rain|downpour already is, rather than as a setting that quietly changed the default look. Classic isn't a second code path kept alive for compatibility; it's the fill code simply not running. Every capture and every film already on this site stays exactly the frame it was shot as.

That distinction was checked, not assumed: three scripted --capture walks in --view classic came back byte-identical to the frames the engine wrote before any of this landed. And it's worth being straight about the reference clip here too — its whole four minutes are the new look, with no old-view section and no side-by-side. That it can fall back to a bare-glyph mode is a credible claim about how engines like this are usually built, but it isn't demonstrated in the source. Proving reversibility here, rather than assuming it, is the actual difference between a view and a repaint.

The three things that weren't free

Deriving the fill from a hue the engine already had was the easy 90%. Three things needed real work:

• The ground had gaps. A road cell whose glyph is a space was simply skipped, so the street was already speckled — colour on the characters, black between, and the road is the single largest black area in any frame. In a filled view the ground now writes its fill even where no glyph lands. It's the single change that opens the street up the most.
• Contrast had to be designed, not just derived. A glyph on a fill of its own hue can vanish if the two lightnesses sit too close. A flat 0.30 downscale — tried by eye against 0.24 and 0.38 side by side — keeps the ink about 3.3× brighter than its own field at every lightness, so it can't disappear even in the tightest case: amber on amber, a hue with no chroma to fall back on, only luminance.
• Plates had to stay plates. The legibility scorer that grades a registration reads runs of coloured background, so once the whole city has one, a filled frame could read as one enormous plate. It didn't need fixing — the scorer already disambiguates a plate from its surroundings by a separate plate mask, not by the background colour itself — but that had to be checked, not assumed, and it's now a named test rather than a hope.

Indoors, the same rule holds

The reference engine's buildings read as one flat hue apiece; this engine's walls vary lightness cell to cell for depth, and that variation was the one thing not up for negotiation. Fill and keep the gradient, or the change is a downgrade wearing an upgrade's clothes.

What it costs, measured here

Filling the background is new work on the hottest path in the renderer, so it was measured rather than assumed — six interleaved pairs of 400 frames at 180×60, tools/bench-view.sh, the same binary run in --view classic and --view blocks alternately so machine load lands on both equally:

The machine wasn't fully settled while this ran — load average sat around 7–8 rather than the under-0.5 the project's own benchmarking notes ask for — but the method is interleaved pairs precisely so steady background load lands on both sides equally, and it reproduces the project's own +19% figure for the street almost exactly. Most of the cost is in paint, not the renderer itself: a filled frame emits a terminal colour-change sequence wherever the fill colour changes, where a classic frame emits none. Classic stays the default, and stays free — nothing pays this cost unasked.

The render got faster along the way

Profiling render broken down by pass, to see where the fill's cost was landing, found two passes doing work once a column that only depends on the row — sky was recomputing an elevation angle per cell instead of once a row, and ground was re-deriving the same world cell down a column where one screen cell spans several rows of it. Both were hoisted out.

Measured the same way, interleaved against the build immediately before this change, six pairs of 400 frames at 180×60:

The "after" binary includes the whole view-mode change — the extra branch on every pass that checks whether to fill — and it's still faster than the build before it existed, because the two hoists pay for the new branching several times over. Under the same machine conditions as the table above, so read the absolute numbers with the same caution; the direction and the rough size of the win are the finding. walls, the single most expensive pass, was left alone — it has no redundant work to hoist out, and chasing a few percent there risks the look for not much.

What shipped

Three named views, run the same way weather is and toggled live with B while you walk:

All three work everywhere the engine runs — --vista, --capture, --film, --doorway, --lift, the browser build — because the fill isn't a fourth picture the renderer draws. It's the frame buffer's own background plane, finally filled.

The softness was never in the glyph

It was in the sampling, four lines down in a dependency:

let img = img.resize_exact(rect.width as u32, (rect.height * 2) as u32,
                          FilterType::Triangle);

Measured on dmg-acid2 at 80×24 cells: 271 distinct colours, 268 of which no Game Boy shade maps to.

The fix samples the cells directly, nearest-neighbour at pixel centres, the same rule the video scaler already used. It also writes a uniform cell as a space rather than ▀, so a font with a poor block glyph cannot soften the large flat areas a Game Boy picture is mostly made of.

Doing the work ourselves is cheaper

This is the part that surprised me. The new path pays a full sampling cost on every frame and still wins: over roughly 1,070 frames at 146×54 cells, same ROM and window both sides, whole-frame time went from 0.460 ms to 0.349 ms.

It replaces two image-crate resizes — a nearest upscale to the display's pixel size, then a Triangle downscale back to the cell grid. One pass of arithmetic beats two passes of somebody else's.

The guard is a property, not a pixel

Blur has now been reported twice here, so the regression test asserts the thing that matters: every colour on screen must be a colour that was in the framebuffer. No interpolating resampler can satisfy that.

One unit test runs a one-pixel checkerboard — the worst case for a smoothing filter — at five window sizes. One end-to-end test drives the real render on dmg-acid2 at four.

Why a suite of short ROMs cannot see it

Each one boots, measures one thing and stops. A latch that needs a transfer to end on an instruction boundary and a scan to follow it never gets the chance.

That is not a criticism of those suites. It is a property of their shape.

The check itself, which is a nice piece of indirection

A cartridge cannot see which objects the scan found. What it can see is how long mode 3 took, and ten objects on a line cost the fetcher at least sixty dots.

So: leave object memory entirely empty, put the visible objects in the transfer's source, and start the transfer so it covers the measured line's scan. A machine whose scan reads object memory straight through the transfer finds the ten objects the transfer has already written and is still drawing them. Hardware finds none and is already in horizontal blank.

Two details are load-bearing rather than decorative. Object memory is left empty on purpose, so whatever slot the scan last managed to read, it read a zero — the frozen Y puts the phantom object above the screen, and the check does not depend on where the freeze landed. And the transfer is sourced from video memory rather than work memory, because on a monochrome console work memory sits on the cartridge's own bus and a transfer out of it would feed the processor its own bytes instead of instructions. That is why every real game's transfer routine lives in high RAM.

The rule it left behind

When a check is written, run the whole cartridge and read the total, not just that check's line. A new check that passes in isolation and moves an unrelated area's verdict has found something.

One in two thousand six hundred

"All three failures were the same thing" is exactly the sort of pattern a human finds in noise, so: with 21 Bulbasaur, 2 Charmander and 3 Squirtle runs and no species effect at all, the probability that the three failures land on the three Squirtle runs is about 1 in 2,600. p ≈ 0.00038.

That is not a coincidence you shrug at. And it was the second time this exact shape of bug had appeared in this project, which is what turned it from an incident into a rule.

Why the film sees what the table cannot

Not because a film is nicer to look at. Because of what each representation can carry.

A completion table has one row per milestone and one rate per row. It is a marginal — it has already summed over the population, and a correlation between a run's hidden attribute and its outcome is exactly the information summing destroys. You cannot recover it from the table no matter how carefully you read, because it is not in the table.

The film has not summed over anything yet. Every agent is still a separate object on screen, carrying everything about itself, and the failures are visible as a group — three cells stuck in the same room at the same time is a thing you see rather than compute.

It is not free. The film that showed this takes roughly twenty-four screenshots per decision per agent — gigabytes — where the table costs nothing but the emulation. It is the expensive artefact, and this is what it is for.

Three separate causes, none of them the one first suspected

The obvious hypothesis was that the training corpus was biased toward one starter, so the student was simply worse with the others. That was checked, and it is not what was happening.

The starter choice is genuinely balanced. At the chain's own entry state the first decision carries 0.992 bits of entropy, and over 500 sampled attempts the committed student takes Bulbasaur 254 times, Squirtle 127 and Charmander 118, reaching the goal in 499 of 500. That is a real three-way split, not a collapse.

What was true, and actionable, is narrower and less obvious: two of the links on the return leg have exactly one recorded start state each, so their corpora contained zero species variation — regardless of how balanced the entry choice was. The student had simply never been shown those rooms with a Squirtle in the party.

Pulling the three failures apart gave three unrelated causes:

The fix that broke everything, and what it taught

The first wiring of the Oak-interaction goal took the whole chain from 88.5% to 0 of 150.

The trigger tile it had been trained on — one specific tile, facing one specific direction — is, independently, the chain's own entry tile for taking a starter six links earlier. Same physical room, visited three times by this chain for three different reasons. An ungated goal that fires whenever it recognises its screen fired on the very first approach to the Poké Balls and broke every single run.

The fix was structural rather than a heuristic: the late-chain goals are now only ever consulted once a return-leg stage has already latched. Not by convention — by construction. A screen that a return-leg goal happens to recognise can no longer hijack the outward leg, however visually identical it is to something further down the chain.

There is a general shape here worth naming. In a route that revisits the same rooms, a recogniser's precision is not a property of the recogniser. It is a property of the recogniser and the window of the episode it is allowed to look in. Ours was excellent at its job and catastrophic without a gate.

Where it landed

After the three fixes, an eight-agent smoke test first — 8/8 — before committing to the long run. Then a cold-boot certification at N=150:

No starter anywhere near zero, all three intervals overlapping heavily. The filmed swarm at N=26 came back 26/26 — the first time this chain's film has shown every starter completing at 100%, where the previous one showed a third of them at zero.

N=150 is not the project's 3,000-attempt convention, and bounds failure near 2%, not 0.1%. And Charmander's 13/13 has a lower interval bound of 77.2%: thirteen runs is evidence of not-obviously-broken, not of perfection.

What this actually generalises to

Very little of the above is about Pokémon.

An agent population with a self-selected hidden attribute — which tool it picked, which branch it took, which variant it was served — will produce an aggregate success rate that is arithmetically correct and behaviourally meaningless the moment that attribute correlates with outcome. The failure mode is not a wrong number. It is a right number answering a question nobody asked.

Two cheap defences came out of this. Break every rate down by the attribute, whether or not you expect it to matter. And keep one artefact in the pipeline where the population has not been collapsed yet — expensive, rarely looked at, and the only place a structural split is visible before it becomes a mystery.

Every poll looked too fast

The device-code login flow enforces a minimum polling interval, and the endpoint has to both read the last poll time and stamp a new one.

Written the obvious way — one UPDATE … RETURNING — it silently never works, because RETURNING sees post-update values. The endpoint reads its own new timestamp, computes an interval of zero, and interval enforcement quietly does nothing.

The shape that works reads the previous value under a row lock first and updates in a second common table expression. It was caught before commit by reading the Postgres documentation rather than by a test — and there is now a test, so a "tidy-up" back to a single statement turns red.

The same snapshot rule bites twice more in this codebase: a data-modifying CTE is invisible to the same statement's SELECT, so the lapsed-sprite purge must run as a separate UPDATE before the SELECT that reads the collection, and the rate limiter counts only prior attempts — which is why "max" here means allow exactly max, deny the max-plus-first.

A row id that was a string

pg returns 64-bit integers as JavaScript strings by default, because they do not fit safely in a double. Every id in this schema is a bigint, so Number.isInteger(id) guards silently stopped guarding and ids in JSON quietly became strings. Measured: a friendship id came back as "1".

One type-parser registration at the database module fixes it globally.

A grid that could not shrink

The Pokémon cards live in a CSS grid. Written as repeat(auto-fill, minmax(16rem, 1fr)), that grid physically cannot get narrower than 16rem — so below about 350 pixels it made the whole document wider than the viewport and every panel on the page got clipped mid-word at the right edge. The min(100%, 16rem) spelling is load-bearing, not stylistic.

The same class of fault lived in two other places: the site header, where the brand plus the navigation come to about 350 pixels with no wrapping allowed; and a form label inside a card, where a flex item's automatic minimum size is its content width, so a 16rem minimum on one label spilled the card at every width.

All three are one mistake — a rule that sets a floor on the page width — and one measurement catches all of them:

for (const el of document.querySelectorAll("body *")) {
  const r = el.getBoundingClientRect(),
        p = el.parentElement.getBoundingClientRect();
  if (r.right > p.right + 1) { /* this element overflows its parent */ }
}
document.documentElement.scrollWidth > document.documentElement.clientWidth

And one that belongs in no category

pgrep -f and pkill -f match the process doing the matching. An automated run on this repository killed itself with a pattern sweep for a dev server, because its own command line contained the pattern. Kill by the process id you captured when you started the process.

And then one line was worth a hundred maps

A door is a warp on both sides. You arrive on the doormat, and a player still holding the direction takes one more step and walks straight back out.

Holding: 113 maps photographed. Releasing on arrival: 216.

The one that was stranger: shop clerks talk

Several maps put a text box up the moment you arrive, and Generation 1 does that by parking the window layer at WY = 0. Which means the window covers the entire screen and the map is drawn through it.

An earlier version of the comparison excluded "wherever the window is", the way it excludes sprites — and so masked the whole picture. 31 maps went from exact to inconclusive and two to no-alignment, with nothing in the report to say why.

The right answer was not to subtract the text box but to dismiss it, the way a player does: press B until the window is off-screen again, requiring several consecutive clear checks, because the window parks off-screen for a few frames between two boxes of one conversation.

It looked like a tolerance problem and it was a modelling one.

What it did not rescue

The Hall of Fame. Walk in and Oak starts talking, and his script is not one you can press B through — it inducts the party. PixelGB presses B up to eighty times and requires four consecutive clear checks before photographing; this one still has a text box up when the budget runs out, so it is counted on its own.

Ten more maps have nowhere to arrive: a warp names a destination warp on the far side and these have none, so the camera comes to rest outside the map. Those and the Hall of Fame are the eleven named on the project page.

The answer with real N

Dozens of genuine frames per message, taken from the typing animation itself, over six distinct in-game messages. Nearest-centroid across all six identities, with a temporal split — train on each message's first 65% of typing, test on the last 35% it has never seen.

97.2% accuracy against 20.0% chance, N=36 held out, permutation p < 0.005. The confusion matrix is essentially the identity matrix.

What survives is shape, not letters: line length, word-wrap position, letter density per region.

One of the six messages had to be captured from a separate session, and its background differs from the other five by 14 of 1,440 cells, all inside one small icon. Removing that message entirely, or masking those 14 cells, moves the headline by about one point.

The version that mattered in practice

Compare the bag opened with an empty item pocket against the same bag holding Oak's parcel. 57 cells of the 40×36 observation separate the two states perfectly, and not one of them requires reading a letter.

A goal marker does not have to be legible text. A reliable change in layout is enough.

These are fresh linear probes and nearest-centroid classifiers fit on frozen observations, not a trained student network, so there is no weights file to name against them.

Read the table, and check the rows nobody disputes first

Six bytes per move, straight out of the cartridge:

Every row but the one under investigation matches the values Generation 1 is known for. That is what says the table is being read at the right offset with the right stride.

python3 - "$ROM" <<'PY'
import sys
rom = open(sys.argv[1], 'rb').read()
e = 0x0E * 0x4000 + (33 - 1) * 6   # Moves, 0E:4000, TACKLE is move 33
print("power %d accuracy %d (%.1f%%)" % (rom[e+2], rom[e+4], rom[e+4] * 100 / 255))
PY
# power 35 accuracy 242 (94.9%)

Where 240 came from

94% of 255 is 239.7, which rounds to 240. It is the byte you get by computing it from a percentage you already believed, instead of reading it.

And the accuracy byte is not the accuracy anyway

The hit calculation scales a move's accuracy byte by the attacker's accuracy stage and the inverse of the defender's evasion stage. A policy reading the ROM value is reading a number that has not been true since the first SAND-ATTACK landed.

A Pidgey's SAND-ATTACK takes a 95% TACKLE to 62% and then 47%. Both ratios come out of a stage-modifier table read from the cartridge, located by searching for its own opening bytes — a signature that occurs exactly once — and re-checked on every read against two properties: the first pair must be 0.25, and the middle pair must be exactly 1:1, because a table read from the wrong place almost never has a neutral stage in its middle.

There is a second trap underneath it, and the atlas carries its own warning about it: in the stat-stage block, 7 is neutral, not 0, and the block is zeroed work RAM until the battle-init routine writes the sevens. A sample taken on the first frames of a battle reads 0 everywhere and looks like every stat six stages down.

Cold evaluation over a state pool is optimistic by about a factor of two

Every state in a start-state pool is frozen from one traversal, so the map's own people barely move between them. Same policy, same tile, 150 attempts: 100% under a 0–96 frame start offset, 52.7% under 0–3,000.

Six distinct people-layouts against twenty-two. That is the whole difference.

Every rate published since carries both spreads. The gap between them is the measure of how brittle a student is.

Then the naming rule

On 21 August, in one evening, this project reported a rate to the captain as belonging to the committed network when it did not — twice. Once because a results page never named which weights produced its headline. Once because a sampling result measured on one student was carried onto a different one.

Both reports were plausible, both were wrong, and nothing in the repository could have caught either.

The fix is a check that fails a build the same way it failed the captain. A page opts in with a marker in its first forty lines. Every table on an opted-in page that contains a percentage-looking cell must carry one of: a per-row attribution column, a weights filename in its rows, or the literal word unattributed.

The opt-in matters. Most tables in the repository are about the teacher — a scripted program, never versioned by weights — or about cartridge mechanics. Neither has this ambiguity.

And the checker passed for the wrong reason

An early version carried a sticky "have we seen a model name anywhere in this file yet" flag. A single mention in a page's opening paragraph made every table below it unfailable, no matter how far below and no matter what it was about.

It was caught by deleting a real table's attribution column and watching the check still pass. Each table is now judged on its own.

Indoors is a decision, but the door is not

An interior has no connections at all. The cartridge says which door leads to it and nothing about where the room is. So the rule is one sentence: a building is drawn adjacent to the map its door is in, on the side that door is on, in line with it.

What follows from that took several rounds, and the way to compare them is the room-to-door distance over the rooms every layout can measure:

Ordering has to outrank nearness, and the weight was measured

Two buildings whose street doors are on the same side of the same town must be drawn in the doors' own order along that side. Added as an ordinary term in the distance cost, that loses every time: an inversion the eye reads at a glance is worth only a few pixels of nearness, and a building will buy the pixels. Which is how Cinnabar's gym came to be drawn below the two shops whose doors are eight tiles below its own.

At weight 4 the cartridge still has five pairs the wrong way round. At 8 it has none. From 8 to 16 the layout does not move at all.

And "not the wrong way round" turned out to be a loophole the search will find. With equality free, seven pairs came to rest exactly level — Saffron's gym and mart among them, the very pair that was complained about. Making the ordering strict cost nothing: same mean, same median, same sheet.

One warp in the cartridge is not a door

Celadon City's ninth warp, tile (39,19), drops you into map 136 — the department store's fifth floor. That floor's own three warps lead to the roof, the fourth floor and the lift; none of them leads back to the street. Read as a street door, it filed one floor of the store 254 tiles from the other six, on the opposite side of the city.

So an outdoor warp counts as the way in only when the room it reaches has a warp back to the map you came from. Map 136 is the only map in the cartridge that fails that test, and with the rule in place the store lands as one column of seven.

Victory Road looks like the same bug and is not. Route 23 has two street doors of its own, into 1F and into 2F, and both rooms walk back out. The route is 20 tiles wide, so those doors are genuinely on opposite sides of it and the two halves file either side. The community's hand-authored atlas bundles them; the cartridge does not, and the cartridge wins.

A building that will not fit comes apart at one of its own doors

The S.S. Anne is entered through Vermilion's dock rather than off the street, so the dock, the ship and its eleven rooms are one building. A twelve-room block wants about a million square pixels of one rectangle, and that does not exist within two screens of Vermilion. Every arrangement of it as one block put it beyond Route 12, further from its own town than anything else in the cartridge.

It was not mis-assigned and the search was not failing. Measured against the finished sheet, where it stood was the nearest place a single rectangle of that size would go.

So a building may be cut at one of its rooms, and the rooms behind that door become a wing, placed by the same rule with "the map" now meaning a room of its own building.

What is not negotiable through any of that: a panel never covers walkable world or another panel. The finished rectangles are checked and an intersection fails the render. That assertion is worth more than the rule it guards, because it is what makes the next change to the layout safe.

Why no amount of training fixes it

What tells the two crossings apart is OAK's PARCEL sitting in the inventory. The inventory is not drawn on the overworld screen. This agent reads a 4 × 36 × 40 picture and nothing else — no coordinates, no map register, no memory read of any kind — so the input on the way out and the input on the way back are, for practical purposes, the same input.

A function cannot return two different values for the same argument. This is not a capacity problem that a wider network or another thousand epochs reaches; it is a statement about what is representable. The 33.53/66.77 split is that statement, measured.

The first fix worked, and was abandoned anyway

The obvious answer is to go and look. Gen 1 does draw the bag's contents, and the two states are visibly different — ▶OAK's PARCEL / CANCEL with it, ▶CANCEL alone without. So the first design gave the agent a seventh button, taught it to open the bag, read it, close it, and only then decide which way to walk.

It was built, trained, and smoke-tested successfully. A real certification run put the harder of the two rooms at 5/5 and then 299/300. It genuinely worked.

It was thrown away on the captain's correction, and the reason is the interesting part. The game already announces that the parcel has been collected, in plain unmissable text, at the exact frame the milestone fires:

Building a seventh button, a bag-opening sequence, and an on-the-way-in-versus-on-the-way-out disambiguation at an identical menu picture was solving a problem the cartridge had already solved — one layer further from the screen than necessary. The bag check was not wrong in the sense of not working. It was wrong in the sense of reaching past an answer already sitting in plain text to go digging for a second, harder copy of the same fact.

The pattern that came out of it

Once you look for it, the shape is everywhere in this route: every goal in the chain ends with the cartridge announcing, in unique on-screen text, that it is done — and that announcement is the trigger for the next goal. A recogniser per announcement, a trained behaviour per goal, chained in order.

Nothing is deduced, nothing is inspected, nothing is hard-coded. The driver that implements this knows nothing about parcels, Oak, or any specific room; declaring a new stage is a longer list in a data file, never a change to the code.

Two design details are worth pulling out, because they are the whole difference between this and the interrupt mechanism the project already had:

The trigger did not need a crop, and that was checked first

Another recogniser in this project keys on a nickname prompt and needs a deliberate crop, to hide a species name a wider view would let it cheat on. This one takes the full observation, because the parcel announcement is not a screen that could plausibly be confused with anything else in the game.

That was verified before a recogniser was trained rather than assumed after. Playing the scripted teacher through the collection and recording the on-screen text at every decision found the exact string and the exact decision it appears on. Then the last recorded frame of successful episodes — from a 1,500-episode corpus whose episode lengths range from 13 to 34 decisions — was compared against a fresh live capture of that screen: byte-for-byte identical, zero difference, on every one of five spot-checked episodes of very different lengths.

The reason it is identical is structural rather than lucky. The dialogue box is opaque, and the success flag fires at a fixed point in the game's own script no matter which button got the player there. That is what makes "the last frame of a successful episode" a correct way to harvest training positives without any per-frame text matching at all.

The shipped recogniser scores 99.93% held-out accuracy and 99.96% balanced accuracy, trained on 1,500 positives against 6,000 negatives sampled from six other links' own corpora.

What it measured

Each of the five return-leg links certified on its own, with the adapter applied unconditionally, sampled at temperature 1.0, N=300 — alongside two floors, because a rate with nothing under it is not evidence:

The two rows in bold are the doubling-back rooms — the entire reason the work exists. Both certify at 100.00%, against random floors of 3.40% and 1.20%. The mechanism resolves an ambiguity that a memoryless, unconditioned student provably could not.

N=300, not this project's usual 3,000. Three hundred clean attempts bound a failure rate near 1% by the rule of three.

And then the honest part

The first full sixteen-link cold-boot swarm, with everything wired in, reached the last link before the parcel is delivered — and scored 0 of 26 on it.

Not 60%. Zero. Fifteen of sixteen milestones at 100%, both hard rooms perfect, and the last one a complete failure.

It was worth having, because it was specific. The 73.67% above was the same weakness measured in isolation, and the chain's own actual entry tile evidently sits on the unlucky side of it consistently enough that no draw of 26 clears it. Isolated replay showed the failure precisely: the adapter reproduces the teacher's first eight moves exactly — left, then seven ups — and then, at the one decision the teacher turns right toward Oak, presses down and oscillates up/down at that junction for the rest of its budget.

A second training draw with more epochs and a larger sampled corpus produced the identical failure at the identical junction. Not seed noise — stable across independent draws, which is its own finding: this project has now found three times that "more epochs" is not an answer to a genuinely blind tile.

The mechanism suspected, half confirmed and half refuted

The plausible story was that the frozen base holds a confident, actively wrong prior at that tile — it shares its room with several links the base was trained on — so the adapter has to overturn a strong opinion rather than fill an empty one.

Measured directly at the stuck tile, that half is true: the base reads 96.3–97.7% down — the wrong answer — under every trained goal id.

The proposed fix, though, was refuted rather than left untested. Feeding the untrained neutral conditioning row instead of the usual one gives 96.3% down, statistically indistinguishable from what it replaced. The identity transform passes features through unmodified, but the action head was never trained on unconditioned features in isolation — so an "untrained" row is not the same thing as an "unbiased" one. That is a distinction worth carrying out of here.

One id is measurably different, reading 61.3% right / 38.7% down — not confidently correct, but the only one whose prior does not actively fight the right answer. Retraining against it is the next thing worth trying, and it was deliberately not tried here: that id's semantics for this checkpoint are not established, and changing it risks four links in the same stage that already work.

Where it ended up

The last link was closed in a later round — a fresh corpus for the conversation half of it, a dedicated goal for the press that starts the conversation (the base gets that right only 4.55% of the time unaided), a battle policy on the return crossing of Route 1 changed from flee to fight-or-flee after a real seed was traced into an infinite battle-menu deadlock, and two purpose-built start states so the corpora were not all the same starter.

Cold boot, N=150, sampled, the whole sixteen-link chain: 145/150 = 96.67% [92.4–98.6%]. Per starter — the standing rule now — Bulbasaur 87/90, Charmander 13/13, Squirtle 45/47, no starter anywhere near zero and all three intervals overlapping heavily.

One more result belongs here because it is the most useful kind. Running the same command without the already-shipped interrupt adapters gives a much worse 13/26 — and every one of those twelve extra failures is a known trap six links earlier, nothing to do with the return leg at all. A chain-level number only means what it claims once every already-fixed piece is actually wired in.

The bug was in the teacher

Every teacher in the repository answers an open text box with B. Except the navigation teacher, which gated that rule on a mode flag — and that flag reads "overworld" while a box is on the screen.

For five links nothing noticed, because no navigation link had ever been in a room with a conversation in it. The link that leaves the lab is the first. It put thousands of frames of an open text box into the corpus labelled with a direction.

A direction press re-triggers the box. The student learned that faithfully and did it four hundred times.

Measuring the blast radius

The fix is one shared helper. The interesting question was how much else the bug had poisoned: 12.84% label drift on the link that leaves the lab, and 1.43–3.63% on the four other navigation links.

Both the before and the after are published, because the after is not legible without the before.

Which weights these numbers belong to

The 7-of-300 and 300-of-300 figures belong to an earlier, uncommitted arm of the student which always took Charmander. They are a before-and-after on one training arm, which is what they are, and not a score for the file that ships. The shipped student's own rates are on the project page.

The repair is not a bigger budget

The row the mart door opens onto crosses the city cleanly, sits six rows above the ledge, and the rest of the chain finishes even from below the ledge. So the leg turns west first, and an overshoot costs nothing.

This shape has now appeared three times, which is what makes it a rule rather than three anecdotes:

The tool that checks it over-reports, on purpose

It cannot know whether an overshoot is reachable — that needs the map's people, and a person in the way is what pushed the walker over the ledge in the first place — and it has no model of the driver's stuck-sidestep. So it is a design aid, not a gate, and it says so.

The piece that didn't exist

Nothing in the house could zoom or pan across a still that large, or choreograph several independently-timed clips appearing at chosen positions on cue. That's a camera and a scheduler, not a renderer — and it's exactly what a tool like Remotion is for.

Remotion's own documentation doesn't put a number on the one thing that actually mattered here: whether a smooth pull-back over an image that size performs at all. Not "renders eventually" — holds something close to real time, for a shot that needs nine continuous seconds of it. That was the one genuine unknown, and it was the kind of thing that could have ended the idea before it started.

Building our own instead of adopting theirs

The licence was never actually the obstacle. Remotion is free for one person working alone, personal or commercial use either way, so the open-source-versus-paid-seat question people expect never came up. What decided it was smaller than that: the piece Remotion would actually contribute — a camera and clip choreography over footage we already generate — is a well-understood technique, and building it cost about the same as learning somebody else's framework well enough to trust it. Minus the ~300MB Chromium download and a Node toolchain nothing else here uses.

So: ShowReel. A Rust crate — eighteen modules, a little over 8,600 lines — that takes a description of a film and renders it, deterministically, to an mp4. tiny-skia and rustybuzz draw the pixels and the glyphs; ffmpeg encodes. No browser, no Node, no headless Chromium. From the point the Remotion question was answered to a rendered film was under two hours.

The film itself is 393 lines written against nothing but that public API — a title screen, a camera move, five bursts of footage, a pull-up naming one of them. Nothing in the crate underneath it knows what a map or a Pokémon is; every map rectangle and clip timestamp lives in that one file, as input.

The number that mattered

The test that answered the risky question: a 120-frame pull-back over the actual 6,832 × 7,024 atlas, rendered down to 1920 × 1080.

33× faster than the obvious version, and around 8× faster than real time for the actual shot.

The reason is choosing an already-shrunk copy of the image before resampling, instead of reading the full 48 megapixels on every single frame regardless of how much of it ends up on screen. Cost becomes proportional to the output size rather than the source size — close to constant, whatever the zoom. Building that pyramid once, at load, costs 523 milliseconds and holds 192MB resident afterward. When the camera pushes in rather than pulls back — a Game Boy screen blown up to fill the frame — the same code switches to nearest-neighbour resampling instead, so the pixel art stays sharp rather than turning to mush.

Where it actually happened

The whole opening chain — leaving the bedroom, the rival battle, out of the lab, north up Route 1 — happens within a few hundred pixels of Pallet Town. On a picture of the whole region, that is a few dozen screen pixels. Every burst in the finished film clusters there, because that is where the footage covers, not because the film is choosing to.

So each clip sits at the edge of the frame instead, and a line is drawn back to the map coordinate it actually happened at.

What it doesn't do

There's no audio — every encode ShowReel produces drops the input track outright. Memory is spent on footage, not on the picture: the finished film holds over a gigabyte of decoded video clips in memory at once, about six times what the 48-megapixel atlas itself costs once it's been reduced to its pyramid.

There's no scrubbable preview player either, the thing Remotion's own docs lean on hardest. In its place: a single frame in about a tenth of a second, a whole labelled contact sheet of the film in three seconds, and a genuinely scaled-down preview pass in under seven — all well short of the 25 seconds a full render takes. That loop is what caught a caption running off the edge of the frame before a single second of video was ever encoded.

The anatomy

Three explanations, all closed by measurement

Not the route. The teacher, driving from the same tile with the same offset, reaches the Mart in 30 decisions. There is a way round and the privileged player finds it.

Not a wanderer who would eventually move. The person steps twice, at decisions 13 and 61, reaches (31,20), and then does not move for the remaining 533 decisions — about 17,000 frames, or 4.7 minutes of game time. Checked under four different player behaviours from the stuck moment, including backing off a tile and standing still, and pacing 266 tiles up and down. It stays parked in all four.

Not the bag check. The run spends 301 of its 600 decisions with a menu on screen, but the menus are not what pins the person: an arm that presses only b runs the overworld continuously for 533 decisions and the person does not move either.

Which weights these rows belong to

Every rate for this link predates a corpus re-collection on 23 Aug 2026. The round-0 corpus it was trained from carried 105 leaked frames; a fresh corpus collected under the fix audits clean, and no student has been retrained or re-certified on it. The certification file does not record which weights it ran, so these rows are marked unattributed rather than filled in from a directory convention.

This is a measurement of one reproducible attempt. It has not been re-measured since.

The counter did change, later, for a different reason

A second independent source arrived. Gambatte's div/start_inc_{1,2}_cgb04c take the genuine Color path and pin both the divider's value and the exact machine cycle its low byte wraps on, at a fixed distance with no LY wait.

So they measure the counter alone — precisely the confound the original objection named. The constant moved on their evidence.

Bully's row is still red, byte-identical in both picture modes, because the PPU half is untouched. Two crews' work settled half a question; the other half is still open, and the red row is what says so.

The other red that stays

Blargg's oam_bug fails on a Color console here. All eight sub-tests pass on DMG, where the object-memory corruption defect is modelled faithfully. Color silicon has no such defect, so real hardware fails that ROM too. Passing it would be the bug.

Both rows are kept on the board rather than excluded, because a suppressed red is indistinguishable from a fixed one six months later.

The constant was derived, not chosen

The controller takes the bus a fixed number of dots after the write to $FF46, and that number is the one free parameter in the whole model. It came out of eight ROMs.

Gambatte's late_sp{00,01,02,39}x_{1,2} each put the write one machine cycle either side of one scan slot. sp00x_2 finds object 0 while sp01x_1 misses object 1, which brackets the arm. The sp02x/sp39x pair — same DMA phase, different slot — rules out every uniform shift.

Then it was swept across the whole 811-row oamdma/ group:

The scan reads on even dots, so 1 and 2 are the same machine. A curve with a flat top two dots wide, and a physical reason for the width — that is what a derived constant looks like, as opposed to the one value that made a favourite test go green.

The data half came first, and was worth four hundred rows

Three days earlier the same physical rule was modelled from the other side: while the transfer runs, the CPU and the controller share one bus, so the CPU's reads of most of the map come back as whatever the transfer is putting on it.

Gambatte went from 2,682 to 3,083 of the rows scored at the time. Four hundred rows, from modelling a bus conflict instead of a copy.

And then a sibling project found the flag

GBSelfTest's object-DMA check found a real bug in this model on the day it was written: the flag the PPU keeps about a running transfer was cleared on one of the two paths that can notice the transfer has ended, and not the other. Once it latched, the object scan never read object memory again for the rest of the session.

Thousands of rows across five public suites were byte-identical either way. Why they could not see it →

A subroutine that quietly ate the measurement

FlipSpeed runs the documented STOP-based speed-switch sequence and, like every subroutine in that file, makes no promise about which registers survive it. It loads A repeatedly on the way through.

A check that measured something into A, called FlipSpeed to return to the starting speed, then compared against A, was comparing FlipSpeed's own leftover value.

It does so silently, producing a plausible and constant wrong number rather than a crash. It shipped in GB-PPU-07's double-speed half and was caught only because the wrong number ($1) disagreed with an independent measurement on two unrelated emulators that had already established the right one ($2).

Two checks that skipped on every console, forever

This is the best of the three, because nothing about it looks wrong.

The build did not pass rgbfix -c, so the ROM's header byte at $0143 was $00 — and a real Color console boots a cartridge with no Color flag into DMG compatibility mode, where KEY1 and double speed do not exist at all.

Meanwhile the cartridge's own console detection still correctly reported CGB, because it reads the boot handover registers, which do not care about the cartridge's header.

So a double-speed check written the ordinary way built, linked, and skipped on every run, on every console, forever. Nothing looked wrong until somebody specifically asked whether it had ever run. Confirmed by building both ways and watching GB-CYC-09 and GB-PPU-07 go from permanently-skip to actually-run, with no change to any other check's verdict on any console.

Two clocks, one of which doubles

The Game Boy Color can switch its CPU into a double-speed mode. The important, easily-forgotten detail is that this does not speed up the screen. The picture processor's dot clock is fixed; only the CPU's own clock doubles. So the unit that a lot of internal timing is measured in — the CPU machine cycle, or "M-cycle" — changes width depending on the mode:

The one-dot stagger

Real Color hardware doesn't make an LCDC write visible at the exact instant the CPU performs it — a couple of the bits become visible to the picture processor one dot later than the rest. TerminalGB modelled that faithfully with a one-dot "early" stagger on the memory unit's LCDC write-commit: hold the change back by a dot, then apply it.

The trouble is where that one dot came from. The stagger was calibrated exclusively against a suite of single-speed reference ROMs, where an M-cycle is four dots wide. A one-dot delay inside a four-dot budget is comfortable. But in double speed the M-cycle is only two dots wide, and the deferred value's slot fell off the end of the cycle. The commit was silently never applied — no error, no assertion, just a value that quietly evaporated and a stripe drawn from the wrong tile source for one dot too long.

Finding it

It surfaced as a hard reference failure, not a bug report. The accuracy harness runs the AGE test-ROM m3-bg-lcdc-ds@cgbBCE — a Color, double-speed ROM built specifically to stress mid-scanline LCDC writes — and compares the rendered frame against a hardware-captured reference image. It read 2,304 of 23,040 pixels wrong. Its single-speed sibling, m3-bg-lcdc@cgbBCE, was already pixel-exact. One passing, one failing, identical but for the speed switch: that pair is what pointed straight at the clock, not the renderer.

The fix

The commit routine now knows what speed it is running at. Where it used to apply a fixed one-dot stagger, it takes the running GbSpeed and drops the stagger to zero when there is no room for it:

// ppu_write_commit — CGB LCDC arm
let early = match speed {
    GbSpeed::Single => 1,   // 4-dot M-cycle: a spare dot exists, model the hardware delay
    GbSpeed::Double => 0,   // 2-dot M-cycle: no spare dot — apply immediately instead
};

Removing the stagger outright in double speed beats leaving it in to be silently truncated. The single-speed path is untouched, so nothing that already passed regresses.

What actually happened to the numbers

m3-bg-lcdc-ds@cgbBCE went from a 2,304-pixel failure to a pixel-exact pass, moving the AGE suite from 10 to 11 of 59, and the Gambatte double-speed rows improved on the accurate engine. Five more rows fell sharply without reaching zero:

Those remainders are a different, smaller timing discrepancy that the stagger bug was masking. Eight wrong pixels are reported as eight, so the next person to open that scoreboard sees exactly how much is left to chase.

The regression is locked in with a test that has teeth: reverting the stagger to a fixed 1 unconditionally reproduces the original 2,304-pixel failure, so the mistake cannot quietly come back.

A note on counting pixels

Not every "wrong pixels" number on the scoreboard is a raw count of differing pixels. The Mealybug Tearoom comparisons use a shade-rank distance, which is deliberately unforgiving: a frame that introduces one extra distinct shade can report on the order of 23,040 "wrong" no matter how much of the rest is perfect, and a four-pixel error can move the total by tens of thousands. Four genuinely wrong pixels there scores 22,070.

So these figures are never converted to a percentage. The 2,304 and the residual counts above are direct pixel counts from the AGE and Gambatte comparisons; a shade-rank distance is treated as an ordering signal, not a pixel tally.

Why this needed the accurate engine at all

A one-dot, mid-scanline error is invisible to a fast emulator by construction — which is exactly why TerminalGB carries two picture engines rather than one.

The standard engine draws a whole scanline in a single step at the end of mode 3, from whatever the registers hold at that instant. It is fast and it is correct for the overwhelming majority of software, but it physically cannot represent "the wrong tile source for one dot in the middle of a line" — it never looks at the registers mid-line. The identical engine walks the real hardware pixel pipeline dot by dot: the background fetcher, the eight-pixel FIFO, sprite fetches, the window restart, the SCX & 7 discard. A mid-scanline write lands exactly where a Game Boy puts it — which means a one-dot timing bug lands exactly there too, and gets caught.

The two are not a quality or an appearance setting. On ordinary games they produce byte-identical framebuffers — verified across 600 frames of dmg-acid2 plus Blargg's cpu_instrs. The only axis between them is exactness against speed:

The accurate engine costs roughly four times as much per frame — 0.373 ms against 0.094 ms, still only a couple of percent of a frame's budget on a desktop core. That is cheap enough to be the default, and it is: identical has been the shipping default since it stopped losing accuracy rows the fast engine kept. But four times the cost is not free everywhere. On the PSP frontend, where the CPU budget is tight, the emulator deliberately pins standard — an unplayable-but-exact picture helps no one.

That is the whole reason the split exists. The fast engine is what makes the emulator usable on modest hardware; the accurate engine is what makes a bug like this one findable. Ship only the fast one and the double-speed stripe would still be on screen, unmeasured and unfixed, because nothing in the pipeline would ever have looked closely enough to see it.