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 of The Micro User that more than makes up for it. It even made the cover:
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.
| Quote | Details |
|---|---|
"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." |
|
"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. |
|
"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. |
|
"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. |
|
"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: |
|
"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)." |
|