From dcf2090d0f08293547dae5872ff49ccb753053f8 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 21:05:35 +0000 Subject: [PATCH] re: build 4 captured without the plate, and keyframe groups hold rather than loop The port agent ranked a plate-free capture of build 4 above any further static RE, so that came first. B from the main menu returns to the title and the plate fades in a beat later, which opens a clean window. Recorded at 20 fps from the press: the art appears at 1.10 s, builds in to 3.70 s, sits settled and unobstructed until 5.00 s, and the plate arrives at 5.10 s -- the band jumps from 282 to 3755 bright pixels. Committed the frame at 4.0 s as the reference for the cyan glow slab they report drawing and the game not having. Their other sub-question -- whether a keyframe group loops or holds -- falls out of the decoded sweeps plus a measurement I already had, and the two agree. ptloop01's final keyframe parks pteff03.t32 at x=1521 and ptloop02's parks pteff03a.t32 at x=-839, both off-screen on a 1280-wide design; and over 18 s of settled title the centre tiles sit at sd <= 0.01 when a looping group would recross the screen every 7.5 s. So groups HOLD at the last keyframe. The loop*.rat name is misleading. Also recorded, in the corpus rather than only in their report: the rest_plateau bug, with their exact identifying condition -- the final untimed keyframe has the same pose as the last timed one -- the six elements it misses on main_menu, and the bracket it drops. That closes an open question ui-paint-order-key.md has carried for a while about ptframe1 and ptframe2 resting at alpha 0 while the capture shows the frame plainly. Same two elements, same cause. Not fixed yet; the change is in ui_layout's rest(). And a METHOD line I would not have written myself: two renderers agreeing is not evidence the field is right. Their composite and screen render matched to 3/255 on main_menu and both omitted two elements the game draws, because both read one field through one decoder. --- docs/re/METHOD.md | 7 +++++ docs/re/structures/ui-resting-pose.md | 34 ++++++++++++++++++++++++ docs/re/ui-title-build-map.md | 37 +++++++++++++++++++++++++++ 3 files changed, 78 insertions(+) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 01058ee7..1b679468 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -261,3 +261,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the finding landed in `docs/re/` while the page the port agent reads kept the stale version. The commit's file count is the tell: if it is one short, an edit was silently dropped. +* **Two renderers agreeing is not evidence the field is right.** The port's + composite and `sylpheed-cli screen render` matched on `main_menu` to 3/255 — + and *both* omitted two elements the game draws, because both read one field + through one decoder. Agreement between consumers of the same decode measures + the decode's determinism, not its truth. Only a framebuffer capture is an + independent check. (Reported by the port agent, 2026-08-28, after a capture + crop found the missing bracket.) diff --git a/docs/re/structures/ui-resting-pose.md b/docs/re/structures/ui-resting-pose.md index 40faa096..4f025173 100644 --- a/docs/re/structures/ui-resting-pose.md +++ b/docs/re/structures/ui-resting-pose.md @@ -153,3 +153,37 @@ invisible — in the literal sense — until `fade` is applied. 0 and never hold at a visible value, so the plateau rule rests them at alpha 0 — invisible. That is *probably* right for a settled screen, but the capture cannot confirm it while `fade` is unapplied. + + +## 🔴 `rest_plateau` is wrong for elements with no exit animation (2026-08-28) + +Reported by the port agent with a capture that proves it, and it affects +`sylpheed-cli screen render` too — this is not only a port concern. + +`rest_plateau` drops a trailing run of identical keyframes because that run is +normally the **exit** animation. On an element that has **no exit**, the trailing +run *is* the hold, and dropping it puts the element back at its **first** +keyframe — off-position and transparent. + +**The condition that identifies these exactly** (no false positives across the +port's whole export): + +> the final untimed keyframe has the same pose as the last timed one + +**Six elements** on `main_menu` match it and `rest()` misses all six. The +visible cost: on `main_menu` the timeline render and the `rest` render differ in +exactly one region — **400 × 470 at (440,108)**, the bounding box of `ptframe1` +and `ptframe2` and nothing else. That is the **bright circuit bracket around the +menu**, plainly present in +[`../captures/main-menu-oracle.png`](../captures/main-menu-oracle.png) and absent +from the `rest` render. Cropping the same region from the capture and from both +renders puts the ring and its elbow trace pixel-aligned with the game's in the +timeline render. + +This also explains a long-standing ❔ on +[`ui-paint-order-key.md`](ui-paint-order-key.md): *"`ptframe1`/`ptframe2` rest at +`0x00ffffff` (alpha 0) and are therefore not drawn, but the capture shows the menu +frame plainly."* Same two elements, same cause — now identified. + +❔ **Not yet fixed.** The change belongs in `ui_layout`'s `rest()`; it is a +decoder change and has not been made. diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md index 70798096..2f9b5b67 100644 --- a/docs/re/ui-title-build-map.md +++ b/docs/re/ui-title-build-map.md @@ -314,3 +314,40 @@ declared `16 → 261` (4.08 s); the two are not measuring the same thing. Testing it properly needs the title reached **without** a skip, and a way to separate the quad from the elements — neither of which this recording had. + + +## ✅ For the port: build 4 alone, and groups HOLD rather than loop + +Both answers the port agent asked for, in one recording. + +### The capture — the title with no `PRESS Ⓐ` plate over it + +Ⓑ from the main menu returns to the title and the plate fades in **a beat later**, +which opens a clean window. Recorded at 20 fps from the press: + +| | | +|---|---| +| title art appears | t ≈ 1.10 s | +| builds in | 1.10 → 3.70 s (mean 41.8 → 63.2) | +| **settled, still no plate** | **3.70 → 5.00 s** | +| plate arrives | t ≈ 5.10 s (band jumps 282 → 3 755 bright px) | + +[`live-title-build4-no-plate.png`](captures/title-builds/live-title-build4-no-plate.png) +is t = 4.0 s — build 4, settled, unobstructed. That is the reference for the +washed-out cyan glow slab the port reports drawing and the game not having. + +### ✅ A keyframe group HOLDS at its last keyframe — it does not loop + +This follows from the decoded sweeps plus a measurement, and the two agree: + +* `ptloop01.rat`'s final keyframe puts `pteff03.t32` at **x = 1521** and + `ptloop02.rat`'s puts `pteff03a.t32` at **x = −839** — both **off-screen** on a + 1280-wide design. A group that holds therefore parks both sweep sprites out of + view and nothing moves after the build-in. +* Measured: over 18 s of settled title the centre tiles sit at **sd ≤ 0.01** + (per-tile map above). A looping group would recross the screen every **7.5 s** + and be unmissable. + +So the name `loop*.rat` is misleading — in this build the records animate **once** +during the build-in and then rest off-screen. 🟡 This is about *these* groups on +*this* screen; nothing here says no group anywhere loops.