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

re: the game blends in the ENCODED space -- no gamma render target, anywhere

Browse Source 
The Port asks whether the blend is evaluated on sRGB-encoded values or
linearised and re-encoded. It is answered by one register field I already
log, and the answer is the same on every draw of two full captures.

RB_COLOR_INFO.color_format is k_8_8_8_8 (0) on 2402/2402 splash draws and
33779/33791 draws of the boot-through-title capture; the other 12 are
k_32_FLOAT and k_16_16_FLOAT and are not colour passes. k_8_8_8_8_GAMMA (1)
appears ZERO times, and color_exp_bias is 0 everywhere so nothing stands in
for a gamma either.

The mechanism is Canary's own source, not our inference: k_8_8_8_8_GAMMA is
the ONLY colour format around which a piecewise-linear gamma<->linear
conversion is applied (spirv_shader_translator.h:510 PWLGammaToLinear /
LinearToPWLGamma, render_target_cache.h:720, dxbc_shader_translator_om.cc).
With k_8_8_8_8 there is none, so the blender operates on the stored values
as they are.

So a renderer that linearises before blending and re-encodes after is doing
a different operation -- and the difference is gamma-shaped and exactly zero
on unblended pixels, which is the divergence signature the port reports.

Also renamed my units-per-second pre-registration off the 'h4' prefix: the
Port's BLOCKED.md numbers this blend-space question H4 and two different H4s
in one corpus is how a citation goes wrong.
This commit is contained in:
sylph-decoder
2026-09-01 17:01:11 +00:00
parent 8dac5aa264
commit 60b05bcd90
4 changed files with 164 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/re/data/blend-space-rt-format.txt Normal file
View File

@@ -0,0 +1,35 @@
# In what SPACE does the game blend? -- answered from RB_COLOR_INFO.color_format,
# over every draw of two full captures.
#
# The mechanism, from Canary's own source (a non-ours instrument):
# ColorRenderTargetFormat (xenos.h:297)
# k_8_8_8_8 = 0 plain UNORM. No conversion anywhere.
# k_8_8_8_8_GAMMA = 1 the ONLY colour format for which a piecewise-linear
# gamma<->linear conversion is applied around the
# render target (spirv_shader_translator.h:510,
# PWLGammaToLinear / LinearToPWLGamma;
# render_target_cache.h:720; dxbc_shader_translator_om.cc)
# So: fmt=1 would mean "decode to linear, blend, re-encode".
# fmt=0 means the blender operates on the stored values as they are.
#
# ── census ────────────────────────────────────────────────────────────────────
#
# Capture A -- both boot splashes (2402 draws, frames 1..600)
# 2402 rt0=[tile=0 fmt=0 exp=0]
#
# Capture B -- boot through the attract movie to the settled title with the
# PRESS (A) plate (33 791 draws over 6565 frame labels)
# 33779 rt0=[tile=0 fmt=0 exp=0]
# 10 rt0=[tile=0 fmt=14 exp=0] k_32_FLOAT -- 10 draws, not a colour pass
# 2 rt0=[tile=0 fmt=6 exp=0] k_16_16_FLOAT -- 2 draws
#
# k_8_8_8_8_GAMMA (fmt=1) appears ZERO times in either capture.
# color_exp_bias is 0 on every draw in both, so there is no exponent scaling
# standing in for a gamma either.
#
# ── conclusion ────────────────────────────────────────────────────────────────
# The game blends in the ENCODED space, on the stored 8-bit values, with no
# linearisation and no re-encode. A renderer that linearises before blending and
# re-encodes after is performing a different operation, and the difference is
# gamma-shaped and exactly zero on unblended pixels -- which is the signature the
# port reports.

43
docs/re/data/input-decoder-masks.txt Normal file
View File

@@ -0,0 +1,43 @@
# Every button mask the C_PAD_DECODER's update function applies, sub_8220B8C0
# (0x8220B8C0..0x8220CFA0, 1400 instructions). Two sources, both listed:
# * pure masks -- rlwinm rA,rS,0,MB,ME, the PPC idiom for 'test these bits'
# * immediates -- andi. / cmpli operands
# Bit values are XINPUT_GAMEPAD's, in their NATIVE positions: the decoder reads
# a 32-bit word at +12 of the C_PAD_RINGBUF (this+76) and masks its low 16 bits,
# verified 7/7 against /image/sylpheed.pe. There is no shift and no remap.
## SINGLE-BIT masks -- one XINPUT button each
0x0001 DPAD_UP rlwinm x21 0x8220BB9C 0x8220BC14 0x8220BE48 0x8220BEA8 0x8220BEEC 0x8220C28C andi./cmpli x2
0x0002 DPAD_DOWN rlwinm x2 0x8220BC64 0x8220C864
0x0004 DPAD_LEFT rlwinm x3 0x8220B8E4 0x8220C858 0x8220C8D8
0x0008 DPAD_RIGHT rlwinm x1 0x8220BC50
0x0010 START rlwinm x5 0x8220BE64 0x8220C47C 0x8220C594 0x8220C6B0 0x8220C920
0x0020 BACK rlwinm x4 0x8220C498 0x8220C5A0 0x8220C6C8 0x8220C93C
0x0040 LEFT_THUMB rlwinm x2 0x8220BF98 0x8220C444
0x0080 RIGHT_THUMB rlwinm x2 0x8220C08C 0x8220C460
0x0100 LEFT_SHOULDER rlwinm x0
0x0200 RIGHT_SHOULDER rlwinm x0
0x0400 (0x0400) rlwinm x1 0x8220CBAC
0x0800 (0x0800) rlwinm x0
0x1000 A rlwinm x2 0x8220C584 0x8220C608
0x2000 B rlwinm x1 0x8220C694
0x4000 X rlwinm x1 0x8220C66C
0x8000 Y rlwinm x1 0x8220C680
## GROUP masks -- the XINPUT groupings, which is what identifies these as buttons
0x0003 x1 DPAD_UP,DPAD_DOWN
0x000F x1 DPAD_UP,DPAD_DOWN,DPAD_LEFT,DPAD_RIGHT
0x0030 x1 START,BACK
0x0060 x1 BACK,LEFT_THUMB
0x00FF x5 DPAD_UP,DPAD_DOWN,DPAD_LEFT,DPAD_RIGHT,START,BACK,LEFT_THUMB,RIGHT_THUMB
0xE000 x18 B,X,Y
0xF000 x1 A,B,X,Y
## Verified against the image (database used only as an index)
0x8220C558 image=0x554A0426 expect=0x554A0426 OK rlwinm r10,r10,0,16,19 mask A|B|X|Y ("any face button")
0x8220C680 image=0x556A0420 expect=0x556A0420 OK rlwinm r10,r11,0,16,16 mask Y
0x8220C66C image=0x556A0462 expect=0x556A0462 OK rlwinm r10,r11,0,17,17 mask X
0x8220C694 image=0x556B04A4 expect=0x556B04A4 OK rlwinm r11,r11,0,18,18 mask B
0x8220BB80 image=0x556B0424 expect=0x556B0424 OK rlwinm r11,r11,0,16,18 mask B|X|Y
0x8220C550 image=0x815F004C expect=0x815F004C OK lwz r10,76(r31) this+76 = the C_PAD_RINGBUF
0x8220C554 image=0x814A000C expect=0x814A000C OK lwz r10,12(r10) +12 inside it = the button word