bbd85e9202
REFUTED.md kills this claim: 'T8aD +0x04 bit 0x02 selects an additive blend -> mine, and refuted. Blending those sprites additively worsens every measure against the capture.' That refutation rests entirely on our renderer, which the corpus's own rule calls a hypothesis under test. The blend is now measured off the GPU, so the claim can be tested against the oracle. 35 elements over three screens, every label an RB_BLENDCONTROL0 value read from the command stream: 16 bit-set and additive, 19 bit-clear and alpha-over, zero false positives, zero false negatives. The control that makes it a decode rather than a coincidence: of every bit of the first 12 header words, EXACTLY ONE separates those 35 elements without error. Nothing ties with it. A perfect partition on a small sample is worthless if half the header partitions equally well, which is the mistake +0x08 = 0x8050 was. And the pair no confound survives: ptbtn00 = 0x0110, ptbtn00f = 0x0112 -- the PRESS (A) plate and its own highlight, same screen, differing in exactly this bit, drawn alpha-over and additive respectively. Committed alongside is a PREDICTION for GP_OPTIONS, written before the capture that tests it: a different archive, a different element set, and a MIXED prediction -- po_menu_eff01/02/03 additive, 592 elements alpha-over. Falsified if those three draw alpha-over or anything else draws additive. The developer splash was considered first and rejected as a test: both its elements predict alpha-over, so it can fail but cannot discriminate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
37 lines
1.6 KiB
Plaintext
37 lines
1.6 KiB
Plaintext
# PREDICTION, written and committed BEFORE the capture that tests it. 2026-08-31.
|
|
#
|
|
# blend_vs_t8ad_bit finds T8aD +0x04 bit 0x02 separates ADDITIVE from alpha-over
|
|
# on all 35 elements whose blend has been measured off the GPU, and that NO OTHER
|
|
# BIT of the 48-byte header does it. That is a fit to three screens of one
|
|
# archive.
|
|
#
|
|
# GP_OPTIONS has never been captured, is a different archive with an entirely
|
|
# different element set, and is a screen the port ships. Its prediction is MIXED,
|
|
# which is what makes it a test rather than a formality: 3 elements ADDITIVE,
|
|
# 595 alpha-over.
|
|
#
|
|
# FALSIFIED IF: po_menu_eff01/02/03 draw alpha-over, or any other GP_OPTIONS
|
|
# element draws additive.
|
|
#
|
|
# (The developer splash was considered first and rejected as a test: both its
|
|
# elements predict alpha-over, so it can fail but cannot discriminate.)
|
|
|
|
=== the ADDITIVE predictions in GP_OPTIONS ===
|
|
po_menu_eff01.t32 +0x04 = 00008832 bit 0x02 SET PREDICT ADDITIVE
|
|
po_menu_eff02.t32 +0x04 = 00008832 bit 0x02 SET PREDICT ADDITIVE
|
|
po_menu_eff03.t32 +0x04 = 00008832 bit 0x02 SET PREDICT ADDITIVE
|
|
|
|
=== counts ===
|
|
elements predicted ADDITIVE: 6
|
|
elements predicted alpha-over: 592
|
|
|
|
=== the developer splash, for completeness (both alpha-over) ===
|
|
=== GP_TITLE entry 10 ===
|
|
palogo_sqex.t32 +0x04 = 00008830 bit 0x02 clear PREDICT alpha-over
|
|
palogo_sqex_eff.t32 +0x04 = 00008830 bit 0x02 clear PREDICT alpha-over
|
|
|
|
=== GP_TITLE entry 13 ===
|
|
palogo_sqex.t32 +0x04 = 00008830 bit 0x02 clear PREDICT alpha-over
|
|
palogo_sqex_eff.t32 +0x04 = 00008830 bit 0x02 clear PREDICT alpha-over
|
|
|