A level on horseback

I wanted a level that scrolls fast, a ride in the style of Ivanhoe, with depth. Sky in the background, then distant mountains, a sea, and a foreground of grass streaming under the hooves. Each layer moves at its own speed: the ground scrolls fast, the sea follows more calmly, the mountains barely move. That is the parallax effect, the one that gives the illusion you're really crossing a landscape, and I wanted to push it as far as it would go on both my target machines, the STe and the STf.

On paper it's stacked depth. In practice, on the Atari ST, sliding several layers at different speeds without breaking the image is the whole subject. So I started with an isolated prototype, outside the game, to validate the idea before integrating it. This post is about that prototype.

The prototype in motion: over the fixed sky, the mountain, the sea and the ground scroll at three different speeds. A capture of the prototype running on STe as well as STf, at 50 Hz, in 1 MB.

The hardware reflex, and its trap

The STe can shift its display by a few pixels on its own, effortlessly, thanks to its hardware scroll. The obvious idea: give every layer its own offset and let the machine do the work. Zero extra memory, perfectly smooth.

I wrote it. In the emulator it was perfect. Pixel-accurate scroll on every layer, smooth, nothing to complain about.

Except that pushing that hardware scroll this far, mid-display, is a minefield. I remembered an old flicker, so before going any further I checked real demos and real games to settle it. The clearest answer comes from a well-known demo from 1990: its author writes, word for word, that he has never seen this type of scroll work correctly on all STs, that he came across a good fifteen different machine configurations, and that if you see flicker it means you have a model he couldn't test.

There is the verdict, from a professional: this pushed hardware scroll depends on tiny variations between individual Atari STs. It works on my machine, it will work badly on others. The emulator doesn't reproduce those variations, so it was lying to me by omission. For a game that has to run everywhere, that shortcut had to go.

Prepare the images ahead of time, but not the whole scene

The reliable technique, the one used by real games that scroll cleanly, is to prepare the shifted versions of the scenery once and for all, at startup, then do nothing but copies, which are far cheaper. Fine scrolling becomes a simple choice among ready-made images. No hardware acrobatics.

My first pass prepared the entire scene in all its shifted positions. Smooth, reliable, and a megabyte of memory all by itself. On a machine with a single megabyte, that is dead on arrival.

The lesson from real games is that you never prepare a full-screen scene: you prepare the bare minimum. Hence the real fix: prepare each layer separately, with just the fineness it needs. A slow layer needs fine granularity, because the eye freezes every small step. A fast layer does not, because the eye doesn't freeze an image that is streaming past. The sky is a gradient: scrolling it changes nothing on screen, so a single copy is enough.

By matching fineness to the speed of each layer like this, I went from a megabyte to a little over half of that, and there is room left for the rest of the game.

STe and STf: the same images, two ways of placing them

On the STe, I let the machine point each layer at the right ready-made image, layer by layer, mid-display. Three moving layers over a fixed sky, smooth at full speed.

One defect appeared when I cut the scene into bands: a thin stray line at the join between two layers. It was a one-line overflow at the moment the machine changes layer. In a single scene it landed on the neighbouring scenery and was invisible. In separate bands it showed. I extended each image by a few lines of margin so that the overflow shows a simple continuation of the scenery, and the stray line disappeared.

The STf, for its part, cannot shift its image on its own: it has to be recomposed by hand, every frame. But the images prepared ahead of time are already there, exactly the same ones as on the STe. So the STf only has to copy the right image into the right place, without recomputing anything.

Recomposing every full-width layer on every frame is nevertheless too heavy for the STf, which would drop to half speed. So I made a deliberate game design choice: on the STf, I freeze the two slowest layers, the sky and the mountain, and only let the sea and the ground move. Two layers of depth instead of three, but full speed. The STf therefore runs at the same cadence as the STe.

Taking stock

What is delivered: a prototype of a horseback level with depth, holding up on STe and STf, at full speed on both sides, without flicker and without tearing. The code is solid, and above all reliable on real hardware, not just in the emulator.

The moral joins the one from the STf port: on the Atari ST, the hardware offers gorgeous shortcuts that don't always keep their promises across every version. The safe route is often the most down to earth, here copying images prepared ahead of time rather than asking the machine for a tour de force mid-display.

The prototype is downloadable here as an .st floppy image. Mount it as floppy A in Hatari, in STe mode to see the three layers scroll, or in STf mode for the two-moving-layer version: it's the same file, it detects the machine by itself. Any key quits. For the current version of the game, see the homepage.