JN Engine

Tags follow the project's own discipline and are never promoted: Confirmed observed in a file or binary · Reported a log or a person said so · Inferred reasoned, with a stated falsifier · Contradicted sources disagree.

What it genuinely does

The engine parses the original's asset containers end to end — 0MF2 canvases, .gam property bags, task tables, Granny meshes for the sequel — and reimplements the gameplay layer in C. One codebase builds a native Linux game, a WebAssembly demo, and a replay renderer that plays back the original's captured D3D7 command stream verbatim. Level 1 of Boy Genius renders faithfully against that capture; the sequel runs with 22 levels.

The parts that work best are the un-fakeable ones. A linkage-certificate gate refuses to mark a class linked without a green headless oracle proving the ported behaviour matches the recovered decompiled body. A review pass mutation-tested every certified oracle and all eight then-certified oracles went red under a native-side perturbation. CI runs on a fresh Ubuntu host with no secrets, no XP box and no GPU, and a deliberate-regression pull request was used to prove the gate goes red.

What it does not do — stated by the project itself

• No decompilation-to-source of OMT2.dll. The engine is reimplemented, not ported.
• No automated re-derivation of specs from the binary. Spec authoring is model work, reviewed as prose.
• No capture without the Windows XP machine and a person at the keyboard.

The audit asked one question: where can a wrong claim enter this project, and what would catch it? It read repos, session transcripts, git history and on-disk artifacts across three machines, tagged every claim with its provenance, and refused to promote a tag because an earlier session sounded confident.

It produced 712 tagged findings, then re-opened every single cited file to check the citation resolved, the line range existed, and the claim's distinctive tokens actually appeared there. 377 confirmed claims re-checked, 376 verified, one downgraded — 99.7%. It also catalogued fifteen distinct ways an unverified claim can enter and survive, each with a real observed instance rather than a hypothetical.

The finding that is the whole audit in one story

In late May a session wrote a findings document with headline numbers — 94% high-tier reproduction, 119/122 mesh agreement, 139 static coverage. Re-running the validator shipped in the same commit produces 1/70, 3/122, 94. The prose never matched its own code's output. The operator caught it by reading a number that felt wrong, and a second session independently reproduced the catch and overwrote the file with honest figures.

That is the good half. The bad half is that the correction landed where the error was made and nowhere else. The fabricated figure is still live today in the two documents the project tells every new contributor and agent to read first — and, as this session confirmed, on the published branch as well as locally. Worse, the same sentence welds the hallucinated statistic to a parsing rule, and both were then promoted into a “do not relitigate these” invariant list. A rule forbidding re-examination was applied to a claim that had never been examined.

A mechanical checker now compares every spec's Identity block against three independent sources the project already generates: the .gam property schema, the class-id registrar scan, and the engine's own native binding table. Then, for every disagreement, the registrar function is disassembled out of Neutron.exe and its installed vtable addresses are matched against the spec's own.

Fifteen specs declare their FourCC “not resolved; not a .gam-placed object” when the project's own generated data resolves it. Two state an outright wrong one. Twelve of the seventeen describe classes that are placed in shipped levels — 180 instances and 272 harvested properties described by their own spec as absent — and twelve are simultaneously bound to a native vtable in the engine. Every one of the seventeen also states, in its Validation section, that there was nothing to cross-check.

Seven of seventeen shown. Five more rows describe classes with zero shipped instances, where only the “not resolved” half of the claim is false.

All seventeen come from one resolver

The generator resolves a class's FourCC in three branches, and each one leaks:

1. A case-sensitive dictionary lookup, built only from the property schema. The schema stores Ghidra's captured name in upper case — C3DEYE — while the key is C3DEye. Fourteen classes differ from their schema entry by case alone. The answer sits two lines away and is missed.
2. A regex for a class-id immediate in decompiled text, which only fires when the decompiler happened to print one.
3. A nearest-preceding-registrar-within-0x800 address heuristic with no identity check at all. This is what handed C3DDarwinFish the id belonging to C3DDino, and C3DSparrow the id belonging to level 5.

And a fourth mechanism is pure omission: the registrar loader reads only two columns of the class-id scan — the FourCC and the function address. That file's class-name column, which spells out C3DCorona(), C3DGRILL, C3DPASSCARD, C3DSmokePuff() in plain text, is never read.

Of the 49 specs that state a FourCC at all, only 21 could have come from the identity-checked branch. Sixteen of the remaining 28 turn out right anyway, eleven are corroborated by nothing in the repo, and one is wrong.

A second, softer count: 29 specs (13.9%) state “no .gam properties to cross-check” while the schema held 627 property rows across 617 shipped instances for their FourCC. The narrow reading may be true; the sentence still declares validation impossible when the data was sitting in a generated file in the same directory.

