Files

sylph-decoder baf285d366 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

2026-09-03 20:55:12 +00:00

2.7 KiB

Raw Blame History

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), 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.

2.7 KiB Raw Blame History Unescape Escape

Enumerating an element's records — and focus_link is a misnomer

Why