starkernel: item 4.3.4 -- checkpoint, draw a cube (no new bugs)

Adds VERT/EDGE/CUBE to capsules/fabric.4th (blocks 4913-4915). VERT
( n -- x y z ) reads bits 0/1/2 of a corner index as the X/Y/Z sign
(+-CS from center), so all 8 cube corners come from one word. EDGE
resolves both corners via VERT and calls LINE; CUBE is 12 EDGE calls
(4 bottom, 4 top, 4 vertical).

First item in the 4.3.3.x sequence with no new bug found -- a small signal
that Q.TO-INT, the VARIABLE alignment fix, and the LINE-STUCK? cap were
the real gaps rather than something still lurking in LINE/PROJECT/CART-Y.

Verified live on amd64: a centered, half-size-100 cube renders correctly
-- front/back face squares, back face offset diagonally up-right by
exactly the 45-degree cavalier projection's depth term, all 12 edges
connecting at the right corners.

All three architectures boot clean to ok> with the DoE completing;
dict_hash identical across all three and unchanged from 4.3.3a/4.3.3b.

FABRIC.md item 4.3.4 marked done. This is the checkpoint -- 4.3.x
groundwork stops here for review per this item's own acceptance criterion.
This commit is contained in:
Robert Allan James
2026-08-07 15:29:04 -04:00
parent a3fe0702eb
commit fa300ef4c6
4 changed files with 66 additions and 16 deletions
+21 -1
View File
@@ -3797,10 +3797,30 @@ document and committing that amendment as its own item.*
> than tall, matching unequal radii), and the earlier diagonal `LINE` test.
> `fb/amd64/geom-test-circle-fixed.png`, `fb/amd64/geom-test-full-wordset.png`.
- [ ] **4.3.4 — Checkpoint: draw a cube.** First real exercise of the 4.3.3/4.3.3a/4.3.3b
- [x] **4.3.4 — Checkpoint: draw a cube.** First real exercise of the 4.3.3/4.3.3a/4.3.3b
coordinate/projection/geometry machinery — cube edges use `LINE`. Stop and review here
before scoping the next 4.3.x item — not expected to be fast. *Refs:* §27.4.
> **Done, 2026-08-07.** Block 49134915. Vertices are bit-coded: `VERT ( n -- x y z )`
> reads bits 0/1/2 of `n` as the sign of the X/Y/Z offset from center (`±CS`), so all 8
> corners come from one word instead of 8 hand-written coordinate triples. `EDGE
> ( n1 n2 color -- )` resolves both corners via `VERT` and calls `LINE`. `CUBE
> ( cx cy cz s color -- )` is 12 `EDGE` calls — 4 bottom, 4 top, 4 vertical — grouped by
> face for readability, not because the grouping means anything to the machinery.
>
> No new bugs this item — first time in the 4.3.3.x sequence that's been true, which is
> itself a small signal that `Q.TO-INT`/the `VARIABLE` alignment fix/the `LINE-STUCK?`
> cap were the real gaps, not something still lurking in `LINE`/`PROJECT`/`CART-Y`.
>
> **Verified live on amd64**: `640 400 0 100 16777215 CUBE` (white, half-size 100,
> centered mid-screen) completed cleanly, no errors, no `LINE-STUCK?` trips. Screendump
> (`fb/amd64/cube-4.3.4.png`) shows a correct wireframe cube — front face square, back
> face square offset diagonally up-right by exactly the 45° cavalier projection's
> depth term, all 12 edges connecting at the right corners, no crossed or broken lines.
>
> **This is the checkpoint** — 4.3.x groundwork stops here for review per this item's own
> acceptance criterion, before scoping whatever comes next.
*(4.3.x is open-ended — more items get appended here as Console work is scoped item by*
*item, developed on the fly per §25.0. 4.4 below is unaffected by anything added above*
*this marker.)*