mirror of
https://github.com/RetroPortingToolKit/psxrecomp
synced 2026-10-28 19:07:47 -04:00
Alex Vanderveen
b2a33b21ca
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>