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

re(ui): finish the top-level rotation census; record the JP-capture blocker

Browse Source 
Two threads had converged on needing one capture this container cannot
take, so this iteration records that and finishes something reachable.

BLOCKED, written into MISSION.md rather than worked around: Q1's keyframe
time association and the rest() rule for plateau-less elements both now
hinge on a running capture of GP_TITLE build 7, the Japanese title. The
console language is not settable here -- user_language appears only as
DECLARE_int32 at four call sites with no DEFINE anywhere in the tree, and
it is absent from the registered cvars in xenia-canary.config.toml. There
is no flag to pass, and guessing one is specifically unsafe: run-canary's
own header records that xenia calls ShowSimpleMessageBox from
ParseLaunchArguments before logging starts, so a bad flag blocks forever
with an empty log. Rebuilding canary to add the cvar would be improvising
around the blocker; it needs a human decision. Neither question blocks
the five menu screens.

FINISHED: the disc-wide top-level rotation count, left running four
iterations ago as a shell loop over `screen info --geometry` that never
completed (it decodes every texture per build). Walking the placement
region directly takes seconds.

  top-level elements with a keyframe group   15 493
  carrying a non-zero rotation                2 152  (13.89 %)

Both controls pass: GP_TITLE build 4 reports 0 (its rotations are the
nested ptloop records) and GP_DIALOG build 0 reports the expected two.

The control earned its place -- the first version indexed the pak with a
`screen list` BUILD number and got 0 for a screen that has two, because
GP_DIALOG build 0 is entry 2. GP_TITLE maps 1:1, which is how the
assumption survived. METHOD line added.

Two free corroborations of the rotation decode. The rotated population is
dominated by tactical-map ship icons -- pbb_destroyer 444, pbr_destroyer
402, pbr_fighter 276 -- i.e. markers rotated to heading, the single
largest use of the field on the disc. And GP_TITLE entry 7's Japanese
wordmark pieces settle from ALTERNATING tilts:

  ptlogo3a  r = 0, -14, -4, -1, 0, ...
  ptlogo3b  r = 0, +14, +4, +1, 0, ...
  ptlogo3c  r = 0, -14, -4, -1, 0, ...

Same magnitudes, opposite signs, all decaying to upright. A misread field
does not produce that.
This commit is contained in:
Sylpheed RE agent
2026-08-28 23:46:54 +00:00
parent b973d8cde3
commit 6d246c7a97
5 changed files with 210 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
docs/re/structures/ui-keyframe-rotation.md
View File

@@ -177,3 +177,51 @@ expressed in degrees rather than of a free angle. 🟡 That is a hypothesis abou
* `+4` and `+8` are **not** claimed as X/Y rotation. Three adjacent signed
degree-valued words invite that reading; only `+12` has been observed to do
anything.
## ✅ The top-level census, finished (2026-08-28)
The earlier attempt drove `sylpheed-cli screen info --geometry` in a shell loop
and never finished — it decodes every texture per build.
[`tools/re-capture/rotation_toplevel_census.py`](../../../tools/re-capture/rotation_toplevel_census.py)
walks the top-level placement region the way `ui_layout.rs` does; seconds instead
of hours. Output: [`data/rotation-toplevel-census.txt`](../data/rotation-toplevel-census.txt).
Both controls pass — `GP_TITLE` build 4 reports **0** (its rotations are the
nested `ptloop` records) and `GP_DIALOG` build 0 reports the **2** expected
`pceff03`/`pceff04` elements.
| | |
|---|---|
| top-level elements with a keyframe group | 15 493 |
| carrying a non-zero rotation | **2 152 (13.89 %)** |
By archive: `GP_READY_ROOM` **1 868**, `GP_DIALOG` 40, each of the six
`GP_MAIN_GAME_*2D` 37, `GP_GAMEOVER` 10, `GP_DEBRIEFING_PILOTLOG` 8,
`GP_TITLE` **4**.
### Two more corroborations, both free
**The rotated population is tactical-map ship icons.** The most-rotated names are
`pbb_destroyer` (444), `pbr_destroyer` (402), `pbr_fighter` (276),
`pbb_fighter` (174), `pbb_aircraft` (168) — map markers, in the archive that
holds the tactical map. Rotating a ship icon to its heading is what the field is
*for*, and it is the single largest use of it on the disc.
**`GP_TITLE` entry 7's four rotated elements carry their own control.** Three of
them are the Japanese wordmark's pieces, and they settle to upright from
**alternating** tilts:
```
ptlogo3a.t32 r = 0, -14, -4, -1, 0, 0, 0, 0
ptlogo3b.t32 r = 0, +14, +4, +1, 0, 0, 0, 0
ptlogo3c.t32 r = 0, -14, -4, -1, 0, 0, 0, 0
```
Same magnitudes, alternating sign, all decaying to 0 — three sibling elements
tilting opposite ways and straightening. A misread field does not produce that.
(The fourth is `ptlogo_eff3.t32`, `r = 0, 0, 80, 150` — the transient bloom
discussed in [ui-resting-pose](ui-resting-pose.md).)
⚠️ **This is not subtractable from the byte-scan census.** That one counts
*blocks* (12 164 of 83 862 with a non-zero `+12`); this one counts *elements*.
The two are different units and the difference is not "the nested population".