2 Commits

Author	SHA1	Message	Date
Sylpheed port agent	08ed3dd17e	port: the splash never animated -- pose_at ASSIGNED the settle instant instead of clamping to it ... The 2026-09-02 play-test: "the logos just switch, I cannot discern any animation at all." Reproduced, diagnosed, fixed, and gated by a film. REPRODUCED FIRST, as instructed. tools/motion-census needed Pillow, which this container has no pip for, so it got an ImageMagick fallback that shims only the four Pillow calls it uses -- the census arithmetic, the MOVED floor and the GRID are untouched. Its --selftest passes on that backend with the human's own numbers: fade 97.4 %, switch 2.6 %, frozen 0.0 %. A shim that distorted pixels would fail its own control. publisher 0.30 s moving then 3.30 s FROZEN (human: 0.30 then 3.20) developer 0.40 + 0.25 split then 2.45 FROZEN (human: 0.35 + 0.25 then 2.40) Matched to within a frame. THE CLOCK WAS NEVER THE PROBLEM. view_units advances 2.8-3.0 per frame, smooth, ~60 units/s, no stalls -- the play-test's candidate list can drop "the group clock not integrating" and "advancing by keyframe index". THE POSE WAS. Measuring the sharp logo's own rect frame by frame: 0.40549 flat from unit 7.9 through 28.2 -- the same value it holds at 45 and beyond. It was already FULL before its declared ramp (15 -> 30) began. Cause, in ScreenView.pose_at: t = settle_instant if settle_instant >= 0.0 else minf(t, settle_units(element)) The comment above it says "stop at the hold". The else-branch clamps. This half ASSIGNS, so from a screen's first frame every element was posed at the settled instant and no build-in was ever drawn. The asymmetry is the whole defect, and `--time` sets `frozen`, which skips the clamp -- which is exactly why my frozen sweep "proved" the companions were drawn and proved nothing about running. Fix: `minf(t, settle_instant)`. One operator. ⚠️ AND THE HOLD IS NOT THE BUG. The Decoder measured the game holding one picture for 3.34 s on this screen -- LONGER than the port's 3.30 -- because palogo_sqex declares 205 of its 255 units as a flat plateau. The play-test's "a fade does not hold one picture for 3.20 s" would have sent me to delete the one correct part. Clamping keeps the plateau exactly. GATED BY A FILM, not a still: before after game (Decoder) publisher build-in 0.30 s 0.60 s developer build-in 0.40+0.25 0.95 s continuous splash moving 12.0 % 24.8 % 21.2 % / 27.8 % distinct luma states 120 152 longest frozen 3.30 s 3.30 s 3.34 s 🔴 AND IT LOOKED LIKE A 10x REGRESSION AGAINST THE ORACLE, WHICH IT WAS NOT. verify-capture went publisher 2.17 -> 22.58, title 14.11 -> 67.07. Cause: it shoots two frames after load and got the settled pose ONLY because pose_at assigned it. Its own comment says so -- "the 0.01 % agreements on both splashes were measured through that accident." So the `--screen --capture` path now advances the clock to the settle instant explicitly before shooting, which is what the tool was always asking for. Guarded on `not _frozen`: `--time` means the caller wants THAT instant, and overriding it would reintroduce the silent-ignore this replaces. Every oracle row is back to its pre-fix value to the digit: publisher 2.17 (0.01 %), developer 3.05 (0.01 %), title 14.11, main_menu 13.02, extras 13.10, title_plate 13.04. The port animates AND still matches the settled captures. Not settled: motion-census is not yet wired into check-all -- next, and deliberately not rushed at the end of a long iteration. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX	2026-09-02 15:38:41 +00:00
MechaCat02	3cc3400a96	agents: the splash does not animate, and three instruments could not see it ... A human on a GPU at ~140 fps: "the logos just switch, there is no animation at all." Measured from a real boot with --film at 0.05 s, then per-frame change: splash moves 1.30 s of 7.95 s = 16.4 % publisher splash 0.30 s of motion, then 3.20 s FROZEN developer splash 0.35 s + 0.25 s, then 2.40 s FROZEN distinct luma states in 7.95 s 26 A 45-unit build-in cannot be drawn in 26 states, and a fade does not hold one picture for 3.20 s. The frame counter says 24.8 fps achieved; both are true -- the port is DRAWING 25 times a second and CHANGING almost never. 🔴 Why every check passed, which matters more than the bug: frozen sweep drives the clock BY HAND -- proves the renderer can draw pose N, never that the poses are drawn in sequence settled compare 0.01 % against the capture -- a screen frozen 84 % of the time matches a settled reference PERFECTLY, that is what frozen means achieved fps counts frames DRAWN -- the same pixels 25x/s scores identically to animating Every one measured throughput or a pose. None measured CHANGE. Same shape as InputEventAction bypassing the input map: the instrument sat below the thing that was broken, so the break could not appear in it. tools/motion-census closes the class. It measures change and nothing else, and its --selftest asserts it separates a fade (97.4 % moving) from a switch (2.6 %) from a frozen film (0.0 %) -- a detector that cannot tell those apart would report the same green line on all three. Both briefs: this is the SOLE focus. The port reproduces before changing anything and gates every fix on a film rather than a still. The decoder maps the whole pipeline end to end -- disc bytes, the game's per-frame update (does it interpolate between keyframes or hold?), what is submitted per frame, and what Canary does to it before a capture records it -- delivered as a SERIES, not a settled value. The port should also record the refutation against itself: H2 reads ANSWERED on the strength of the frozen sweep. The mechanism half stands, the blur is a baked companion texture. The behaviour half does not.	2026-09-02 17:24:42 +02:00