From a04891049777b4b2573a13f992f363a3888c6d3f Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 20:49:11 +0000 Subject: [PATCH] re: the loop record is located, its cycle is still not readable Continuing the one gap from last iteration -- turning the title's measured 2.2 s loop into a decoded cycle. It did not turn. The record itself is found and partly confirmed. ptloop01.rat is an opt-linked leaf RATC at 0xbb5966 in build 4, placing pteff03.t32, with 0x1e -- thirty -- in the high half of the word at +0x004, which is the ~30 keyframes ui-rat-layout.md predicts for a loop record. Its pivot fields read 200 and 90, matching exactly what screen info prints for ptloop01, so this is the right blob and the header offsets hold. The times are not there. A build's keyframes are 40-byte blocks with the time at +36; scanning every 4-byte-aligned start across a 0xC0 window for 29 strictly increasing values at that stride finds nothing, in either loop record. So a leaf record's keyframe layout is NOT the build placement layout, which is now a line in REFUTED because it is the obvious first assumption and it is wrong. The 2.2 s stays measured and the port hardcodes it. What the next attempt inherits is the record's address, a confirmed pivot, and one layout ruled out -- which is the useful part of a negative. --- docs/re/REFUTED.md | 4 ++++ docs/re/ui-title-build-map.md | 31 +++++++++++++++++++++++++++---- 2 files changed, 31 insertions(+), 4 deletions(-) diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index 62bc6f1..07052de 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -35,6 +35,10 @@ 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) * "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 1320931..6602958 100644 --- a/docs/re/ui-title-build-map.md +++ b/docs/re/ui-title-build-map.md @@ -220,10 +220,33 @@ 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. -❔ **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. +### ❔ The loop record was opened, and its cycle is still not readable + +The `.rat` was located and partly confirmed, but its **keyframe times are not**. + +`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`. + +| offset | value | | +|---|---|---| +| `+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 | + +**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. + +**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. **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.