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

re(ui): the eff-name implication for bit 0x02 is refuted disc-wide

Browse Source 
Last iteration I killed the biconditional and reported that the one-way
reading survived: all 10 bit-set sprites on GP_TITLE build 4 are eff
names, so "bit set => eff name". Checked over the disc, that is false.

  sprites with a resolvable preceding name   14 709
    bit SET   & name has 'eff'                2 338
    bit SET   & name lacks 'eff'              2 657   <-- counterexamples
    bit clear & name has 'eff'                1 399
    bit clear & name lacks 'eff'              8 315

  P(eff | set)   = 0.468
  P(eff | clear) = 0.144

The implication fails more often than it holds. What survives is an
association -- 3.3x enrichment -- and build 4's 10/10 was a local naming
habit in an 18-element bundle, not a format rule.

The counterexamples are the useful part: pv_loading_ring0,
pv_loading_light0-3, pv_loading_line, px_bunk_line, px_top_extra. Rings,
glows, lights, thin lines -- effect-like artwork that does not carry the
eff naming convention. Consistent with the bit marking effect sprites by
authoring intent rather than by name, which is a description and not a
decode, and is labelled as such.

Names here come from the string immediately preceding each T8aD,
validated 17/18 on build 4 against the RATC child order; the single
mismatch is the known pteff04.t32 -> registered as 8AX case, so this is
the element (opt) name rather than the sprite's registered name. That
mismatch is itself an independent confirmation of the 8AX finding,
reached from the opposite direction.

METHOD: a pattern perfect on one screen can be near-chance on the disc;
and when an association survives a refuted implication, the
counterexamples are the finding.
This commit is contained in:
Sylpheed RE agent
2026-08-29 03:20:24 +00:00
parent 4ef0e30788
commit 2740cbef55
6 changed files with 138 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -528,7 +528,8 @@ evidence rather than on a guess between two same-sized sprites.
| hypothesis | verdict |
|---|---|
| bit ⟺ the name contains `eff` | **refuted** — `ptlogo_back2eff` is an `eff` name with the bit clear. All 10 bit-set sprites *are* `eff` names, so the implication holds one way only |
| bit ⟺ the name contains `eff` | **refuted** — `ptlogo_back2eff` is an `eff` name with the bit clear |
| bit ⇒ the name contains `eff` (the surviving one-way reading) | **also refuted, disc-wide — see below.** It held 10/10 on build 4 and fails on **2 657 of 4 995** bit-set sprites across the disc |
| bit ⟺ the element is transient (gone before the screen settles) | **refuted** — `pteff03`/`pteff03a` carry the bit and run to `t=250`, ramping to `a=255` and holding, i.e. they persist |
### 🟡 What the exception looks like up close
@@ -549,3 +550,35 @@ of one image at one size.
So the bit tracks something that also distinguishes two versions of the same
artwork, alongside a different layer key. ❔ **Still not diagnosed**, but the
search space is smaller by two and the attribution underneath it is now sound.
### 🔴 The one-way implication is refuted too — build 4 was a local pattern
Having fixed the attribution, the surviving reading was *"bit set ⇒ the name
contains `eff`"*, true 10/10 on `GP_TITLE` build 4. Checked disc-wide with
[`tools/re-capture/eff_bit_census.py`](../../../tools/re-capture/eff_bit_census.py)
([data](../data/eff-bit-census.txt)) over 14 709 sprites whose preceding name
resolves:
| | count |
|---|---|
| bit SET & name has `eff` | 2 338 |
| **bit SET & name lacks `eff`** | **2 657** |
| bit clear & name has `eff` | 1 399 |
| bit clear & name lacks `eff` | 8 315 |
`P(eff | set) = 0.468` against `P(eff | clear) = 0.144`. **The implication fails
more often than it holds.** What survives is an *association* — the bit is 3.3×
enriched for `eff` names — and one build's 10/10 was a local naming habit, not a
rule.
🟡 The counterexamples are the interesting part: `pv_loading_ring0`,
`pv_loading_light0`–`3`, `pv_loading_line`, `px_bunk_line`, `px_top_extra` —
rings, glows, lights and thin lines. **Effect-like artwork that does not carry
the `eff` naming convention.** Consistent with the bit marking effect sprites by
authoring intent rather than by name, which is a description, not a decode.
⚠️ Name caveat: these names come from the string **immediately preceding** each
`T8aD`, validated 17/18 on build 4 against the child order. The one mismatch is
the known `pteff04.t32` → registered as `8AX` case, so this is the **element**
(`opt `) name, not the sprite's registered name.