From 7a77740feb5bc7667f0beb31bde6f47576ab2e38 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 20:45:53 +0000 Subject: [PATCH] re: the title loops at about 2.2 s -- and the build-in test I intended did not work I set out to do for the title what worked for the splash: measure the build-in and check it against the declared keyframes. That part failed, and I am recording the failure rather than the number. It failed for two reasons, both mine. The title was reached by skipping the movie with A, which cuts to black and brings the title up on a path that may not be the normal one. And the visible rise, about 2.7 s, is a luminance curve -- which screen-transitions.md already establishes is not the fade quad's ramp. So 2.7 s neither confirms nor contradicts build 4's declared 16 -> 261, four point oh eight seconds. They are not measuring the same thing, and I have said so instead of reporting a discrepancy. What the recording did establish is worth having anyway: the title never settles. Over 22 s the mean luminance oscillates continuously, peaks at 5.6, 7.8, 10.0, 12.7, 15.2, 17.1, 19.2 and 21.3 s, mean interval 2.24 s. Marked as about 2.2 s plus or minus 0.4 rather than a precise period, because peak-picking a low-amplitude signal is coarse. The mechanism was already decoded and I did not re-derive it: build 4 declares ptloop01.rat and ptloop02.rat, and loop*.rat is a looping sprite animation rather than a composition. What is new is the period, and that it runs forever. For the port that matters -- drawing the resting pose and stopping will look wrong. Not confirmed, and flagged: that 2.2 s is the loop's OWN declared cycle. screen info prints the element's placement keyframes but not the frame count inside the .rat, and I did not open it. --- docs/port/HANDOFF.md | 7 ++++++ docs/re/ui-title-build-map.md | 41 +++++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index dcfb5439..ab255f6f 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -61,6 +61,13 @@ authored version can be deleted. this milestone changes — every screen in scope is `GP_TITLE` — but do not ship `kind == 0x3002` as a general button test. (The kind is the 4th `u32` of the 60-byte declaration entry, at `+40`.) +* **The title screen loops — it is not a still.** After building in, mean + luminance oscillates continuously at **≈ 2.2 s ± 0.4** (measured, 7 intervals + over a 22 s capture). Build 4 declares `ptloop01.rat`/`ptloop02.rat`, and + `loop*.rat` is a decoded **looping sprite animation**. Drawing the resting + pose and stopping will look wrong. ❔ Whether 2.2 s is the loop's declared + cycle is unread — `screen info` does not print the frame count inside a + `.rat`. * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the disc's real navigation structure is unknown, and `opt ` is *not* a focus link diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md index b89e4a9f..13209319 100644 --- a/docs/re/ui-title-build-map.md +++ b/docs/re/ui-title-build-map.md @@ -199,3 +199,44 @@ tools/re-capture/pad.py tap A 0.30 ``` Mind the d-pad hold — see [`METHOD.md`](METHOD.md). + +## ✅ The title is not a still image — it loops, ≈ 2.2 s + +Recording the title at 10 fps for 22 s shows the screen **never settles**. After +the build-in it oscillates by about ±0.5 in mean luminance, continuously: + +``` +peaks at 5.6 7.8 10.0 12.7 15.2 17.1 19.2 21.3 s +intervals 2.2 2.2 2.7 2.5 1.9 2.1 2.1 + mean 2.24 s +``` + +**measured**, n = 7 intervals, spread 1.9–2.7 s — peak-picking a low-amplitude +signal is coarse, so read it as **≈ 2.2 s ± 0.4**, not a precise period. + +The mechanism is already decoded: build 4 declares **`ptloop01.rat` / +`ptloop02.rat`**, and `loop*.rat` is a **looping sprite animation** rather than a +composition ([`INDEX.md`](INDEX.md), UI screen layout row). So the title carries a +looping element by construction; what is new is that it runs at ≈ 2.2 s and never +stops. + +❔ **Not confirmed:** that 2.2 s equals the loop's own declared cycle. `screen +info` prints the element's *placement* keyframes (`ptloop01` is +`[70 100 238 250]`) but not the frame count inside the `.rat`, and I did not open +it. So the period is measured, not read. + +**For the port:** drawing build 4's resting pose and stopping will look wrong — +the title has a continuous ≈ 2.2 s loop over it. + +### ❔ The declared 4.08 s build-in was not tested + +That was the intent of this recording and it did not work. The title was reached +by **skipping the movie with Ⓐ**, which cuts to black and brings the title up on a +path that may not be the normal one; and the visible rise (≈ 2.7 s, from t ≈ 0.8 +to 3.5) is a *luminance* curve, which +[`screen-transitions.md`](screen-transitions.md) already establishes is **not** +the fade quad's ramp. So ≈ 2.7 s neither confirms nor contradicts build 4's +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.