TEMPORAL-VERIFICATION §1 requires every instrument to state its achieved rate
against its requested one. That has been applied to --film (which I fixed for
exactly this), to the Decoder's harnesses and to the oracle. It had never once
been applied to the thing being shipped. The port had no idea what rate it drew
at and no way to say.
It matters now because the splashes are the focus and the open complaint is that
ours is LESS PRONOUNCED than the game's. A fade drawn in 45 frames and the same
fade drawn in 12 are different animations, and nothing here could tell them
apart.
boot.gd now counts frames per screen and reports at every boot transition, at the
end of the boot, and at every menu arrival. `worst gap` sits beside the mean
because a hitch is what reads as wrong and a mean hides one by construction.
Measured in this container, three boots:
publisher_logo 17.3 / 19.6 / 25.0 fps worst gap 100-115 ms
developer_logos 16.7 / 21.9 / 22.8 fps worst gap 103-138 ms
title 17.2 / 14.2 / 12.7 fps worst gap 150 ms, all three
main_menu 9.7 fps worst gap 150 ms
🟡 A LIVE CANDIDATE FOR PLAY-TEST FINDING 4, and the first one that is not dead.
The timeline is delta-driven so durations stay correct at any rate; what changes
is how many alphas the fade is DRAWN at. At the measured rates the 45-unit
build-in gets 12-17 distinct alphas instead of 45, and the pre-blurred companion
glow -- the thing that IS the splash's blur -- rises over 15 units and is drawn
at FOUR TO SIX steps instead of fifteen.
⚠️ It is a candidate, not a cause: this is llvmpipe under Xvfb and not the
human's hardware. The point is that the line now prints on every boot, so the
next play-test answers it for free. Every other candidate for finding 4 is
already dead -- keyframes vindicated against the vertex stream, companion quads
drawn, blend space matching, settled pose at 0.01 % against the capture, no
post-process pass to add.
✅ And nothing published is invalidated, which was worth checking rather than
assuming: every timing result here comes from `_elapsed` (+= delta) or
`time_units` (the same sum scaled), so all are correct at any frame rate. The
splash dwells were measured across runs whose rates differed by 2x and agreed to
±0.03 s. Had the timeline been frame-counted, every number in this corpus would
have been wrong by a factor that changed between runs -- which is precisely the
failure the Decoder found in the emulator's rate and withdrew a finding over.
Two defects in the instrument itself, both caught and fixed before it was
trusted:
- its first version printed "-9223372036854775808 requested".
DisplayServer.screen_get_refresh_rate() returns a FLOAT and is -1.0 when the
display cannot say, which Xvfb cannot, and %d underflows to INT64_MIN. It
now names the cap or says `uncapped`.
- it was BOOT-ONLY and said so nowhere -- `--menu` arrives through
_menu_arrive, not _advance, so the mode a human spends time in reported
nothing. That is the shape this port keeps finding in other people's work,
and it lasted one measurement here.
Refutation attempt: I checked whether the port re-decodes PNGs per frame, which
would have been a real defect. It does not -- _load_textures caches at
load_screen. Hypothesis dead, cheaply, and recorded.
Not settled: what rate the human's machine manages; whether 9.7 fps on the menu
is llvmpipe or something in our draw path; H6's +0x04 exposure; H1 (the Decoder
is taking it this iteration).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
170d255e82