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

re(ui): the sequencing survives refutation -- and a bundle is a palette

Browse Source 
Two checks on last iteration's "sequential, not simultaneous" reading.

First, the phases really are disjoint. If glows and logos ever shared a
frame the claim would be wrong. Across all 235 captured frames the count
of frames containing both is ZERO, and the switch is a single clean
boundary -- f110-115 draw 1280x720 + 262x108 + 525x90, f116 onward
1280x720 + 243x86 + 499x72. Two sprites either side, no transition frame.

Second, and larger: a third of the bundle is never drawn. Entry 11
declares three logo/glow pairs and only two appear.

  palogo_gamearts / _eff    95 / 22 frames
  palogo_seta     / _eff    95 / 22 frames
  palogo_anima    / _eff    never

palogo_anima declares the SAME keyframe times as palogo_gamearts. Two
elements with byte-identical data, 95 frames and 0 frames in one run.
Reach: the capture covers frames 1-214, so this is "never in the window".

So a bundle is a palette, not a script. Its elements say what to draw and
for how long; which of them run, and when each starts, is decided outside
the placement data. That is the same conclusion the boot-order work
reached from the other end -- the driver is code, not data -- now with a
per-element measurement behind it.

For the port, concretely: compositing every element of a bundle does not
reproduce what the game shows over time. It is the right thing for a
static screen that settles, and it is not a timeline.

METHOD: two elements with identical data and different outcomes is the
strongest possible evidence that the decision is elsewhere.
This commit is contained in:
Sylpheed RE agent
2026-08-29 04:47:05 +00:00
parent 7fb6bdfad8
commit baed44a9ea
4 changed files with 72 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/port/HANDOFF.md
View File

@@ -356,6 +356,16 @@ authored version can be deleted.
⚠️ **So you must author the sequencing.** The observed order on the developer ⚠️ **So you must author the sequencing.** The observed order on the developer
splash — both glows, then both logos — is *measured for one screen*, not a splash — both glows, then both logos — is *measured for one screen*, not a
decoded rule. decoded rule.
✅ **Verified against its own refutation:** across all 235 captured frames,
**zero** contain both a glow and a logo; the switch is one clean boundary with
two sprites either side.
🔴 **And it goes further than start times — a bundle is a palette, not a
script.** Entry 11 declares *three* logo/glow pairs; only two are ever drawn.
`palogo_anima` gets **0 frames** while `palogo_gamearts` gets **95**, from
byte-identical keyframe times. (Reach: the capture covers frames 1–214, so
"never in the window".) **Compositing every element of a bundle does not
reproduce what the game shows over time** — it is right for a static screen
that settles, and it is not a timeline.
[`structures/ui-group-start-time.md`](../re/structures/ui-group-start-time.md) [`structures/ui-group-start-time.md`](../re/structures/ui-group-start-time.md)
* **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is

6
docs/re/METHOD.md
View File

@@ -802,3 +802,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
right, so what is absent is a per-group start — and it pointed straight at the right, so what is absent is a per-group start — and it pointed straight at the
one undecoded word in the group header. (Which was zero, but the diagnosis was one undecoded word in the group header. (Which was zero, but the diagnosis was
still what made the next step obvious rather than a search.) still what made the next step obvious rather than a search.)
* **Two elements with identical data and different outcomes is the strongest
possible evidence that the decision is elsewhere.** `palogo_anima` and
`palogo_gamearts` carry byte-identical keyframe times; one is drawn for 95
frames and the other not at all. No amount of re-reading the placement data can
explain that, and the pair is worth more than a survey — when a hypothesis says
"the data decides", look for two records that agree and behave differently.

9
docs/re/REFUTED.md
View File

@@ -572,3 +572,12 @@ neighbourhood, not just the line.
origin needs f₀ ≈ 93.5 for `palogo_gamearts_eff` and f₀ ≈ 103 for origin needs f₀ ≈ 93.5 for `palogo_gamearts_eff` and f₀ ≈ 103 for
`palogo_gamearts`, ~19 units apart, and aligning one throws the other off by `palogo_gamearts`, ~19 units apart, and aligning one throws the other off by
~9 frames at both ends. Durations match (97.8 %, 98.5 %); starts do not. ~9 frames at both ends. Durations match (97.8 %, 98.5 %); starts do not.
* "the glows and logos might overlap and my size-grouping merged them" → **tested
and refuted.** Across all 235 captured frames, **zero** contain both a glow and
a logo; f110–115 draw two glows and f116 onward two logos, with no transition
frame. The sequencing is real.
* "a bundle's declared elements are what the screen shows" → **refuted.** Entry 11
declares three logo/glow pairs and only two are ever drawn — `palogo_anima`
gets 0 frames against `palogo_gamearts`'s 95, from byte-identical keyframe
times. (Reach: within the capture's frames 1–214.)
[`ui-group-start-time.md`](structures/ui-group-start-time.md)

47
docs/re/structures/ui-group-start-time.md
View File

@@ -60,3 +60,50 @@ on the same screen. On the developer splash the observed order is: both glows
together, then both logos together. That is a **measured** sequence for one together, then both logos together. That is a **measured** sequence for one
screen, not a decoded rule — a port animating a screen has to author the screen, not a decoded rule — a port animating a screen has to author the
sequencing, and should know it is authoring. sequencing, and should know it is authoring.
---
## ✅ Verified against its own refutation — and it goes further than start times
**2026-08-29.** Two checks on the "sequential, not simultaneous" reading.
### The phases really are disjoint
If the glows and logos ever shared a frame, the sequencing claim would be wrong.
Across all 235 captured frames, the number of frames containing **both** a glow
and a logo is **zero**. The switch is a single clean boundary:
```
f110–115 1280x720 + 262x108 + 525x90 ← both glows
f116–122 1280x720 + 243x86 + 499x72 ← both logos
```
Two sprites either side, no overlap, no transition frame.
### A third of the bundle is never drawn at all
Entry 11 declares **three** logo/glow pairs. Only two are ever drawn:
| sprite | declared | drawn |
|---|---|---|
| `palogo_gamearts` / `_eff` | 500×71 / 521×91 | **95 / 22 frames** |
| `palogo_seta` / `_eff` | 240×89 / 261×110 | **95 / 22 frames** |
| `palogo_anima` / `_eff` | 388×136 / 407×156 | **never** |
…and `palogo_anima` declares the *same* keyframe times as `palogo_gamearts`.
⚠️ Reach: the capture covers frames 1–214, so this is "never **within the
window**", not "never". The pair may follow after it.
### What that means for a consumer
**A bundle is a palette, not a script.** Its elements carry what to draw and for
how long; which of them run, and when each starts, is decided outside the
placement data — selectively enough that two elements with byte-identical
keyframe times get 95 frames and 0 frames in the same run.
That is the same conclusion the boot-order work reached from the other end
(*the driver is code, not data*), now with a per-element measurement behind it.
⚠️ Concretely: **compositing every element of a bundle does not reproduce what
the game shows over time.** It is the right thing for a static screen that
settles, and it is not a timeline.