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

re: validate the screen layout against the running game -- eight rows, +/-2 px

Browse Source 
Booted to the ARSENAL and detected the eight teal category chips by colour, then
compared their row centres against the eight prbtn1..8.rat placements parsed from
eng\prmain_scr.prt. All eight fit

    screen_Y = placement_Y + pivotY(14) + chrome(45)

with residuals -1,-1,-1,-2,0,-2,-1,-2 px. The spacings are the real signature:
predicted 54,56,55,54,56,55,55 against observed 54,56,54,56,54,56,54 -- an
irregular alternating pattern, not a round number that could match by luck. The
one free parameter is the 45 px emulator window chrome, which is not part of the
game, and the residual is centroid measurement noise.

Confirms three things together: the declaration table is the element set, the
placement region gives real screen coordinates, and the pivot composes additively
(pivotY 14 = half the 28 px chip, so placement is top-left as documented).

Explicitly NOT confirmed: the max-dwell rule for animated elements. These buttons
are static -- every keyframe identical -- which is exactly what makes them a clean
ruler. That rule needs an element captured mid-slide.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-11 22:25:18 +00:00
parent 35e2d1067f
commit 9228255bfa
2 changed files with 37 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/re/captures/arsenal-layout-validation.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 620 KiB

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

@@ -277,3 +277,40 @@ the running game:
[movie table](../movie-subtitle-link.md) uses. A sub-component reads identically:
`psselect_win1` declares 4 elements, three of them **parented to element 0**,
which is the parent-index field doing real work on an independent pak.
### Validated against the running game, to ±2 px
The layout above is a static parse; this is the check that it predicts what the
game actually draws. Booting to the ARSENAL and detecting the eight teal category
chips by colour gives their row centres, against the eight `prbtn1…8.rat`
placements from `eng\prmain_scr.prt`:
```
placement Y + pivotY(14) + chrome(45) observed centre diff
166 225 224 -1
220 279 278 -1
276 335 334 -1
331 390 388 -2
385 444 444 +0
441 500 498 -2
496 555 554 -1
551 610 608 -2
```
The spacings are the real signature: **54, 56, 55, 54, 56, 55, 55** predicted
against **54, 56, 54, 56, 54, 56, 54** observed — an irregular alternating pattern,
not a round number that could match by luck. The single free parameter is the
**45 px emulator window chrome** (title bar + menu bar), which is not part of the
game; the ±2 px residual is the centroid measurement, since a thresholded chip
centre is not exact.
This confirms three things at once: the **declaration table is the element set**,
the **placement region gives real screen coordinates**, and the **pivot composes
additively** — `pivotY = 14` is half the 28 px chip, so placement is the top-left
and pivot carries the centre offset, exactly as the record layout says.
**Not** confirmed by this: the max-dwell rule for *animated* elements. These eight
buttons are static (every keyframe identical), which is precisely why they make a
clean ruler. Validating the animation rule needs an element captured mid-slide.
Evidence: [`captures/arsenal-layout-validation.png`](../captures/arsenal-layout-validation.png).