4bb67fa166
Play-test finding 4 asked, in order: is there a pass, what is it, where do its parameters come from, only then what curve. All four, from GPU state. 1. NO post-process pass. Over all 1 048 draws of frames 4..226 (both boot splashes): rt0=[tile=0 fmt=0 exp=0] on 1048/1048, pitch=1280 msaa=0 on 1048/1048, edram_mode only ever kColorDepth or kCopy, resolve dests only the two alternating front buffers, and NO texture base anywhere in the capture equals a resolve destination. The only texture bound in the whole splash region is the sprite page 0x11A50000. No blur, no bloom, no fade quad over a resolved image, no tone curve, no resolve-and-resample. 2. What it is: per frame, a full-screen replace triangle (the clear), a full-screen black quad through the ordinary blend, ONE batched sprite draw carrying every visible element (indices 4/8/12/24), and the two presentation resolves. 3. Where the parameters come from: NOT the constant banks -- the splash pixel shaders read zero float constants, ps_c[n=0] on 1048/1048, taken off each shader's own float_bitmap. NOT immediates. The fade is the per-vertex k_8_8_8_8 colour in a vertex buffer the guest rewrites every frame. 4. The curve falls out of 3 and is the corpus's existing 34/frame law, reproduced on an independent capture. Not claimed as new. And the composite is ORDINARY SOURCE-OVER, confirmed from the shader ucode rather than inferred from the blend register: the register reads ONE/ONE_MINUS_SRC_ALPHA, which looks premultiplied, and is -- because the shader premultiplies. The two together are src*A + dst*(1-A). So the 'more pronounced' fade is neither a blend difference nor a pass. The likely mechanism instead: the developer splash submits SIX quads, three logos plus three slightly-larger companions that lead them by 8 frames and are gone 79 frames early. Two over-blended copies of the same art at different scale is a halo, on screen only during the entry. Refutation attempt, recorded: REFUTED.md's re-opened rest() pair states its settling condition as 'a draw capture of the developer splash naming which of the three glows is submitted at rest'. This is that capture. All three companions ARE submitted in all 21 frames -- so no rule that hides one describes this stream -- but they are NOT interchangeable: Q6 leaves the plateau on its own -5.6/frame decay while Q4 and Q5 hold 255. The one-byte sibling difference is drawn. Trap recorded with the evidence: censusing the whole 600-frame log finds six 640x360 textures sampled ~330 times each, which reads exactly like a half-resolution blur chain. They are the attract movie's chroma planes and first appear at frame 234, after both splashes. Restricting the window is what separates them. Evidence: docs/re/data/splash-draw-pass-census.txt, docs/re/data/splash-quad-timeline.txt, docs/re/data/shaders/*.ucode.frag. Logger: canary sylpheed-re d90d14e02.
36 lines
1.8 KiB
Plaintext
36 lines
1.8 KiB
Plaintext
# Every GPU state that could carry a post-process pass, over BOTH boot splashes.
|
|
# Source: xenia_re_ui_draws_01.log, Canary with the augmented UI draw logger
|
|
# (canary sylpheed-re d90d14e02). Capture recipe:
|
|
# GRACE=1 NOTAP=1 ARM=early FRAMES=600 MAXDRAWS=400000 tools/re-capture/ui_draw_capture.sh
|
|
# Frames 4..226 are the two splashes; frames >=234 are the attract movie and are
|
|
# EXCLUDED here -- the movie's 640x360 chroma planes look like a half-res blur
|
|
# chain if you census the whole log at once, and that is the trap this file avoids.
|
|
|
|
draws in frames 4..226: 1048
|
|
|
|
## 1. RENDER TARGETS -- one, throughout
|
|
[('rt0=[tile=0 fmt=0 exp=0]', 1048)]
|
|
## 2. SURFACE -- one pitch, no MSAA, throughout
|
|
[('pitch=1280 msaa=0', 1048)]
|
|
## 3. EDRAM MODE -- kColorDepth(4) draws and kCopy(6) resolves only
|
|
[('4', 628), ('6', 420)]
|
|
## 4. RESOLVE DESTINATIONS -- two, alternating front buffers, every frame
|
|
[('14570000', 210), ('14910000', 210)]
|
|
## 5. TEXTURES BOUND -- and whether any is a resolve destination
|
|
416 ('10000000', '1x1', '26')
|
|
208 ('11A50000', '1280x768', '6')
|
|
any texture base == a resolve dest? False
|
|
## 6. PIXEL-SHADER FLOAT CONSTANTS -- the parameter-source question
|
|
[('ps_c[n=0]:', 1048)]
|
|
## 7. SHADERS, and the blend each is submitted with
|
|
416 ps=0xE59B2B3DA4AA9008 blend=0x07010701 mode=6
|
|
210 ps=0x2E372EA28CC404B7 blend=0x00010001 mode=4
|
|
210 ps=0x5773DC18083C4C20 blend=0x07010701 mode=4
|
|
208 ps=0xE59B2B3DA4AA9008 blend=0x07010701 mode=4
|
|
4 ps=0x5773DC18083C4C20 blend=0x07010701 mode=6
|
|
|
|
# blend 0x07010701 = colour and alpha both src*ONE + dst*(1-SRC_ALPHA)
|
|
# blend 0x00010001 = colour and alpha both src*ONE + dst*ZERO (a replace/clear)
|
|
# BlendFactor: 0=ZERO 1=ONE 7=ONE_MINUS_SRC_ALPHA (xenos.h:751)
|
|
# EdramMode: 4=kColorDepth 6=kCopy (xenos.h:929)
|