re: withdraw the eff3 explanation and the flash advice; add a calibration-free

test that refutes 105

Two claims shipped this morning are withdrawn, and the port had already acted
on one of them.

WITHDRAWN 1: "eff3 was never drawn because a 2-unit flash peak is sub-frame."
eff3's alpha is non-zero for t in (58,64), and the capture's frames 133 and 134
sit at t = 60.0 and 62.2 -- squarely inside that window, with eff2 and eff4
both drawn in the same frames. It should have been submitted and was not. The
absence is real and UNEXPLAINED; it is not sampling phase.

WITHDRAWN 2: "a port drawing all five flashes shows more sweep than the
console". No evidence behind it. The port checked against its own renderer and
found it draws them sequentially at their declared times, never more than two
at once -- which is exactly what frames 131-135 show the game doing. The
pile-up worth warning about was the rest() bug, now fixed.

Kept, at the port's request: a frame-by-frame comparison of the build-in WILL
disagree about which flash lands in which frame -- 2 units per submitted frame
against this run's 2.231 units per presented frame -- and neither side is
wrong. Without that stated, the discrepancy reads as a port defect.

Added, and stronger than the argument it replaces: a calibration-free test of
105 vs 120. The glow's draw is omitted when its alpha reaches zero, and the
smallest alpha actually submitted across 807 drawn frames is 1, so the culling
threshold is read off the data rather than assumed. Measured dark fraction
17.7% (173 of 980 settled frames); a 120-unit cycle with its declared 15-unit
hold predicts 14.4%; a 105-unit cycle predicts 2.2%. 105 is out by 8x and
would need a threshold of alpha 11 out of a peak of 80, while the capture
contains submitted draws at alpha 1..12. No frame rate, no pacing factor, no
wall clock.

Also recorded: a regression of five build-in events against their declared
times (residuals <=0.9 frames) recovers t=0 at frame 106.1 when the composite
spike, not in the fit, is frame 107 -- and that same slope makes the glow's
period imply a 114-unit cycle against a declared 120, which is unexplained.
And the vertex-alpha identity holds for the glow but does NOT generalise:
eff4 reads 255/127/254 on consecutive frames.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 20:03:48 +00:00
parent d98c8214cc
commit 311bd16ad8
4 changed files with 119 additions and 17 deletions

View File

@@ -86,9 +86,28 @@ alpha**, so the ramp can be read straight out of the guest's draw stream
* fitting the decoded ramp gives RMS 13.16 alpha levels against **38.18 for the
same ramp reversed** — the asymmetry is real and in the decoded direction.
This does not re-measure the period in seconds (the run's frame rate was not
recorded), so the falsification below stands on the corpus's wall-clock timings
rather than on this run.
### ✅ And a calibration-free test that refutes 105 outright
The measurements above still need a units-per-frame conversion. This one does not.
The glow's draw is **omitted entirely when its alpha reaches zero**, and the
smallest alpha actually submitted in 807 drawn frames is **1** — so the renderer's
culling threshold is 1, read off the data rather than assumed. The fraction of
settled frames with no glow draw is then a pure ratio within one measurement:
| | dark-frame fraction |
|---|---|
| **measured** (173 of 980 settled frames) | **17.7 %** |
| predicted by a **120**-unit cycle (15-unit dark hold) at threshold 1 | **14.4 %** |
| predicted by a **105**-unit cycle (no dark hold) at threshold 1 | **2.2 %** |
🔴 **105 is out by a factor of eight.** For a 105-unit cycle to produce 17.7 %
dark, the culling threshold would have to be **alpha 11 out of a peak of 80** — and
the capture contains submitted draws at alpha 1, 2, 3, 4, 5, 6, 7, 8, 9, 11 and 12,
which refutes any such threshold directly.
No frame rate, no pacing factor, no wall clock: the declared 15-unit dark hold is
visible in the draw stream as the frames where the game submits no draw at all.
## What this replaces