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:
75
docs/re/element-records-enumerated.md
Normal file
75
docs/re/element-records-enumerated.md
Normal 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.
|
||||
Reference in New Issue
Block a user