Teach the artwork tutorial the converted listing

Chapter 18 still taught the machinery the listing lost when it moved onto
SOLID and the persistent drawing layer: the frame-boundary PACE routine, the
flattened live list, the SSHAPE pool accounting, and the sixty lines of
BALLBRICKS/TESTCELL that computed a minimum translation axis by hand.

Step 8 now registers each brick with SOLID, arms COLLISION 2 and reads the
contact back with RCOLLISION, including the point that costs an evening if it
is missed: the BUMP mask is by sprite, and the balls are sprites 5, 6 and 7,
so their bits are 16, 32 and 64. The FOR-with-equal-bounds rule that every
one-item case in the chapter depends on is now stated where it is first used
rather than referred to from a step that no longer exists.

The listing loses six declarations orphaned by the conversion and the comment
blocks that still described the captures.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EwxGB6TdoVvZ11KQQME9cL

examples/breakout/sprites/README.md

@@ -48,10 +48,10 @@ dive across the field into a save at both ends.
 ## How it works, and how to write your own
 
 **[Chapter 18 of the guide](../../../docs/18-tutorial-breakout-artwork.md)** builds this
-program in twelve steps: loading artwork, budgeting the eight sprite slots, capturing a
-drawing into one, stamping the brick field, finding the host's frame boundary with `TI#`,
-moving everything that is not drawing out of the deadline, the stroke font, the bounce
-without a square root, and the gems.
+program step by step: loading artwork, budgeting the eight sprite slots, taking the text
+layer out of the way so a drawing can be seen, stamping the brick field, registering the
+bricks as collision geometry, the stroke font, the bounce without a square root, and the
+gems.
 
 [Chapter 17](../../../docs/17-tutorial-breakout.md) does the same for
 [`../characters`](../characters), which builds the same game out of the text grid and two
@@ -71,18 +71,16 @@ Crediting Kenney is not required by CC0. It is here because it should be.
 Named honestly rather than left to be discovered:
 
 - **No music under the game**, only event sounds and two four-note stings. There is room in
-  the third voice for it; there was not much room anywhere else when it was written. 121 of
-  the interpreter's 128 variables are spoken for and the label table is at 61 of 64 —
-  several of them spent working around defects that have since been fixed.
+  the third voice for it; there was not much room anywhere else when it was written. The
+  conversion gave some of that room back — the variable table is under the 128 ceiling with
+  a handful to spare and the label table is at 57 of 64, where it was at 61.
 - **One gem at a time.** There is one sprite slot for it. A brick broken while a gem is
   falling drops nothing.
 - **Sticky and multiball share one offset.** Two balls stuck to the paddle at once sit on
   top of each other. It is rare enough that fixing it would cost a variable I do not have.
-- **The score lags a frame behind the bricks.** Only one capture happens per frame and the
-  field goes first, so a brick disappears one frame before the score that counts it. At
-  thirty frames a second nobody can see it, and it is a deliberate trade rather than an
-  oversight.
 - **No high score on disk.** There is no disk.
+- **No attract mode**, unlike `../characters`. It sits on the title screen until somebody
+  presses space, which also means it cannot test itself unattended the way that one can.
 
 The eight interpreter defects this game turned up are filed in `TODO.md` §9, each with a
 reduction that fits on a screen and the file and line of the cause. **Six are now fixed**
@@ -92,8 +90,14 @@ drawing. The two that stand are the left-operand arithmetic rule, which turned o
 decision rather than a defect and is now documented as one, and the 256-line batch tear,
 which belongs to the host.
 
-**The listing's code is unchanged**, and deliberately: it is what a program written
-against those constraints looks like, and none of the workarounds costs anything now that
-they are not needed. Six separate scalars for six brick stamps, and loops guarded by
-`GOTO` rather than wrapped in a block, are both still what the file does. Its comments say
-which of the five traps stand and which are marked FIXED.
+**The listing has since been converted**, and its header records what went. It used to
+spend two of its eight sprites on the screen itself — an `SSHAPE` of the HUD strip and one
+of the whole play field, because a drawing lasted a single frame and a sprite was the only
+thing redrawn for nothing. A drawing persists now, so both slots are free, the `PACE`
+routine that hunted for a frame boundary is gone with the captures it protected, and the
+flattened live list that made a full-field redraw cheap is gone with the redraw itself: a
+broken brick is erased in place.
+
+What has *not* changed is the shape of the workarounds that no longer cost anything — six
+separate scalars for six brick stamps, loops guarded by `GOTO` rather than wrapped in a
+block. Its comments say which of the five traps still stand and which are marked FIXED.