Skip to navigation

Lander on the Acorn Archimedes

In David Braben's own words

A code analysis of the Lander author's own article from The Micro User

Sometimes when you tackle a big disassembly project, you're not the first to go there; for example, when I documented Elite, there were plenty of other people who had already documented aspects of the game, so I didn't go into it completely blind. On the other side of the coin, Revs was a lot more challenging as I couldn't find anything at all to help me along, so I had to work out everything from scratch.

There wasn't much information available for Aviator or Lander either, but both of these games came with an incredibly valuable set of clues, straight from the authors themselves. Aviator's game manual contains a full specification of the flight model, which turned out to be incredibly useful when analysing that part of the code; and although the "manual" for Lander is little more than a few words in the Archimedes application guide, there's a fantastic magazine article in the November 1987 edition The Micro User that more than makes up for it. It even made the cover:

The cover of The Micro User, November 1987

Written by none other than David Braben himself, this article is a run-down of all of Lander's main technical achievements, plus the extra features that make Zarch an even more impressive sequel. It is an absolute goldmine for anyone wanting to understand how Lander and Zarch work; you can read the article on archive.org, and I can highly recommend it.

In the table below, I'll quote the main points of interest from this article, and link to the relevant bits of the source code, and any deep dives that explain things in more detail. So not only can you read David Braben's descriptions of this epic game, but you can follow along with the relevant source code as well.

QuoteDetails

"Also speed considerations restricted the direction of view to a constant (to avoid the overhead of additional rotating and clipping), although on very early versions of the game this was not the case (this code was used to produce the Union Jack demo, which can rotate about any axis)."

"With the display technique chosen, the frame rate dictated the approximate number of tiles which could be used and also the amount of scenery. The display looks much better if these are greatly increased - as the picture on this page shows - but sadly this reduces the frame rate to only one or two frames per second - a succession of stills."

  • Configuration variables: TILES_X and TILES_Z

"To avoid flickering bank-switching, which uses two screens with all plotting being done to the hidden one, is used. They are switched when a frame is finished. However, this requires twice as much screen memory."

"Both Lander and Zarch use Mode 13, a 256 colour equivalent of Mode 1. There was almost no choice as to the screen mode to use, since 256 colours gives the required scope for shading and lighting, and there is no (hardware) lower resolution with this number of colours available."

"The graphics on Zarch and Lander are quite simple. The hidden line removal routine uses an Elite-like method to filter out some of the triangles..."

"...and then depth sorts all the graphic elements, including particles before plotting them. This means that shapes go in front of each other in the correct fashion.

The best general sorting algorithms such as quicksort, take of order n log(n) steps, and are still a bit slow. However, since objects only need to be approximately in order, and it is known that the values are in a certain range, a technique known as bin sorting is used.

This involves having a buffer for each of a range of depth values, and when an object's position is calculated it is put into the relevant buffer. Finally the buffers are flushed in depth order, farthest first. This requires a great deal of memory, but is virtually free as far as time considerations go."

"Another technique used is colour keying the depth. This is clearly trivial, but gives a good effect and is achieved by varying levels of white according to the depth of an object in the screen.

This is actually not what would be seen - colour tends to be lost in the distance - but is more effective than the rounding towards grey that might be expected. With only 256 colours the steps seem more blatant with, for example, red suddenly becoming grey."

"Shadows are almost essential; it is surprisingly hard to judge height without them. They are also quite easy to simulate if you are allowed a little artistic licence. Firstly each node of each shape is projected on to the landscape vertically, for speed, then they are projected to the screen in the normal fashion, and joined up with black triangles.

This method is clearly incorrect since it does not allow for the curve of the landscape, nor does it allow for scenery - no, shadows don't go over houses or other shapes."

"All shapes are lit from above and slightly to the left to give a better 3D effect, and to emphasise the shadows. This is done by calculating the angle between a light ray and each face of the shape. The brightness of the face is then some function of that angle. Lander and Zarch use:

Brightness = k * SIN(angle)

FaceColour = BaseColour + Brightness * White

Where k is the number of shades available for lighting, and White is the smallest amount of white available."

"The object routine has a list of objects, each of which have a list of attributes including position, velocity and a driving routine pointer. This makes the code very simple indeed."

"The driving routines are called every game cycle for each object, and these routines, different for each object type, take care of the behaviour of that object. This leaves the object routine loop to do such things common to all as plotting and hit checking."

"The particle routine, although similar in principle to the object routine, has more compact data, and rather than call a routine for each particle, each has a flags word with each bit determining some aspect of its behaviour."

"The landscape routine obtains the rolling hillside effect by simply adding a set of pseudo-random sine waves, which are clipped at a fixed height to give the water. As a look-up table is used to calculate the sine values, this technique is very fast."

"The landscape is a bit too uniform without the water, which of course is very easy to add."

"[Talking about Zarch] It is very hard to play at first. The mouse controls are very different to other games, but once you get the hang of flying the craft it is quite satisfying - and there is scope for some fancy flying."

"[Talking about Zarch demo mode] This requires less than a screenful of ARM (Basic assembler) source code, admittedly using multi-statement lines (single statement lines are for people with shares in timber companies, or weenies who insist on writing a paragraph of comments on each instruction)."

  • This entire documented source code project is an example of weenie code, I guess! My apologies... :-)