Files
Sylpheed/tools/canary-patches/0002-RE-Raise-the-UI-draw-capture-s-vertex-dump-from-8-to.patch
sylph-decoder 3f114a28af tools: export ALL FOUR container-only Canary commits, not just my own
Applying my own lesson to my own corpus rather than only stating it. I
exported the content-hash patch and stopped; auditing the docs for
"/canary sha" citations found three pages naming d90d14e02, and checking
/canary's history found the exposure is four commits deep, not one.

Bounded by measurement rather than guess: branch -r --contains puts
590912722 on origin/sylpheed-re and finds no remote for anything after it,
so the container-only stack is exactly these four.

  0f920e645  blend= per draw          <- the ENTIRE blend decode rests on this
  fa1e4c221  vertex dump 8 -> 64      <- at 8 the log silently dropped four
                                         quads of the EXTRAS 24-index batch
  d90d14e02  RT state, resolves, PS constants
  ab3203f79  h= content hash

The sharpest case is 0f920e645. Without it a draw log records no blend
state at all, so ui-blend-mode-decoded.md's 35-element oracle -- which
overturned a REFUTED entry and deleted the port's authored blend map --
could not be re-derived by anyone who cloned this repository.

The failure mode is silent: the recipe LOOKS complete and only fails for
someone on a different machine, long after its author could say what the
flag did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:59:14 +00:00

37 lines
1.8 KiB
Diff

From fa1e4c22147b2d9138f43a946559e9512d1e2a36 Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Mon, 31 Aug 2026 07:00:16 +0000
Subject: [PATCH 2/4] [RE] Raise the UI draw capture's vertex dump from 8 to 64
8 vertices is TWO QUADS. A batched UI draw carries more: on Project Sylpheed's
EXTRAS screen one 24-index draw holds six sprites, and truncating at 8 reported
the first two while ptframe4, pteff21, pteff22 and pteff23 looked like elements
the game never draws at all. A cap that hides geometry is worse than a long
line, because the missing rows do not announce themselves.
---
src/xenia/gpu/command_processor.cc | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/xenia/gpu/command_processor.cc b/src/xenia/gpu/command_processor.cc
index d389e299c..20e75c6ae 100644
--- a/src/xenia/gpu/command_processor.cc
+++ b/src/xenia/gpu/command_processor.cc
@@ -374,9 +374,15 @@ void CommandProcessor::CaptureUiDrawForRE(
return (uint32_t(q[0]) << 24) | (uint32_t(q[1]) << 16) |
(uint32_t(q[2]) << 8) | uint32_t(q[3]);
};
+ // 🔴 This was 8, and 8 is TWO QUADS. A batched UI draw carries more: on
+ // `EXTRAS` one 24-index draw holds six sprites, and truncating at 8
+ // reported the first two and silently dropped `ptframe4`, `pteff21`,
+ // `pteff22` and `pteff23` — which then looked like elements the game does
+ // not draw at all. A cap that hides geometry is worse than a long line,
+ // because the missing rows do not announce themselves.
uint32_t nv = uint32_t(init.num_indices);
- if (nv > 8) {
- nv = 8;
+ if (nv > 64) {
+ nv = 64;
}
ui_out << fmt::format(" fmt0={} v:", pos_fmt);
for (uint32_t v = 0; v < nv; ++v) {