My fourth position today, and it returns to the port's.
Splash B's logo quads in this capture step +17 per present, 14 gap-free
steps, four quads agreeing. h3-units-per-frame-measured.md measured the
SAME elements at +34 and concluded 2 units per frame.
Both are right. With the declared T=15, dA/present = 255*(units/present)/T:
h3 capture 27.2 presents/s +34 2.0 units/present 54.4 units/s
this capture 51.4 presents/s +17 1.0 units/present 51.4 units/s
Units per present halved when the presentation rate doubled. Units per
second did not move. The UI clock advances by ELAPSED TIME, not by frame
count, and "2 units per frame" was a property of a capture that ran at
27 fps, never of the game.
So my 120 units/s is withdrawn: it was 2 units/present x 60 presents/s, and
the first factor is not a constant.
The movie result is re-explained rather than refuted. 2 presents per
decoded movie frame at 51.4 presents/s is a movie decoding at 25.7 fps -- a
30 fps movie at 86% under a slow emulator. The measurement held; the
inference assumed the movie decoded at 30/s in real time, which it does not
when the emulator is slow. Same shape as the first withdrawal.
60 is now positively supported rather than merely undefended. A time-based
clock is immune to dropped frames, which predicts the dwell in seconds is
stable across runs at different frame rates -- and it is, across four runs
whose present rates differ by 1.9x: 255/4.27 = 59.7 and 210/3.46 = 60.7,
both within 1% of 60.
h3-units-per-frame-measured.md's conclusion needs demoting: its measurement
stands, its law is a single-capture artefact, and it is the origin of the
constant this question has thrashed on.
Finding 3 is open again with no surviving named cause.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
73f5f57966