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

docs: correct the empty ship capture - nothing is broken, there was no ship on screen

Browse Source 
The previous commit framed the empty capture as "the 3D draws never reach
CaptureShipDrawForRE" and proposed a static comparison to find out why. The
comparison was done and it refutes the framing.

The discriminator for ship geometry is stride=24 prim=4 with a large vcount -
xbg7-mesh.md records a real one as stride=24 vcount=10891 indices=18 prim=4. Not
"positions outside the screen rectangle", which is what I used and is a bad test:
a UI sprite placed at (137,308) passes it.

By the correct test this run's capture has exactly one prim=4 draw, a 6-vertex
full-screen quad, and the 2.9 MB file I was comparing against has NO prim=4 draws
at all. That file is a UI capture: 1303 of its 1582 draws are stride=24 prim=13,
which two other docs in this corpus already identify as the UI sprite shader. The
"1300 3D draws" it appeared to contain were UI sprite coordinates counted by the
bad test.

So the capture recorded exactly what was on screen. The tutorial's opening is an
empty starfield, the player's own ship and a HUD - no capital ship. And
ship-placement-runtime-capture.md has always stated the procedure: play into the
mission, frame the ship side-on, press F10.

What remains is therefore not a code question but a gameplay one: reach a real
mission and frame a capital ship. Worth stating that the original capture was
taken interactively on HW Vulkan, and this container runs lavapipe.
This commit is contained in:
Sylpheed RE agent
2026-08-19 13:02:48 +00:00
parent 9b17506c1f
commit ef739ea80d
2 changed files with 47 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/re/BACKLOG.md
View File

@@ -776,8 +776,16 @@ shader, all screen-space, none 3D — against a known-good 2.9 MB capture from a
earlier session. The 8 000-draw budget was not the limit and the scene *was*
rendering. ⚠️ The "cache refuted" claim above is **overstated**: this run used
the same complete cache as `tut4` and got 0 crashes vs 11 497, so variance
dominates. **Next (static, no emulator):** compare this capture's shape against
the known-good one to find why the 3D draws never reach `CaptureShipDrawForRE`. 🔴 The resume-refused lead (1 663 on one
dominates. 🔴 **Corrected:** nothing is broken. Ship
geometry is `stride=24 prim=4` with a large vcount (`vcount=10891` for a real
one); this capture has one `prim=4 vcount=6` quad and the 2.9 MB "known-good"
file has **no `prim=4` at all** — it is a **UI** capture (1 303 of 1 582 draws
are `stride=24 prim=13`, the UI sprite shader). The earlier "3D draws" test
counted UI sprite coordinates as 3D. The capture recorded what was on screen, and
the tutorial's opening has **no capital ship**. **What remains** is what the
capture doc always said: play into a real mission and frame a ship side-on —
gameplay driving, not a menu step, and the original was taken on HW Vulkan where
this container has lavapipe. 🔴 The resume-refused lead (1 663 on one
thread) is **REFUTED**: that thread did execute, and `KeWaitForSingleObject` /
`NtWaitForSingleObjectEx` are `kHighFrequency`, which is unlogged unless
`--log_high_frequency_kernel_calls=true` — so a parked thread is invisible and

42
docs/re/title-crash-stl-tree.md
View File

@@ -441,10 +441,42 @@ So the hook fires, the frame has 3D in it, and none of the 3D reaches the
capture. For comparison, the capture this project already has from an earlier
session is **2.9 MB**.
### 🔴 Correction: nothing is broken — there was no ship to capture
The section above frames the empty capture as "the 3D draws never reach
`CaptureShipDrawForRE`". **That framing is wrong**, and the static comparison it
proposed is what showed it.
**The discriminator for ship geometry is `stride=24 prim=4` with a large
vcount** — `xbg7-mesh.md` records a real one as
`stride=24 vcount=10891 indices=18 prim=4`. Not "positions outside the screen
rectangle", which is what was used above and is a bad test: a UI sprite placed at
(137,308) passes it.
By the correct test:
| capture | `prim=4` draws | verdict |
|---|---|---|
| this run, 329 KB | one, `vcount=6` (a full-screen quad) | no ship geometry |
| `uicap`, **2.9 MB** | **none at all** | no ship geometry either |
So the 2–3 MB files this was being compared against are **UI captures**, not ship
captures: 1 303 of their 1 582 draws are `stride=24 prim=13`, which
[`ui-quad-class-foothold.md`](ui-quad-class-foothold.md) and
[`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md) both identify
as the UI sprite shader. The "1 300 3D draws" they appeared to contain were UI
sprite coordinates counted by the bad test.
The capture recorded exactly what was on screen. The tutorial's opening is an
empty starfield, the player's own ship and a HUD — **there is no capital ship in
it**. [`ship-placement-runtime-capture.md`](ship-placement-runtime-capture.md)
states the procedure plainly and always did: *"Play into the mission, frame the
ship side-on, press F10."*
### Next
Find why. `CaptureShipDrawForRE` is called from one place in
`command_processor.cc`; the question is whether the 3D scene's draws go through
that path at all in this build, or whether they are being deduped away. Comparing
the shape of this file against the known-good 2.9 MB one is the cheap first step,
and does not need the emulator.
Not a code question. A second capital-ship capture needs a **capital ship on
screen**, which means driving real gameplay in a real mission (`STAGE01` via LOAD
GAME) far enough to frame one — a much larger ask than a menu step, and the
original capture was taken interactively on **HW Vulkan** where this container
has lavapipe. That is the honest size of what remains.