`HITTEST`, `XBRICK` and `YBRICK` are gone -- about forty lines that divided
pixels by cell sizes to recover a grid index, tested the ball's leading edge
rather than its box, and could miss a brick clipped at the corner by seven
pixels' worth of ball. In their place: sixty `SOLID` rectangles registered as the
wall is built, `COLLISION 2, BRICKHIT`, and a fifteen-line handler.
The handler reads better than what it replaces because it asks rather than
derives. `RCOLLISION(1, 1)` is which brick -- the id is the array index plus one,
so nothing is looked up. Fields 2, 3 and 4 are the way out and how far, so the
ball is pushed exactly clear instead of being restored to a remembered `OX#`/`OY#`.
Field 7 is which axis to reverse, which `TESTCELL` in the other game computes by
hand from an overlap rectangle.
`MOVEBAL` loses its two brick calls and its position backup. `KILLBR` retires the
rectangle in the same breath as clearing the array element, so the next frame
cannot hit a brick that is no longer drawn.
**A latent defect in the target prescan had to be fixed first, and `RCOLLISION`
is the first name in the language to reach it.** `src/renumber.c` walks a line
character by character looking for `GOTO`, `GOSUB`, `COLLISION` and the rest, and
checked only the character *after* a match -- so `RCOLLISION(1, 1)` found
`COLLISION` at its second character, read the `(1,` that followed as a handler
line number, and refused the whole program with "branch to line 1, which the
program did not number", naming a line that contains no branch at all. It now
requires a word boundary on both sides. The comment there was already right that
the trailing check protects `GOTOX#`; nothing protected `XGOTO#`.
`tests/unnumbered.c` covers all three shapes and TODO.md section 6 item 42
records it.
The game runs ninety seconds headless with no error line and the attract mode
scores 1320, so bricks are being found and broken through the new path.
Chapter 17 is not updated yet -- that is the other half of section 6 item 39, and
it is a bigger edit than this one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EwxGB6TdoVvZ11KQQME9cL
GOTO 100 in a script written without line numbers finds the hundredth line
and branches there. Silent, plausible and wrong: the test for it loops
forever printing the second line when the check is removed.
akbasic_runtime_check_targets() is a fourth prescan beside the label, DATA
and TYPE ones, run on every entry into MODE_RUN -- the earliest the check
can be made and the only place all four ways a program arrives pass
through. A target naming an empty line is still allowed, for the same
reason RENUMBER leaves one alone, and a fully numbered program is
unaffected, which is every program that existed before this.
It shares RENUMBER's walk rather than repeating it. renumber.c grows an
akbasic_TargetWalk -- a self pointer and a visit function -- and
rewrite_line() takes one. RENUMBER's visitor substitutes the number a line
moved to; the check's substitutes the number unchanged and raises. One
walk, so the two cannot disagree about what a branch target is.
The check points environment->lineno at the line being walked so the "? N :"
prefix names the offending line. The other three prescans do not and report
whichever line the loader stopped on; TODO.md section 5 item 64 records it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A script written against LABEL and GOTO NAME never names a line number, so
the numbers it had to carry were decoration. akbasic_runtime_load(),
RUNSTREAM and DLOAD now file an unnumbered line one slot after the last one
filed; a numbered line is filed under its number and moves the cursor, so
the two mix. akbasic_runtime_file_line() is the one implementation of that
rule, so the three paths cannot drift.
The prompt is untouched. A line typed without a number is still direct mode
and still runs now -- that is the only thing separating program text from a
statement at a REPL, and it is why this is a loading feature.
What this replaces was silent data loss: an unnumbered line was filed under
the cursor unchanged, on top of the line before it. A blank line therefore
erased whatever preceded it, and RUNSTREAM did not skip blank lines the way
the other two paths did.
That moves one golden file, and the reference had the same defect.
language/arithmetic/integer.bas has four PRINT statements, an expectation
with three values, and a trailing blank line that erased 40 PRINT 4 - 2
before the program ran. The expectation is now 4 4 2 2.
tests/reference/README.md records the divergence and TODO.md section 5 item
63 says why.
akbasic_SourceLine grows a `numbered` flag so an assigned number can be told
from a written one. RENUMBER sets it on every line it touches; NEW, DELETE
and DLOAD clear it. hadlinenumber moves to akbasic_scanner_scan(), so it
always describes the line just scanned rather than only the REPL's.
Two lines carrying the same written number still keep the last, as they
always have. That is a separate decision.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
