Files
Sylpheed/docs/re/f6-unit7-one-moving-quad.md
sylph-decoder fd3d936427 re: F6 unit 7 -- the title has exactly ONE moving quad; the lights are in the texture
The port raised a real caveat: my earlier scans filtered on height (>1.2
NDC) and sample count (>=20), so a population of many small lights would
have been invisible to both by construction. Dropping both filters, over
the whole title era: 59 distinct shapes, 2 moving, 57 static, and ZERO
small moving shapes. The two moving keys are the rounding-split halves of
one element, pteff03.

So there is exactly one moving quad on the title, 883x1134 px.

That answers the human's actual uncertainty -- whether the game renders one
light per line or one light covering several close lines. It is the second:
the multiple lights are painted INTO the texture of a single large sweeping
sprite, not drawn as separate moving objects. A port reproducing "several
lights" as several elements would be modelling the wrong thing.

The port's caveat was right to raise and the check excludes the population
it warned about -- third time in this exchange that asking was worth it
even when the specific worry did not apply.

What I have NOT done, and it was the literal ask: the human asked for
screenshots and I have taken none. I answered the counting question from
the draw stream because it is the stronger instrument for how-many and
how-big -- it reads the guest's vertex buffer rather than pixels and cannot
miss a faint light. But "what do the lights look like" is a question about
an image and the draw stream cannot answer it. That remains open.

Reach: one boot, one window, every quad in the stream. Static elements are
not counted as lights -- 57 exist and some may pulse in place; this unit
counts motion, not brightness.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:57:07 +00:00

62 lines
2.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# F6 unit 7 — the title has exactly **ONE moving quad**: the lights are inside the texture
**Status: ✅ measured ⟨capture⟩ ×1.** 2026-09-02.
**Question:** how many distinct moving quads does the title draw, and how big?
**Look at:** every quad, no size and no sample-count filter.
**Not covered:** screenshots as images; what the lights look like.
---
The port raised a real caveat: my earlier scans filtered on height (>1.2 NDC) and
on sample count (≥20), so a population of many **small** lights would have been
invisible to both by construction. Dropping both filters:
```
title era, ALL quads distinct shapes: 59
MOVING: 2
static: 57
moving shapes:
1.38 x 3.15 NDC (883 x 1134 px) n=1140 dx 3.38
1.39 x 3.15 NDC (890 x 1134 px) n= 614 dx 3.37
SMALL moving shapes (<0.5 NDC both axes): 0
```
> **Two moving keys, and they are the two rounding-split halves of one element —
> `pteff03`. There is exactly one moving quad on the title, and not a single small
> one.**
## 🔴 That answers the human's actual uncertainty
They said they could not tell whether the game renders **one light per line** or
**one light covering several close lines**. It is the second:
> **One quad, 883 × 1134 px, sweeping across. The multiple lights the human sees
> are painted INTO its texture, not drawn as separate moving objects.**
A port trying to reproduce "several lights" as several elements would be modelling
the wrong thing — the game moves one large sprite whose image already contains the
traces.
📌 The port's caveat was right to raise and the check excludes the population it
warned about. Third time in this exchange that pattern has held: **asking was
worth it even when the specific worry turned out not to apply.**
## ⚠️ What I have NOT done, and it was the literal ask
The human asked for **screenshots** of the title. I have not taken any. I answered
the counting question from the draw stream instead, because it is a stronger
instrument for *how many and how big* — it reads the guest's own vertex buffer
rather than pixels, and it cannot miss a faint light the way an image can.
**But "what do the lights look like" is a question about an image, and the draw
stream cannot answer it.** If that is what is wanted, it is a separate deliverable
and it is still open.
## Reach
⟨capture⟩ ×1, one boot, the title era of one window, every quad in the stream.
Static elements are not counted as lights here — 57 of them exist and some may be
glows that pulse in place rather than travel; **this unit counts motion, not
brightness.**