Asked whether the bug can be fixed now. Not yet — there is a symptom and no
cause, and guessing at this point would join the six hypotheses already dead.
But the captured lists narrow it further without touching an emulator. For
PolyG3+semi|B+F:
strides psx-runtime [28, 2332] oracle [28, 1052, 2332]
range 0x10D05C..0x10DCC0 0x10D0AC..0x10FD48
colours (30,0,0) (24,0,30) dark (47,23,0) (127,55,0) bright orange
28 is one packet, so those are contiguous runs. The oracle has a THIRD group
the runtime does not — the 1052 stride — and builds it in a byte range the
runtime never touches. The colours differ in character too: dark red/blue
against bright red/green, which is what the screenshots show as missing orbs.
So the census now records the address span each class is built in, and when a
class is systematically absent it names the region the oracle uses and the
runtime does not. That converts "short by 258 primitives" into an address range
to point range_writers at: if nothing on psx-runtime writes there, that is
where they are lost, and the code that should have written it is the fix site.
Still a single capture, so still to be confirmed by the census itself — phase
can hide a group in one frame, not in forty.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Looked at the two screenshots properly for the first time. The oracle draws a
dark scene with two bright glowing orbs and a green artifact on the landmass.
psx-runtime draws the same landmass, uniformly bright orange, with no orbs and
no artifact. That is the reported symptom verbatim — "it stops rendering the
artifact" — and it is not a glow rendered wrongly, it is objects that are not
there.
Which sends the class-count difference from a very different angle. Every class
matches exactly except two, and both are additive:
PolyG3+semi|B+F 32 against 290 -258
PolyFT4+semi|B+F 0 against 30 -30
Additive gouraud triangles and additive textured quads: exactly what draws
glowing orbs and a shimmering artifact. I saw this difference earlier and
attributed it to animation phase, because a single capture from each side
cannot tell "does not draw it" from "was not drawing it just then".
class_census removes that ambiguity by comparing MAXIMA over many captures.
Phase can hide a primitive in one frame; it cannot hide it in forty. If
psx-runtime never once reaches a count the oracle routinely shows, "not just
then" stops being an available explanation.
Deliberately symmetric: a class the ORACLE never reaches is reported as its own
finding rather than as the expected one, and a floor keeps single-digit jitter
(PolyFT3 at 4 against 6) out of the verdict.
If this confirms, the fault is in the guest code that BUILDS those primitives —
which the renderer results have been pointing away from all along, and which
explains why every renderer-side hypothesis died.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alex Vanderveen