re: the paint-order tie-break costs 24 overlapping pairs, not one element

The port challenged HANDOFF's "costs one element's blend on one screen" with a
census of 105 elements sharing a layer key across 12 of 16 screens. The two
numbers count different things -- elements vs overlapping pairs -- so it is not
the contradiction it looked like, but the objection stands and the line was
wrong.

paint_order_audit already reports overlapping ties per entry, and over all 16
GP_TITLE entries: 5 use a measured order and carry no tie risk; of the 11 that
fall back to the derived order, 7 have overlapping ties, 24 pairs in total. The
Japanese title (entry 7) alone has 16, because it is the twin of the one build
whose measured order exists and has none of its own.

Overlap bounds where a wrong tie-break COULD show, not what it costs; nobody has
measured how many of the 24 change a pixel, and the port is right about that too.

The rule itself is unaffected: the layer key is still decoded and the derived
order still reproduces every measured order exactly except the title's eight
tied pairs.

Census committed at docs/re/data/paint-order-ties-gp_title.txt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nsxw1A9JseUw99Yw1ZRQzY
This commit is contained in:
sylph-decoder
2026-08-29 14:17:40 +00:00
parent 5a0fa8f6f9
commit c5b815c5aa
3 changed files with 112 additions and 1 deletions

View File

@@ -10,6 +10,44 @@ there are **three** measured orders now, not two.
Tool: `cargo run -p sylpheed-formats --example paint_order_audit -- dat/GP_TITLE.pak`.
Output committed at [`data/paint-order-audit.txt`](../data/paint-order-audit.txt).
## 🔴 Refutation, 2026-08-29 — the published COST of the tie-break was understated
The port challenged HANDOFF's line *"eight candidates refuted; costs one
element's blend on one screen"* against its own census of 105 elements sharing a
key across 12 of 16 screens. Those two numbers are not comparable — the port
counts *elements*, this page counts overlapping *pairs*, and "one screen" was
scoped to five English menu screens without saying so. **So the objection is not
the contradiction it looked like. It is still right, and the line is corrected.**
`paint_order_audit` already reports overlapping ties per entry. Run over all 16
`GP_TITLE` entries — committed at
[`data/paint-order-ties-gp_title.txt`](../data/paint-order-ties-gp_title.txt):
| entry | screen | tied pairs | **overlapping** |
|---|---|---|---|
| 4, 5, 8, 11, 14 | title EN, main menu ×2, splash ×2 | — | **measured order is used; no tie risk** |
| 0, 1 | loading, plain | 2 | **1** each |
| 12, 15 | loading, dressed | 2 | **1** each |
| 6, 9 | `EXTRAS` EN / JP | 15 | **2** each |
| **7** | **title, Japanese** | **37** | **16** |
| 2, 3, 10, 13 | `PRESS Ⓐ` plate, `palogo_sqex` | 0 | 0 |
**24 overlapping tied pairs across 7 of the 11 entries that fall back to the
derived order** — not one element on one screen. The Japanese title alone carries
16, because it is the twin of the one build whose measured order exists and it
has no measured order of its own.
⚠️ **Overlap is an upper bound on the cost, not the cost.** Two elements that
overlap still show nothing if either is transparent at rest or one is opaque
where they meet. What the pair count bounds is *where a wrong tie-break could
show*, and the port is right that nobody has measured how many of those actually
change a pixel.
⚠️ This does not weaken the **rule**. The layer key is decoded and the derived
order reproduces every measured order it can be checked against, exactly, except
the title's eight tied pairs. What is corrected is only the advertised blast
radius of the unknown tie-break.
## The claim holds, and the exception is all ties
| build | derived == measured | inverted pairs | of which same-key ties |