Jupiter Lander

01 · The screens

The four screens

The game holds four pictures of the same canyon. $E1C4 decides which one is on screen from where the lander is. Each picture is 38 cells across and 23 rows deep, and each is drawn here from its own stream of bytes, in the game's own character set, at two screen pixels to one.

02 · The pads

The pads

Three places in the world accept a landing. Each one is a single line of world Y and a range of world X, and each carries a painted multiplier that the bonus is counted through.

From $E3E7: three bytes of Y low, three of Y high, then the X minimum and maximum the same way. $E3B5 wants the Y to match exactly, and the X to be at or above the minimum and below the maximum. Each range is 48 world units wide, which is the lander sprite with doubling switched on.

The marker in each picture is that world Y turned into a screen row. The sprite's top edge sits at the world Y less 50, the lander's lowest pixels are in its 21st row, so its feet are 21 pixels lower in the wide view and 42 in a close-up. All six markers land on the top edge of a run of character $07, the flat ledge glyph.

03 · Compression

Every run in a stream

One block per pair, in the order the painter reads them, each block as wide as the run is long. The whole strip is 874 cells.

The x2 plateau stands in open sky and its rock is a single wedge, so half its screen is one blank character repeated and its runs are the longest of the four. That is the whole of why its stream is the smallest.

04 · How it works

The zoom

Flying between zones swaps which picture is painted. The terrain itself is never scaled. All four screens were drawn separately and stored separately, and each close-up has its own rock, its own ledges and its own Commodore badge cut out of the cliff. What the zoom changes is how the lander is placed on top. In the wide view the world coordinates are halved and the sprite is drawn at its ordinary 24 by 21 pixels. In a close-up the view's origin, from the table at $E1BB, is subtracted at full scale, and $D017 and $D01D double the sprite in both directions. The same sprite data serves both sizes.

The format

Each stream is a list of pairs. The first byte of a pair is a count, the second is a character code, and the painter at $EC72 writes that character that many times before reading the next pair. A count of zero ends the stream. Cells run left to right and row by row, 38 to a row for 23 rows, which leaves the last two columns of the 40-column screen for the speed gauge. Colour is decided by the character code alone, so the data carries none of its own. The four streams lie end to end from $EEB8 to $F253: 924 bytes for 3,496 cells.