Lazer Bars

Lazer Bars is a single-screen shooter where the player maneuvers a character across a fixed landscape, shooting upward at invaders while dodging laser bars that descend from above. The player uses six keys for movement (left, right, up, down) and firing in two horizontal directions plus a vertical shot. Four UDGs are defined: two invader sprites (UDGs B and D, loaded via POKE USR loops from DATA statements), a bullet character (UDG c, a thin vertical line via BIN 00011000), and a laser-bar character (UDG E, BIN 00010100). Collision detection relies on ATTR and SCREEN$ checks—ATTR value 106 flags a laser hit and 52 flags solid ground—triggering a life-loss subroutine at line 900 with a three-tone beep penalty. Scoring accumulates via variables j (a multiplier incremented every 16 sub-points) and s, displayed as (16×j)+s.

---

Program Structure

The program divides into clearly distinct phases:

1. Introduction (lines 30–99): Title screen, gameplay explanation, controls screen, and a demonstration beep sequence for the life-loss sound.
2. UDG Setup (lines 120–290): Four UDGs are defined using POKE USR loops and DATA/BIN literals.
3. Initialization (lines 310–350): Variables, lives, score, and the static playfield are set up.
4. Main Game Loop (lines 360–490): Draws laser bars, reads input, checks collisions, and loops back.
5. Subroutines (lines 500–830): Firing (500), drop-down (600), jump-up (700), and laser-drop enemy (800).
6. Life-loss and Game Over (lines 900–1100): Life penalty, game-over sequence, replay prompt, and farewell screen.

UDG Definitions

Four User-Defined Graphics are created before gameplay begins:

UDG	Usage	Method
\b (UDG B)	Invader sprite	8-byte DATA: 126,90,60,126,90,66,66,129
\d (UDG D)	Player sprite	8-byte DATA: 36,66,153,153,90,126,189,255
\c (UDG c)	Bullet/laser visual	BIN 00011000 repeated 8 rows
\e (UDG E)	Player’s upward shot	BIN 00010100 repeated 8 rows

Note the mixed case: uppercase UDGs (B, D, E) are accessed via POKE USR "B"+a style indexing, while lowercase c uses POKE USR "c"+a, both valid on the Spectrum where UDGs span from ‘A’ through lowercase letters.

Main Game Loop

The loop begins at line 360 (targeted by GO TO 360 at line 451) and runs through line 490 before jumping back to line 420. Invader bars are drawn across row 7 at every even column (line 370–390). The player sprite UDG D is printed at position (m,l), where m is the row (vertical) and l is the column (horizontal). After processing input and subroutines, the player position is redrawn and the loop continues.

The loop actually has two entry points: line 360 (after score update) and line 420 (normal iteration). This means invader bars are only redrawn when the score milestone triggers the branch at line 451, not every frame—a performance optimization at the cost of some visual consistency.

Collision Detection

Collision is detected using two BASIC functions:

• ATTR (m-1,l)=106 — checks the attribute of the cell above the player. Value 106 corresponds to INK 2 (red), PAPER 5 (cyan), BRIGHT 1, which matches the laser-drop character drawn at line 810.
• ATTR (m-1,l)=52 — value 52 corresponds to PAPER 6, INK 4 (the ground/ceiling color), blocking upward movement.
• SCREEN$ (u-1,l)<>" " — used in the firing subroutine (line 530) to detect when the bullet hits something non-blank, scoring a hit.

Scoring System

The score is stored as two variables: s (sub-score, 0–15) and j (a multiplier). Every time s exceeds 15, j is incremented and s resets (line 451). The displayed score is always (16*j)+s, effectively making the score a 16-based counter. This is an unusual but functional way to avoid a single large integer variable while showing a meaningful running total.

Subroutines

Line	Function	Notes
500	Fire upward	Loops UDG E from player row up to row 6; uses OVER 1 at line 550 to erase; awards score on non-blank hit
600	Drop down	Guards against ATTR 52 below; calls subroutine 700 if the cell just vacated is non-blank (bumping head)
700	Jump up	Guards against ATTR 52 above and row limit (m<=10); moves player one row up
800	Enemy laser drop	Triggered randomly (1-in-50 chance per frame); drops UDG c (BRIGHT 1, INK 2) from row 8 to player row
900	Life loss	Plays three-tone penalty beep, decrements life, displays remaining lives; branches to 1000 on zero lives

Notable Techniques and Idioms

• OVER 1 erasure (line 550): The bullet UDG is erased by reprinting it with OVER 1, which XORs the pixels back to zero without needing to explicitly blank the cell — a classic Spectrum graphics trick.
• Horizontal blast (lines 462–463): Keys 3 and 8 print a space character to the left or right of the player respectively, with a short beep — a very minimal “blast” that clears a single adjacent character-cell. The left blast uses l-l (which equals 0) rather than the intended l-1, making it always print at column 0, which is a bug.
• Random enemy trigger (line 470): IF INT(RND*50)=5 gives approximately a 2% chance per loop iteration of spawning a laser drop — simple and effective for difficulty scaling.
• Line 815 LET t=t: This is a no-op assignment (t equals itself) and has no effect; it appears to be a vestigial placeholder, possibly intended for horizontal laser drift that was never implemented.
• Line 801 RANDOMIZE without argument: Called at the start of the enemy subroutine to re-seed the random number generator each time an enemy drops, increasing variability in column placement.
• Boundary clamping: Left boundary is clamped at line 425 (l<0 THEN LET l=0) and right at line 479 (l>=31 THEN LET l=31), but these checks are separated from the movement lines by other logic, meaning a single frame can show the player briefly out of bounds before correction.
• Game-over flash (line 1010): The player sprite is reprinted with INK 2; FLASH 1 at death, providing a visual cue without additional animation code.

Bugs and Anomalies

• Left blast column bug (line 462): PRINT AT m,l-l;" " computes l-l=0, so the blast always clears column 0 regardless of player position. The intended expression was almost certainly l-1.
• Line 800 is never called (lines 470 vs 801): The random trigger at line 470 calls GO SUB 800, but the subroutine code begins at line 801, not 800. Since there is no line 800, this will cause a “Line does not exist” error at runtime — the game cannot spawn enemy lasers.
• Double initialization of life: LET life=3 appears at both line 310 and line 320, making the line 310 assignment redundant.
• Score display gap (line 435): The score header “SCORE= ” is printed every frame, but the score value itself is only updated inside subroutine 500, leading to a static label with a delayed value update.
• Subroutine 900 entered as GO SUB 900 but coded from line 910: Line 900 does not exist; execution would fall through to line 910. This is a valid (if unusual) technique — BASIC finds the next line after 900, which is 910 — so this works correctly in practice.