From f5069b0f64e43cdad81efa773539b794ab39f096 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 18 Aug 2026 17:15:51 +0000 Subject: [PATCH] docs/re: neither existing Canary hook can capture the title screen's draw order MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The paint-order item's remaining step is a per-draw capture, and the obvious move is to reuse the RE instrumentation already compiled into the Canary build on `sylpheed-re`. Read the source rather than assume: neither hook works here. `--log_draws` de-dups by vertex-declaration fingerprint, so a screen's sprites collapse to one record; it carries no texture identity and only first-seen order. The F10 ship capture does keep submission order and would separate the elements, but it returns early on any draw without an `f32x3` position stream — the comment says "UI/effects — skip" in as many words. So the item needs a new cvar-gated hook and a `build-canary` run. Stated in the entry so the cost is known before someone starts, and so this reading is not repeated. --- docs/re/BACKLOG.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 99a0f5cf..9c057702 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -99,6 +99,29 @@ now either identical to the declaration table or refuted by the capture. The nex step is no longer static — it is either the guest code that walks this table, or a per-draw capture of the title screen showing the order the game submits. +**Blocker, checked rather than assumed.** The obvious move is to reuse Canary's +existing RE instrumentation, which is already in the built binary on +`sylpheed-re`. Neither hook can answer this: + +- **`--log_draws`** (`command_processor.cc`) de-dups by a *vertex-declaration + fingerprint* — shader hash + primitive type + per-stream element + formats/offsets + index-buffer guest base — and writes each distinct one once. + A screen's sprites share a declaration, so they collapse; and the record + carries no texture identity and no per-frame submission order, only first-seen + order. It is a mesh-format log, not a draw-order log. +- **The F10 ship capture** does preserve per-draw order within a frame and + de-dups on `(vertex base, WVP transform, index range)`, which would separate + the elements — but it **explicitly drops UI draws**: + `if (pos_off_bytes < 0 …) return; // no float-position stream (UI/effects) — + skip`. It requires an `f32x3` position attribute, which a 2D quad stream does + not have. + +So this needs a **new hook in Canary** — log each draw in submission order with +its bound texture fetch (or its screen-space quad), gated behind a cvar the way +the other two are — and therefore a `build-canary` run. That is the cost to +state up front rather than discover halfway in; it is not a container +limitation, just a long build plus a title-screen run. + ## Capital ships assemble wrong in the viewer