re: a candidate blend flag -- T8aD header +0x04, bit 0x02

Continuing the swoosh. Last iteration ended with "the next step is
finding where a blend mode would be encoded, and I do not know the format
carries one". It does carry a candidate.

The kind field is not it -- the swoosh sprites are kind 0x0, the same as
ordinary ones. But the T8aD header word at +0x04 splits the title's
sprites exactly along effect versus normal: pteff01, pteff03a,
ptlogo_back2eff1..5 and both ptlogoall_eff are 0x8832, while ptlogo1,
ptlogo2, ptlogo_tm, ptbase2, ptlogo_back2 and ptcopyright are 0x8830.
One bit, 0x02.

Disc-wide it behaves like a real flag rather than an artefact: 19216
sprites, 18 distinct values, bit 0x02 set in 27.1 percent, and it toggles
against otherwise identical words -- 0x8830 against 0x8832, 0x0830
against 0x0832, 0x0810 against 0x0812, 0x0030 against 0x0032.

Marked as correlation and not decode, because nothing here shows the bit
MEANS additive. The one thing that makes it more than a guess is
ptlogo_back2eff, which carries 0x8830 despite having eff in its name --
so the split is the field's and not my pattern-matching on names. The
test is to blend bit-0x02 sprites additively and re-correlate the title
against the plate-free capture.

METHOD gets the trap that cost the first attempt: searching for a
sprite's name and taking the next T8aD returns the SAME header for every
sprite, because the names all live together in the declaration table. It
failed its own control at once -- different sprites reporting identical
dimensions -- and the fix was to match on width and height instead of on
proximity.
This commit is contained in:
Sylpheed RE agent
2026-08-28 21:46:18 +00:00
parent c10802536f
commit e0d02dce71
3 changed files with 56 additions and 1 deletions

View File

@@ -96,7 +96,19 @@ authored version can be deleted.
mostly-transparent sprites (`ptlogo_back2` 5.4 % opaque, its glow 10.3 %, the
five `eff` segments 10–23 %, all white or warm) stacked with plain alpha-over
saturate to opaque white — which is exactly what we draw, and would read as
"thicker" against the game's thin coloured stroke. ❔ Not diagnosed.
"thicker" against the game's thin coloured stroke.
🟡 **And there is a candidate field for it.** The `T8aD` header word at
**`+0x04`** splits the title's sprites exactly along effect-vs-normal:
`pteff01`, `pteff03a`, `ptlogo_back2eff1…5`, `ptlogoall_eff`/`_eff2` are
**`0x8832`**; `ptlogo1`/`2`, `ptlogo_tm`, `ptbase2`, `ptlogo_back2`,
`ptcopyright` and `ptlogo_back2eff` are **`0x8830`**. One bit — **`0x02`**.
Disc-wide it is a real independent flag: 19 216 sprites, 18 distinct values,
bit `0x02` set in **27.1 %**, and it toggles against otherwise-identical words
(`0x8830`/`0x8832`, `0x0830`/`0x0832`, `0x0810`/`0x0812`, `0x0030`/`0x0032`).
⚠️ **Correlation only — untested.** Nothing yet shows it *means* additive; the
test is to blend bit-`0x02` sprites additively and re-correlate the title
against the capture. Note `ptlogo_back2eff` is `0x8830` despite its name, so
this is a field and not a naming pattern. ❔ Not diagnosed.
🔴 **Refuted:** it is *not* that our dim covers the whole frame instead of
sitting beneath the UI — the logo reads +2.36 against a background of −0.74, so
the paint order is being honoured.