From 3cb9298e5d341801dc014bf423136e8c6b257d5d Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 20:53:08 +0000 Subject: [PATCH] re: the loop records decode -- and they are not what I measured Two of my own claims from last iteration die here, and the decode is the thing that kills them. Searching for the SHAPE instead of an assumed count found it immediately: fade words matching 0x??ffffff at alternating strides of 24 and 16, which is a 40-byte block carrying fade at +0 and tint at +24 -- exactly the build layout, starting at +0x68. So "a leaf record's keyframes are not in the build's 40-byte layout" is withdrawn. They are. My scan failed because I demanded 29 strictly-increasing times, having read the word at +0x004 as a keyframe count; the records hold THREE. Decoded, both are horizontal light sweeps. ptloop01 runs pteff03.t32 from x=-639 to x=1521 over t=150..600, which is 450 units or 7.5 s; ptloop02 runs pteff03a.t32 the other way over 570 units or 9.5 s. Which refutes the second thing. Last iteration I attributed the measured 2.2 s oscillation to these elements because build 4 declares them -- association, not evidence. A 7.5 s cycle would give about three peaks in a 22 s capture and I counted eight. So the loops are not what I measured, the 2.2 s stands as a measurement, and its source is now explicitly unidentified rather than wrongly assigned. METHOD gets the general form, because it is what cost the previous iteration: do not hard-code an expected element count into a structure scan. Scan for the shape and let the count fall out. --- docs/re/METHOD.md | 6 ++++ docs/re/REFUTED.md | 11 ++++--- docs/re/ui-title-build-map.md | 54 ++++++++++++++++++++--------------- 3 files changed, 44 insertions(+), 27 deletions(-) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index a1a6694d..b5869ff4 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -249,3 +249,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the second is the intro movie's own opening frame. Reading the capture alone gives "three logo screens". Cross-check a repeat against what is *supposed* to be playing at that moment before counting it as its own screen. +* **Do not hard-code an expected element count into a structure scan.** Looking + for a `.rat` record's keyframes, I required 29 strictly-increasing times because + a header word read `30`. The records hold **three** keyframes in exactly the + layout I was testing for, and the over-constrained filter reported the layout as + refuted. Scan for the *shape* (here: `0x??ffffff` fade words at a constant + stride) and let the count fall out. diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index 07052de7..9315ccfe 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -35,10 +35,13 @@ neighbourhood, not just the line. ## Screens, classes and RTTI -* "a `.rat` leaf record's keyframes use the build's 40-byte placement-block - layout (time at `+36`)" → they do not. A strided monotonic scan over - `ptloop01.rat`/`ptloop02.rat` finds no increasing time sequence at any aligned - start. [`ui-title-build-map.md`](ui-title-build-map.md) +* ~~"a `.rat` leaf record's keyframes use the build's 40-byte layout" → they do + not~~ — **withdrawn.** They do. The scan that "found nothing" required 29 + increasing times; the records hold **three**. Decoded in + [`ui-title-build-map.md`](ui-title-build-map.md). +* "the title's measured ≈ 2.2 s oscillation is the `ptloop01`/`ptloop02` + elements" → **mine, and refuted by decoding them.** Their sweeps run 7.5 s and + 9.5 s; a 22 s capture showed 8 peaks, not 3. The period's source is unidentified. * "the developer splash cannot be rendered by `screen render` at all" → it can, with **`--all`**. It is only invisible to the *default* listing, which filters on `is_build`. [`ui-title-build-map.md`](ui-title-build-map.md) diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md index 6602958d..e35c81c6 100644 --- a/docs/re/ui-title-build-map.md +++ b/docs/re/ui-title-build-map.md @@ -220,36 +220,44 @@ composition ([`INDEX.md`](INDEX.md), UI screen layout row). So the title carries looping element by construction; what is new is that it runs at ≈ 2.2 s and never stops. -### ❔ The loop record was opened, and its cycle is still not readable +### ✅ The loop records ARE decoded — and they are not what I measured -The `.rat` was located and partly confirmed, but its **keyframe times are not**. +`ptloop01.rat` is an **`opt `-linked leaf record**: in build 4 the chunk `opt ` +(size `0x0c`) carries the name, immediately followed by a `RATC` blob at +**`0xbb5966`** (`ptloop02.rat` the same at `0xbb5a82`). Its pivot fields read +`200`/`90`, matching `screen info`'s `pivot (200,90)` — the right blob. -`ptloop01.rat` is an **`opt `-linked leaf record**, not a nested build: in build 4 -the chunk `opt ` (size `0x0c`) carries the name `ptloop01.rat`, immediately -followed by a `RATC` blob at **`0xbb5966`**. `ptloop02.rat` is the same shape at -`0xbb5a82`. +**The keyframes use the ordinary 40-byte block layout**, starting at `+0x68`: -| offset | value | | +| | `ptloop01` → `pteff03.t32` | `ptloop02` → `pteff03a.t32` | |---|---|---| -| `+0x004` | `0x001e0000` — **30** in the high half | the ~30 keyframes [`structures/ui-rat-layout.md`](structures/ui-rat-layout.md) predicts | -| `+0x014` | `1` | name count | -| `+0x018` / `+0x01c` | `1280` / `720` | design space | -| `+0x020` | `pteff03.t32` (`pteff03a.t32` for loop02) | the sprite it places | -| `+0x050` / `+0x054` | `200` / `90` | pivot — **matches `screen info`'s `pivot (200,90)` for `ptloop01`**, which confirms this is the right record | +| kf0 | `t=150` x=**−639** α=`ff` | `t=150` x=**1721** α=`00` | +| kf1 | `t=540` x=−39 α=`80` | `t=630` x=1111 α=`80` | +| kf2 | `t=600` x=**1521** α=`ff` | `t=720` x=**−839** α=`ff` | +| scale | 100 × 600 | 100 × 800 | +| span | 150 → 600 = **450 units = 7.5 s** | 150 → 720 = **570 units = 9.5 s** | -**But the times are not where a build's are.** A build's keyframes are 40-byte -blocks with the time at `+36`. Scanning every 4-byte-aligned start across -`+0x60 … +0x120` for 29 strictly-increasing values at a 40-byte stride finds -**nothing**, in either record. So a leaf record's keyframe layout is *not* the -build placement layout, and the loop's declared cycle cannot be read by that -route. +Y is constant at 270 and X runs off one edge to the other, so these are +**horizontal light sweeps** — `loop01` left → right, `loop02` right → left. -**The ≈ 2.2 s therefore stays measured, not decoded.** What a future attempt -gains from this one is the record's address, the confirmed pivot, and one layout -ruled out. +### 🔴 Two things I wrote last iteration are wrong -**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. +**1. "A leaf record's keyframes are not in the build's 40-byte layout."** +Withdrawn — they are, exactly. The scan that "found nothing" demanded **29** +strictly-increasing times because I read the word at `+0x004` (`0x001e0000`) as a +keyframe count. These records hold **three** keyframes. A filter that hard-codes +the expected count rejects the right structure; whatever the `30` is, it is not +the number of keyframes here. + +**2. "The ≈ 2.2 s oscillation is the `ptloop` elements."** Withdrawn — I asserted +the link because build 4 declares those elements, not because anything showed it. +The decoded sweeps run **7.5 s and 9.5 s**. A 22 s capture would show ~3 peaks +from a 7.5 s cycle; it showed **8**. So the loops are *not* what the oscillation +measured. + +❔ **What the ≈ 2.2 s period actually is remains unidentified.** Candidates not +checked: `pteff01.t32` (`[50 71 118]`), the five `ptlogo_back2eff*` glows, or a +combination. The measurement stands; only its attribution is withdrawn. ### ❔ The declared 4.08 s build-in was not tested