fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

formats: the declaration entry does not mark a focused state - swept and asserted

Browse Source 
The backlog's cheapest open question about the 60-byte entry: kind is a flags
word (0x10 untextured primitive, 0x4 repeated instance, 0x3002 button record), so
a focus bit would be the obvious answer and the name-pairing in
mark_focused_states would be a convention standing in for a real field.

It is not. Over every screen build on the disc: 54 name-paired focused/base
pairs, all 54 with IDENTICAL kind (all 0x0), NO bit ever set on the focused entry
and clear on its base, and the only words of the entry that ever differ are +48
and +52 - the pivot. The two entries differ in where the sprite sits and in
nothing else.

The test asserts all four numbers rather than just printing them, so the negative
is pinned instead of decaying back into a suspicion. Also noted: these buttons
carry kind = 0x0, so the documented 0x3002 "button record" belongs to the .rat
records and not to the .t32 sprites a menu draws.

Closes the declaration table, not the question - the focused state could still be
marked in the .rat record, the RATC child stream, or only in the game's code.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-24 03:50:40 +00:00
parent 68a3fed554
commit 2d28226b30
2 changed files with 201 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/re/structures/ui-rat-layout.md
View File

@@ -422,3 +422,33 @@ decoded 265×198, declared pivot 19,18), so the rule is not merely a
language-inheritance artefact. **Do not derive a texture size from a pivot**; the
capture backs the decoded size, not the pivot — `ptcopyright` is 694 px wide in
the framebuffer, and `pivot·2` says 618.
## 🔴 The declaration entry does NOT mark a focused state (2026-08-24)
The backlog carried this as the cheapest open question about the entry: `kind` is
a flags word — `0x10` is an untextured primitive, `0x4` a repeated instance,
`0x3002` a button record — so a *focus* bit would be the obvious answer, and the
name-pairing in `mark_focused_states` (`pgmenu_btn00f.t32` next to
`pgmenu_btn00.t32`) would be a convention standing in for a real field.
**It is not standing in for anything.** Swept over every screen build on the disc
(`tests/ui_focus_kind_disc.rs`, asserted so it cannot rot back into a suspicion):
| | |
|---|---|
| name-paired focused/base pairs on the disc | **54** |
| pairs whose `kind` is **identical** | **54** — all of them, and all `kind = 0x0` |
| `kind` bits set on the focused entry and clear on its base | **none, on any pair** |
| words of the 60-byte entry that ever differ | **`+48` and `+52` only** — the pivot |
So the two entries differ in *where the sprite sits* and in nothing else. There
is no focus field in the declaration table, and the naming pairing is the only
signal the file gives.
Worth noting in passing: these buttons carry `kind = 0x0`, so the documented
`0x3002` "button record" belongs to the `.rat` records, not to the `.t32` sprites
that a menu draws for its buttons.
**Still open:** whether the focused state is marked anywhere *else* — the `.rat`
record, the RATC child stream, or (as with the paint order) only in the game's
code. This closes the declaration table, not the question.