The --framerate_limit=30 run refuted the time-based reading on every
discriminating row, against its author's own expectation: modal alpha step stayed
17 where time-based predicts 34, units/second halved to 30.2, the publisher dwell
doubled to 8.450 s. Both controls passed FIRST -- the limiter demonstrably took
effect, and all 8 splash quad rects were identical, so nothing but the frame rate
differed. 255 x 1 / 15 = 17 at 28.4, 51.4 and 54.8 presents/s alike.
THE GAME ADVANCES 1 UNIT PER PRESENTED FRAME. This port advances
`time_units += delta * units_per_second`. Two different mechanisms that agree at
exactly one frame rate -- 60 Hz, the only rate the console ever asked the game to
be right at.
🔴 DO NOT MAKE THE PORT FRAME-BASED TO MATCH THE GAME, and the reason is now in
authored/timing.json so nobody "fixes" it. A time-based port reproduces a 60 Hz
console on hardware that is not 60 Hz; a frame-based one drifts on every machine
that is not -- and this port has measured ITSELF between 9.7 and 69.4 fps
depending on the renderer. Matching the game's mechanism would import a fragility
the game never had to survive, because the game only ever ran on one box.
⚠️ BUT IT SHARPENS WHAT 60 CLAIMS. If units/second IS the present rate, then
`keyframe_units_per_second = 60` is no longer "the unit is 1/60 s". It is "the
game presented these screens at 60 Hz on the console" -- a harder statement, and
checkable.
✅ And supported for the first time. Canary unlimited presents at 51-55 Hz with a
splash dwell of 4.30/4.60/4.37 s. A natively 30 Hz game would present at ~30 in
Canary too -- the framerate_limit run proves it, since forcing 30 made that same
splash take 8.45 s. It does not take 8.45 s unforced. So the game asks for ~60.
Kept as `authored`, not promoted: this is inference over three measurements
rather than a measurement of units per second. It becomes `measured` when someone
reads the console's present rate for these screens directly.
🔴 AND IT CLOSES THE CONSTANT AS A CAUSE OF FINDING 3, in the direction that
matters. Under the frame-based model the only alternative is a 30 Hz console,
which puts the plate at 236/30 = 7.87 s -- LATER than the 3.93 s shipping, not
earlier. There is NO console present rate that makes the plate arrive sooner than
this port already shows it. The human reported it late; no value of this constant
can produce that.
The method note is theirs and it is the durable part: four positions on this
number were inference over a measured quantity; this one changed an input and
watched what moved. The opportunistic comparison -- two captures that happened to
differ -- pointed exactly the wrong way, because nothing controlled what else
differed between them. One designed capture settled it against its author's
expectation.
Not settled: finding 3, still with no surviving cause; the clock origin, which
they are taking next and which every ratio and count in this account survives;
the ~1.0-1.2 menu residual; the allowance's grep trigger.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
15702d0d05