re: enumerate an element's records; focus_link is a misnomer

Adds examples/element_records.rs, which lists leaf AND focus_link records
for an element, plus a disc-wide census. Built because I claimed alpha 80
was undeclared after reading one of ptbtn00's two records -- and focus_link
was already parsed, with ui_layout.rs:424 already documenting the focus
record. The format was known and I did not consult it.

Census: 1467 of 15493 elements (9.5%) across 815 builds carry a second
record whose keyframes are invisible to a by-name leaf lookup.

Refutes our own parser's description of the field. It is documented as "the
focused state of a button", but GP_TITLE has pgloading_loop1 -> loop3 ->
loop4, a chain of three loop animations, and ptloop01 -> ptloop02, the two
sweeps. Neither is a focused state. Naming defect only -- behaviour is right
where it is read -- so not renamed here.

🟡 Notes a better candidate for why the two sweeps share one indices=8 draw:
they are linked, not merely co-textured. Testable on the pgloading chain,
which needs a loading-screen capture I do not have. Named, not claimed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-03 20:55:12 +00:00
parent 374a8e2523
commit 2ea27122ba
2 changed files with 148 additions and 0 deletions

View File

@@ -0,0 +1,75 @@
# Enumerating an element's records — and `focus_link` is a misnomer
**Question:** how many records does a UI element actually have, and does my
tooling see them all?
**What the human looks at:** run
`cargo run -p sylpheed-formats --example element_records -- GP_TITLE ptbtn00`.
Pass = **two** records listed. Fail = one.
**What this does NOT cover:** F5's code route, the `0x70000` bits.
**Instrument:** ⟨disc⟩, every `.pak`.
## Why
I claimed `ptbtn00f`'s α80 was undeclared, having read `ptbtn00.rat` — the leaf,
flat α255 — and stopped. The pulse is in `ptbtn00f.rat`, reached by `focus_link`.
**`focus_link` was already parsed, and `ui_layout.rs:424` already documented that
`ptbtn0Nf.rat` carries the focus ring.** The format was known; I did not consult
it. So this enumerates rather than asking the next reader to remember:
```
entry 2: ptbtn00.rat
leaf ptbtn00.rat loop 120 ptbtn00.t32 [1 keys, peak a255]
focus ptbtn00f.rat loop 120 ptbtn00f.t32 [8 keys, peak a80]
```
The fact I missed is the second line.
## ✅ Census — how much of the corpus this exposes
| | |
|---|---|
| elements disc-wide | **15 493** |
| carrying a second record | **1 467 (9.5 %)** |
| builds containing at least one | **815** |
Every one of those has keyframes invisible to anyone who looks a leaf up by name
and stops.
## 🔴 `focus_link` is the wrong name for at least some of its uses
The parser calls it *"`opt ` link to another record — the focused state of a
button"*. On `GP_TITLE` that description fails twice:
```
pgloading_loop1 --> pgloading_loop3 --> pgloading_loop4
(300 units) (120 units) (360 units)
ptloop01 --> ptloop02
(600 units) (720 units)
```
A **chain of three loop animations**, and **the two sweeps**. Neither is a
focused button state. The field links records; "focus" is one thing it is used
for, not what it means.
Recorded as a naming defect in our own parser, not corrected here — the field's
*behaviour* is right everywhere it is read, and renaming it touches every caller.
## 🟡 A candidate mechanism for the batched draw
The two sweeps arrive in a **single `indices=8` draw**
([`f6-unit11`](f6-unit11-pteff03a-IS-drawn.md)), which I have been treating as
"they share a texture page". They are also **linked**`ptloop01 → ptloop02`.
That is a better candidate explanation, and it is testable: another linked pair
should batch too.
**Not tested.** The obvious subject is the `pgloading` chain, and I have no
loading-screen capture. Recorded as 🟡 with the experiment named, not as a
finding.
## Reach
The census counts `focus_link` only. If a record can be reached by any *other*
route, this enumeration is still incomplete and the census is a lower bound.