Skip to content

Let a meteor move independently

  • Sinclair ZX Spectrum
  • Assembly

A meteor should keep approaching whether the player moves, hesitates or holds both keys. Give it its own position, then update that position on the same clock as the ship.

This checkpoint adds meteor_x, meteor_y and active. Restart puts the meteor at (116,24) and sets active to 1. The ship still starts at (116,160). They happen to share an X coordinate; they do not share a position variable.

Source · view and edit
ZX Spectrum
Companion file: assets.inc

The include line reads this editable data when you assemble. Keep it beside your source for a local build.

Edit the source, then assemble.

Edits are saved in this browser. Keep a downloaded copy of work you want to keep.

Focus the Spectrum screen to use the keyboard, or hold these buttons. Assemble again for a fresh machine.

Run the program to inspect it. Editing source does not change the running machine.

ship_x
—
meteor_x
—
meteor_y
—
active
—
phase
—

At this stage contact does nothing. Leave the ship still and let the meteor pass through it. Move on a second run and check that neither the meteor’s X nor its downward speed follows you. R restarts both objects.

Update the state, then the picture

After moving the ship, the loop checks active. Zero means there is no meteor to update. For an active meteor it calls meteor to XOR away the old image, adds three to meteor_y, and either retires it or draws at the new position.

meteor supplies its own X/Y, meteor_sprites and twelve rows to the drawing helper. The table still reserves sixteen rows per shift block, so the existing 64-byte offset calculation remains valid. The companion file now includes both artworks.

A Y coordinate of 174 or greater retires the object: active becomes zero, phase becomes 3, and CLEAR SPACE appears. We remove it before drawing there. That keeps the whole twelve-row image within the play area above the control line.

Calculate an arrival

The meteor travels from y=24 towards retirement at y=174: a distance of 150 pixels. At three pixels per update, that is fifty updates. At 25 updates per second, it lasts two seconds after it is first drawn.

To test a different speed, replace add a,3 immediately after ld a,(meteor_y) with add a,2. Do not change the ship’s ld e,2. Predict seventy-five updates, or three seconds, then run. The two speed values belong to different objects.

At five pixels per update, could retirement rely on y being exactly 174? Would that be a good general rule?

Show the explanation

This particular distance divides by five, so it would reach 174. But at four pixels per update it would go from 172 to 176. A test for equality could miss the boundary forever. CP followed by the greater-than-or-equal branch retires an object that reaches or passes the boundary.

The counter and active flag decide what exists. A leftover picture is a drawing error, not proof that the object is still active. Conversely, clearing pixels without clearing active would leave an invisible object that keeps updating. Those two mistakes will matter once contact can end the run.

Sources

The maintained Meteor Storm source linked through this page supplies the game rules and data layout. Its experiments run original Z80 instructions on an emulated 48K PAL Spectrum; the game rules are design choices, not hardware properties.

Run it here

This unit's program, built for you.

Program
meteor-storm.tap
Machine
ZX Spectrum 48K (PAL)

Download meteor-storm.tap