From 875ac2632d686e6ac17764773b4e8f19f72981ff Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 19 Aug 2026 01:56:04 +0000 Subject: [PATCH] docs/re: two ground-truth paint permutations, and four more refutations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Deriving the child order from the bundle is what the port needs, so this collects data rather than guessing. Both multi-element screen objects live on the title: * a 7-element bundle paints 0 2 4 6 1 3 5 — evens then odds, a stable partition; * the 24-element title build paints 9 11 12 10 13 6 20 19 14 15 18 16 17 0 2 4 7 1 3 5 22 23 21 8. Two things the pair establishes. The list is GROUPED, not shuffled: elements sharing a sprite are contiguous (ptlogo1's three instances at slots 13-15, ptlogo2's at 17-19, the back2eff family at 8-12). And the five single-keyframe elements lead — exactly elements 9,10,11,12,13 have one keyframe, and the list opens with all five, which is a file-visible property. Refuted on this data: first-keyframe time and resting time (back2eff1 starts at 52 and rests at 56, yet paints after back2 at 66/80), declaration order and its reverse, and the RATC child order (ptbase2 is child 4 and paints first while ptlogo1 is child 0 and paints fourteenth). Not settled, and said so: the rule. The group CONTENTS are explained; the group ORDER is not, and two permutations are too few to build it. --- docs/re/structures/ui-screen-runtime.md | 48 +++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/docs/re/structures/ui-screen-runtime.md b/docs/re/structures/ui-screen-runtime.md index ac5cb2d..6b288fa 100644 --- a/docs/re/structures/ui-screen-runtime.md +++ b/docs/re/structures/ui-screen-runtime.md @@ -146,3 +146,51 @@ Until it is derived, a reimplementation has two honest options: hard-code the captured order for the screens that have been captured, or paint in declaration order and accept that the title screen composites wrongly. The first is what the evidence supports; the second is what the viewer does today. + +## Two ground-truth permutations, and what they rule out + +Deriving the child order from the bundle is what the port needs, so the first +step is data. Both live screen objects with more than one element, read off the +title screen: + +**A 7-element bundle** (pivots `(640,360) (250,36) (260,46) (120,44) (130,55) +(194,68) (204,78)` — three pairs 10 px apart plus a full-screen layer): + +``` +paint order (child slots): 0 2 4 6 1 3 5 +``` + +— the **even** declaration indices in order, then the **odd** ones. A stable +partition into two groups, nothing more. + +**The 24-element title build:** + +``` +paint order: 9 11 12 10 13 6 20 19 14 15 18 16 17 0 2 4 7 1 3 5 22 23 21 8 +``` + +### What the pair shows + +* **The list is grouped, not shuffled.** Elements sharing a sprite are + contiguous: `ptlogo1`'s three instances (0,2,4) at slots 13–15, `ptlogo2`'s + (1,3,5) at 17–19, the `back2eff*` family at 8–12. The 7-element bundle's + even/odd split is the same phenomenon in miniature if its evens and odds are + two sprites. +* **The five single-keyframe elements lead.** In the title build, exactly + elements 9, 10, 11, 12, 13 have one keyframe, and the child list opens with + 9, 11, 12, 10, 13 — all five, before anything animated. That is unlikely to be + chance (5 of 24 in the first 5 slots), and it is a *file-visible* property. + +### Refuted as the ordering key, on this data + +* **first-keyframe time** — `back2eff1` starts at t=52 and paints *after* + `back2` (t=66); +* **resting-keyframe time** — same pair, 56 against 80; +* **declaration order and its reverse** — neither, obviously; +* **the RATC child (sprite) order** — the group order does not ascend in it + (`ptbase2` is RATC child 4 and paints first; `ptlogo1` is child 0 and paints + fourteenth). + +**Not settled:** the rule. Two permutations are enough to kill the simple +candidates and not enough to build the real one — the group *contents* are +explained (same sprite), the group *order* is not.