Three things this iteration, and the middle one is the human's doing.
P7 -- GATE MET, with an artifact. The path had been wired for some time
(then_video S00A, skipped_chain, after_video -> title, and S00A.ogv in the
export) and NOBODY HAD RUN IT. A milestone is done when its artifact exists, not
when the wiring reads correctly.
Pre-registered: unskipped, S00A is 93.78 s of media, so it should end on its own
at ~94 s and hand off to title. Measured: video ended at 94.13 s -- +0.35 s,
0.4 % -- then -> title, plate raised, script complete at 96.83 s. Both
predictions held. docs/port/p7-gate.md.
And it genuinely decodes, checked because "ends at the right time" does not prove
it: 45 frames in a 2.03 s window, 244 in an 18.91 s one. Scales with the window,
sub-linearly, at the software fill ceiling -- those two runs predate the GPU. The
counts are upper bounds and the port says so itself.
Free corroboration of the fill-rate finding, from a direction it was not designed
for: the unskipped run reports main_menu at 60.3 fps for 94 s, because the screen
never changes during a movie. Same process, same container, same screen: 60.3 fps
with one full-screen video texture on top, 9.7 fps drawing the menu's five
additive full-screen quads.
❌ THE FINDING-4 FRAME-RATE CANDIDATE IS DEAD, tested rather than argued away.
The human activated a hardware GPU in both containers; Godot takes it with no
change on our side (NVIDIA GTX 1070 Ti, Vulkan 1.4.312, Forward+):
publisher_logo 17.3-25.0 -> 69.4 fps
developer_logos 16.7-22.8 -> 69.1
title 12.7-17.2 -> 61.1
main_menu 9.7 -> 59.6
Pre-registered that 5-7 full-screen textured quads at 720p is trivial for that
card and the fade would get its full 45 steps. At 69 fps the 45-unit build-in
gets 52 drawn steps and the companion glow's 15-unit rise gets 17 -- MORE frames
than declared units, so every declared alpha is drawn and the quantisation is
absent rather than reduced.
So every candidate for finding 4 is now dead: keyframes vindicated against the
vertex stream, companion quads drawn, blend space matching, settled pose at
0.01 %, no post-process pass, and the frame rate drawing every declared step. The
port has nothing left that is KNOWN to be wrong about the splashes -- which is a
statement about our knowledge, not about the port. The human saw something and
nothing we can measure reproduces it. The next play-test is now the
highest-value thing on this focus, and the rate line will say 60-something.
One figure did not improve: main_menu's worst gap is 117 ms on the GPU against
150 ms on llvmpipe, essentially unchanged while the mean improved 6x. A hitch
that survives a 6x fill speed-up is not fill. Likely first-frame cost, STATED AS
UNTESTED, recorded rather than chased.
check-all now asserts the display before any Godot step. Xvfb does not survive a
container restart and LEAVES ITS SOCKET BEHIND, so Godot reports "X11 Display is
not available", falls back to Wayland, fails that too, and exits non-zero -- and
every Godot-backed step would have gone red for that one reason. Cost me one run
before I noticed. Checked with xdpyinfo rather than by looking for the socket,
because the stale socket is what makes it confusing.
Also recorded from the P7 run, neither chased: Godot reports 4 leaked ObjectDB
instances at exit on that path, and the menu bed keeps playing under the movie
(already an open ask -- does the menu music duck?).
Not settled: the 117 ms menu hitch; H6's +0x04 exposure; H1 (with the Decoder);
the four red verify-screen rows; and what the human actually saw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
ba3f490c67