I'm not familiar with Sim City, but packing all that logic into less than 20k certainly sounds like some feat!
Anyway, these would be my nominations for Beeb technical genius:
Exile
Well... I've raved about Exile so often, and I'd still consider it to be the most impressive technical achievement the Beeb ever saw.
Just considering the amount of 'world', graphics, dynamics and logic which are packed into less than 24k of the Beeb's memory is amazing enough... then considering how the authors achieved this is eye-opening.
The world was mostly generated procedurally from a complex algorithm, which would calculate the piece of scenery for a given (x,y) coordinate. Some complicated areas of the world were mapped 'by hand' and the scenery algorithm would take coordinates in these areas into account and pull return values out of these pre-mapped areas instead.
The sprite routine used by Exile was quite unorthodox. Whereas most Beeb games would effectively store sprites as copies of screen data, and just copy it to screen in the required position, Exile built sprites out of three different-coloured layers, each layer being stored as a flat 1-bit-per-pixel block, rather like a text character. This gave it several advantages:
- Sprites were immediately reduced in size to 75% - using a total of 3 bits-per-pixel instead of the usual 4 bits-per-pixel for Mode 2.
It could easily render sprites at any pixel, horizontally or vertically - essential for its accurate dynamics. This may not sound a big deal, but I can think of very few Beeb games which displayed sprites at any horizontal position.
It could display the three layers in whichever colours were specified, or even turn particular layers off. This meant there was no need to store different-coloured versions of essentially the same sprite. Exile used this extensively, with different coloured monkeys/frogmen using the same sprite data - other examples of sprite data sharing are birds/wasps, keys/RCD, maggots, Triax/protection suit/player, bushes/lightning bolts... I think another ingenious use of the layers was that different frames of animation could be stored in different layers, and these turned on and off in sequence to animate the sprites.
Sprites could be trivially flipped in horizontal or vertical directions, again potentially quartering the amount of sprite data which needed to be stored.
The most astonishing thing about this sprite routine is the fact that it was able to display sprites surprisingly quickly, despite its complexity... as anyone who's played the game can testify, there are frequently large numbers of sprites on-screen, and even if the overall framerate of the game is reduced, there is rarely any flicker.
Another interesting property of this sprite routine is how it deals with overlaying sprites on one another. All game objects are rendered behind the permanent scenery. The way this works is simple but effective: all scenery objects are rendered in colours 8-15. All game objects (sprites) are rendered in colours 0-7. The sprite routine simply looks to see which colour is being plotted onto, and only plots pixels over colours 0-7. This means that scenery is preserved in the foreground, and also means that the same routine can be used to plot and unplot sprites, as plotted pixels are actually EORed with whatever was there before. Occasionally, where two sprites overlap, you can see the tell-tale signs of EOR plotting (a mess of overplotted colours), but of course Exile hides this from the player by very rarely ever allowing sprites to overlap, due to its exceptional collision resolution...
Exile uses some very accurate colour interrupts to provide the water level plotting further on in the game. The water is rendered as a cyan scanline at the surface, followed by blue below. This was achieved by simply changing the background colour palette at the appropriate moment, of course taking into account the screen scrolling - something which is only possible by very accurate timing, and the fact that the game 'took over' the interrupt processing entirely. This technique has been done a few times before, notably Gary Partis' Sphere of Destiny, in order to animate the track, but is worth pointing out nonetheless.
Graphics aside, Exile also had some revolutionary gameplay elements - the object dynamics and collisions are modelled realistically - both collisions with scenery (getting rebound angles perfect) but also collisions between two game objects - and other things such as line-of-sight of characters are also implemented perfectly - quite how it was able to do such things so quickly, when there wasn't even a map stored anywhere, and instead the contents of each scenery tile had to be calculated, I'll never know.
The Exile engine is surprisingly robust, and is able to deal with all sorts of unexpected events. All game objects are created 'equal' and so, for example, the game copes perfectly well with having multiple players in the scene at once if you contrive such a thing. In the case where you litter the world with a number of permanent objects, e.g. keys, there is even code - which is never normally called - which will 'explode' excess litter with a small white flash, to save them from eating up memory and CPU time (even huge numbers of keys in piles perform perfect collision resolution with one another, stacking up like bricks).
Add in the sampled sound on the enhanced version which fits perfectly with the game, and the simple but spot-on sounds for the monkeys, dripping liquid, birds, wasps and the rest... it's a work of virtual perfection.
As you can see, I've spent a lot of time dissecting Exile in the past...
Read more here:
http://exile.acornarcade.com/ (Andrew Weston's tribute site)
Firetrack
Well, I don't have so much to say about Firetrack as I have about Exile
But Mr Pelling certainly put together a tight little package here. I think he was the first to use the 'vertical rupture' technique for pixel-by-pixel vertical scrolling, which is certainly Firetrack's big technical achievement. This technique doesn't necessarily require accurate timing, but Firetrack's method does.
It works by making use of a video chip register which is able to adjust the number of scanlines in a PAL frame line-by-line. Changing its value has the effect of moving the screen up and down by single pixels. However, doing this naively will always result in a huge screen-roll when adjusting it back to its 'base' position again. What Orlando realised was that if he was adding scanlines to the top of the screen, he needed to remove some again further down, and that way the vertical position of the screen could move by pixel amounts as desired, whilst avoiding the 'roll'. The way he achieved this was through very careful timing that effectively created one character block at the bottom of the screen which had extra scanlines added into it, which replaced what had previously been two regular character blocks. (trying to be as non-technical as possible here, but can elaborate if desired!)
Also, I just love the music in Firetrack, and the graphical style with shadows and those nice explosions, is just perfect.
Elite
Well, it has to get a mention really. The hugest technical achievement in Elite for me is the maths behind it. Remembering that it was developed very early on in the Beeb's life, and nothing like it had been attempted before, it was a very brave and groundbreaking product. 6502s are notoriously bad at multiplication and division, so the fact that Bell and Braben were able to do the necessary 3d transforms - rotation and perspective - and also calculate the hidden faces so as not to render hidden lines was a real achievement, considering the speed that game ran at. The pseudo-random seeded galaxy generation is not a big deal particularly for me - but the actual 3d rendering has to be given a mention.