mirror of
https://github.com/RetroPortingToolKit/psxrecomp
synced 2026-10-28 02:56:36 -04:00
Alex Vanderveen
498a0fe45f
The report contradicted itself: native_sampling "free-running-fallback" AND granularity "native-measured-per-frame" in the same document — the data is aliased, and its steps are the animation increment. Both cannot be true. The guard existed and sat on a different branch than the one that fired, so the claim I said last commit could not be made was made on the very next run. Free-running samples land about ninety frames apart, so their differences are aliasing. Presenting them as an increment invites precisely the wrong conclusion — that our fade jumps by 44 — when nothing measured that. Every per-frame claim now checks the sampling method, a test asserts that for each one by reading the source, and a fallback run gets its own label saying the steps mean nothing. The other half is why the fallback ran at all. Per-frame now reports "a block leader fired but no register sample came with it", which was accurate and narrow: it insisted on the SINGLE nearest leader and threw away frames where a leader fired but the recorded sample belonged to a different one. It now takes a sample from whichever fired leader has one, nearest first — true of the frame rather than of one address. Data so far, with the caveat attached: psx-runtime 26..128, oracle 76..86, both aliased. Neither says how either one moves. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>