fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

formats: the tie-break, refuted six ways and measured down to the pixel

Browse Source 
With the layer key and the primitives' implied keys in place, the tie-break -
how the game orders elements sharing a key - is all that is left between the
derived order and ground truth. Three measured screens now constrain it.

On the menu and the splash every tied group comes out in declaration order,
which is what the stable sort already gives. The title is the only screen that
discriminates, and nothing predicts it: 0x8083 x5 paints eff1, eff2, eff5, eff3,
eff4, and 0x80a0 x7 paints logo1 x3, tm, logo2 x3.

Refuted: declaration order; RATC child order; first keyframe time (52, 56, 62,
58, 60 - the measured order is not sorted by them); resting keyframe time;
resting X or Y (938, 938, 64, 788, 447); and T8aD header words +00, +04, +0c and
+10, which are either identical within a group or unsorted.

Child order is worth its own line: a strict improvement over declaration order
(7 misplaced positions on the title instead of 9, and it recovers the logo
grouping) and exactly right on the other two screens. NOT adopted, because on the
only screen that can tell them apart it is still wrong.

Adds a test that measures what the residual costs instead of assuming it. Of the
3 disagreeing pairs of drawn elements across all three screens, all 3 have
overlapping bounding boxes and 2 share opaque pixels: ptlogo_back2eff5 against
eff3 (22568 px) and eff4 (32395 px). The third pair, ptlogo2 vs ptlogo_tm,
overlaps by two columns and shares NO opaque pixel - the wordmark is transparent
there. A bounding-box test called that a defect; reading the alpha says it is
not, which is why the test reads pixels. The set is pinned, so a change that
makes it worse fails.

15 disc tests green.
This commit is contained in:
Sylpheed RE agent
2026-08-19 09:34:10 +00:00
parent 19f2f562be
commit 0873f47687
2 changed files with 221 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
docs/re/structures/ui-paint-order-key.md
View File

@@ -192,3 +192,68 @@ seen before.
drawn, but the capture shows the menu frame plainly. Either the resting rule
picks the wrong plateau for them or the frame is drawn by something else.
* ❔ The derivation for primitives. Three permutations now, still no rule.
## The tie-break: still unsolved, and now measured down to the pixel (2026-08-19)
With the layer key and the primitives' implied keys in place, the tie-break —
how the game orders elements that **share** a key — is the only thing left
between the derived order and ground truth. Three measured screens now constrain
it.
**On the menu and the splash it does not bite.** Every tied group there comes out
in declaration order, which is what the stable sort already gives:
| screen | tied group | measured |
|---|---|---|
| menu | `0x8010` ×2 | 3, 4 |
| menu | `0x8050` ×2 | 6, 7 |
| menu | `0x8110` ×5 | 10, 11, 12, 13, 14 |
| splash | `0xa100` ×3 | 2, 4, 6 |
| splash | `0xa110` ×3 | 1, 3, 5 |
**The title is the one screen that discriminates**, and nothing predicts it:
```
0x8083 ×5 measured 14, 15, 18, 16, 17 (eff1, eff2, eff5, eff3, eff4)
0x80a0 ×7 measured 0, 2, 4, 7, 1, 3, 5 (logo1×3, tm, logo2×3)
```
### Refuted
| candidate | result |
|---|---|
| declaration order | interleaves the logos (`0,1,2,3,4,5,7`); wrong |
| **RATC child order** | groups the logos correctly but puts `tm` last, and leaves `0x8083` in `eff1..eff5`; **exact on the menu and splash, wrong on the title** |
| first keyframe time | `0x8083` times are 52, 56, **62**, 58, 60 — the measured order is not sorted by them |
| resting keyframe time | same shape, same failure |
| resting X or Y | `0x8083` rests at x = 938, 938, 64, 788, 447 — unsorted either way |
| `T8aD` header `+0x00`, `+0x04`, `+0x0c`, `+0x10` | identical within a group, or unsorted |
Child order deserves a note: it is a *strict improvement* over declaration order
(7 misplaced positions on the title instead of 9, and it recovers the
logo1×3 / logo2×3 grouping), and it is exactly right on the two other screens.
It was **not** adopted, because on the only screen that can tell the two apart it
is still wrong, and a rule that is wrong there buys nothing a stable sort does
not already give.
### What it costs, exactly
`order_disagreements_that_change_pixels_are_pinned` measures the damage rather
than assuming it. Across all three measured screens:
* **3** disagreeing pairs of *drawn* elements (repeat instances and faded-out
elements are skipped, so they cannot count);
* all 3 have overlapping bounding boxes;
* **2** actually share opaque pixels — `ptlogo_back2eff5` against `eff3`
(22 568 px) and against `eff4` (32 395 px). The game paints `eff5` third in the
group, the sort paints it fifth, and those blended glow pixels differ.
The third pair is the instructive one. `ptlogo2` and `ptlogo_tm` overlap by two
columns — the wordmark decodes 992 px wide and reaches x=1129, the trademark
starts at x=1127 — but the wordmark is **fully transparent** there, so the order
cannot matter. A bounding-box test called this a defect; reading the alpha says
it is not. That is why the test reads pixels.
So the residual error in the derived order is confined to **one element's blend
on one screen**, and it is pinned: a change that makes it worse fails the test.