The plan proposed decompiling “the OMediaWin* CPU rasterisation path” in OMT2.dll as a second ground truth for rendering questions. There is no such path. The thirteen OMediaWin* classes are the Win32 platform layer — window, input, keyboard, sound, video engine, file and memory helpers. There is no OMediaWinRenderer, OMediaWinRenderPort, or OMediaWinCanvas. Anyone executing the plan as written would have spent the effort decompiling windowing and sound.

The software renderer is the OMediaOMT* family, sitting over OMediaPipeline and the segment rasterizers. And the shipped exe pair gives up nothing: Neutron.exe and NeutronSW.exe import byte-identical sets from all four DLLs and have identical string sets — 3,416 each, zero difference either way. There is no import-table boundary to isolate. Renderer selection happens inside the DLL, at a single factory call, switching on an engine id between the DirectX renderer and the software one.

A note on a number the audit carried: the “52% of bytes differ” figure between the two exes is real, but it measures code shifting, not code change. The text sections differ by 16 bytes in size and the delta shows up as 41,846 runs, mostly one byte long.

The invariants, checked against the engine's own source

Two results are worth more than a checkmark. The fog invariant gets stronger: it is not a property of one capture, it is a property of the engine — fog was never implemented on the Windows path, so adding fog to “fix edges” would be adding something the original never had.

And the culling explanation is simply wrong. OMediaPipeline is referenced by the software renderer and by nothing else, so it cannot explain what a Direct3D 7 capture recorded. In the DirectX path culling starts on and is toggled by a two-sided flag plus an unconditional disable in the canvas-element render path. The observation stands and the practical fix stands — only the reason written next to it is wrong.

One genuine backend divergence surfaced, offered as Inferred with its falsifier: the projection fast path never reads m[3][3], so the software pipeline computes w = z while D3D, handed the same matrix, computes w = z + 1. Negligible at gameplay depths, which is presumably why nobody noticed in twenty-four years.

The binaries date themselves

Reading PE timestamps directly settles a three-way disagreement in the docs. Neutron.exe was linked 2001-09-30 01:07:40 UTC; NeutronSW.exe seventy-nine seconds later, from the same object-file population — the Rich header component counts are identical, which is what a compile-time variant of one source tree looks like. The toolchain is MSVC 6.0 RTM, reproduced independently of the earlier session that claimed it.

This dates the build. A PE header cannot settle a retail street date, so the docs' “THQ, 2002” is not necessarily wrong — but three documents say 2002 without saying which they mean, and the stray “2003” elsewhere belongs to the toolkit's open-source release, not the game.

The three shipped OMT2.dll builds — one per title, spanning thirteen months — export the same 1,358 names in the same ordinal order, with zero ordinals carrying a different name in any pairwise comparison, while only 23, 6 and 5 of 1,358 export addresses coincide. One API, three builds of an evolving tree. They are not interchangeable: two import DINPUT8, the third imports DINPUT.

Hot Wheels Mechanix ships no placement data

Work on this sibling title — another of awefan's maintained efforts, with its own RE workbench — was paused in June on the theory that its missing .gam files were an extraction artifact. They are not. The disc's uncompressed installer header lists exactly 44 files — 36 asset containers, two executables, three DLLs, two small data files and a readme. A raw scan of the entire 91 MB disc image finds zero .gam filenames while finding 36 .omt and 294 .png references.

The manifest and the already-extracted install tree match 44 for 44. The June extraction was complete; re-extracting could only reproduce the same files. Placement is compiled: of the 32 call sites of the game's class factory, 29 pass a literal four-character id as an immediate. The .gam toolchain does not transfer to this title because there is nothing for it to parse.

The loose ends

• LiveThe retracted 94% is still in both entry-point documents — and confirmed present on the published branch, not just locally. A four-line documentation patch is drafted and deliberately not applied.
• ClosedThe Operation Krabby Patty Ghidra project sitting on this machine is one unrecorded hour — created 2026-08-10, one binary imported, nothing exported, and no link to the maintained effort or to any ledger row here. Its engine is confirmed not the toolkit: the disc carries 19 PowerRender object files and zero toolkit fingerprints, so nothing in the OMT toolchain transfers to it.
• ClosedThe 68 GB XP backup does not contain the game and never did — 164,913 listed paths, zero hits for any game artifact. It is a family PC image. The recovery guide's claim that it “very likely holds the original binaries” is wrong; they are elsewhere on the same drive.
• ClosedThe planned tooling entry tracked as a project has no design document. Its entire basis is one sentence in one conversation.
• NarrowedThe audit brief's own authorship is still unnamed, but pinned: it arrived as a downloaded file two minutes before the session that executed it. No exported conversation covers the window at all — the chat archive stops eleven days earlier.

Every claim on this page resolves to a file and a line, or to an offset in a binary. The tooling is re-runnable and needs no network, no Ghidra and no XP machine — a dependency-free PE reader plus objdump covers all of it.

Nothing was edited to produce this report. No spec was corrected, no document was patched, and the disc image was not re-extracted — the uncompressed manifest already settled the question and a re-extraction could only reproduce the same 44 files. Said plainly so it is not mistaken for coverage.