Tuesday, May 18, 2010

An Interview With Alan Laird

Alan Laird worked on the Sinclair Spectrum and Amstrad CPC conversions of OutRun for Probe Software in 1988. Back in January 2000, I e-mailed him a series of questions about the conversion and he kindly took the time to answer.


I've answered your questions below, its been over 10 years so my memory is a little bit hazy in places.....

Firstly, how large was the team that worked on the Spectrum conversion, and how were the different tasks divided up?

Basically there were two people, Ian Morrison and myself. I've been out of touch with Ian for a number of years now so I don't know what he's doing.

Ian did most of the 3D engine code and I did everything else, but towards the end of the project I was pretty much the only person on the Spectrum version as Ian started working on the ST version.

We also did an Amstrad version based on the Spectrum code and John Bankier helped out with that.

How long did the conversion take?

Don't remember exactly. All I remember was that they wanted a Xmas release and the production house (Probe) got so paranoid about us running late that I ended up spending 2 weeks in their office in London. I think we got it done somewhere around early December after starting in the summer so about 4 or 5 months elapsed, this was whilst attending university, it was a rather stressful time.

Were you initially worried that the Spectrum would not be capable of replicating the original machine, and what were the main difficulties you encountered?

Yes, very worried, but it was too much of an opportunity to pass up. Clearly speed would be a difficulty, Outrun has a lot of graphics on screen so keeping the frame rate up whilst drawing those was difficult. Secondly because we didn't have fancy bitmap scaling hardware like the arcade machine, we had to store each graphic at a range of different sizes. There was a trade off between having enough sizes so that the game looked reasonably smooth and the storage space.

What hardware and software was used to convert the game?

It was developed on a PC based system called PDS that some other game developers had hacked together. This was a pretty decent Z80 assembler/debugger environment and at the time I think we used some flavour of 286 with initially a 10M hard drive. There was a dedicated comms board plugged into the Spectrum and an ISA card in the PC to form a kind of parallel interface between the two. You could squirt the entire assembled code down to the Spectrum in a fraction of a second. Much easier than the previous system using microdrives, multi-part assembles and the interface 1 network.

Were the graphics and sound written from scratch, or were some elements borrowed from the other conversions?

Outrun was really the third in an evolving series of driving games. First we did Nightmare Rally which was an original idea that Ian and I put together and then hawked around games houses before Ocean published it. Off the back of that we got a contract from Activision to convert Enduro Racer. This added the element of a track to the game. And off of that we got the Outrun contract from Probe. At each iteration the graphics engine become more sophisticated. Turbo and Europa were even better, they had much more flexibility in the 3D engine,infinitely variable curves and hills in the road and were getting decent frame rates as well. Sound code always came from third party specialists.

 Nightmare Rally

OutRun

Turbo OutRun

Did you see or work on any of the other conversions, and if so, how do you think they compared?

As mentioned above I had a hand in the Amstrad version and Ian worked on the ST and Amiga versions. Amstrad was always difficult because it had the same processor as the Spectrum but twice as much video memory to move around. Amstrad users also hated getting Spectrum rewrites since they didn't take full advantage of the graphics flexibility. We didn't have much time on the Outrun conversion but Turbo and Europa were pretty decent. The ST and Amiga, although they were 16 bit 68000, still weren't terribly fast pieces of hardware and expectations were much higher so invariably they disappointed.

 
Amstrad CPC Conversion

How did you decide where to draw the line between graphical accuracy and speed? I ask this because the graphical accuracy on the game is outstanding, but one of the main criticisms at the time was that the speed suffered on certain stages.

There was a constant battle between me and the production house (Probe) over graphic density and speed. I wanted the game to look as realistic as possible and since I had full control over designing the course layouts I could put in lots of graphics to make it look good. Of course this brought the frame rate way down, I think it was averaging about 3fps in the end, but this game was never destined to be lightening fast.

A nerdy question: On the back of the OutRun packaging, the Spectrum screenshot is clearly different from the final game. The lorry is much larger and detailed, the sky is shaded differently, and the on-screen statistics are in different places. Why were these changes made, and does a copy of this early version still exist?

I think the graphic on the packaging was a mock up done by an artist so that it could get to the printers on time.

The large graphics were one of the first victims to storage space. We would generate a series of graphics at different scaling factors from full size down to almost nothing in steps of say 10%. What you find is that the largest graphics are only on screen for a fraction of a second as you zoom by something and they take up the most space, so naturally they got dropped pretty quickly. If we'd had the space they could have been left in since they are on screen for such a small amount of time they hardly affected speed.

The multi-loading system used on OutRun was rather complex, as it would load levels into memory as the game progressed, whilst holding as many as possible at one time. Was it developed specifically for OutRun?

Don't really remember too much about this aspect. I think the 48K version could hold about 4 levels at any one time including the most recently played level. So if you took the same route through the game each time you didn't need to reload but if you took a different route you would need to. Again it was down to the space needed by graphics, they just wouldn't all fit at the same time. We did +3 versions of the later games which made the whole thing a lot easier.

Did Turbo Outrun and / or Outrun Europa use the same engine as OutRun, or were they written from scratch?

As I mentioned, they were evolutions of the Outrun engine. By the last one the engine was actually getting quite good. Rendering speed was much faster both for the 3D landscape and the graphical objects. Not bad for such a primitive machine, remember that the Z80 didn't even have hardware multiply and divide operations so imagine how cumbersome doing 3D graphics was. We did everything in fixed precision arithmetic, 8 bit whole part, 8 bit fractional part and implemented multiply and divide using loops. For anything more complex like trig and log functions, we used pre-computed look up tables. Compare with today's Voodoo chipsets or a Dreamcast console, kids nowadays have it easy....

Can you briefly summarise the work that you have done since Spectrum programming?

I finished off my undergraduate degree (in Comp Sci) and then did a postgrad degree. After that I joined Baring Securities (of Nick Leeson fame) which later became ING Barings, working there for 5 years in London and mostly Tokyo. Now I'm with Merrill Lynch in Tokyo managing a development team doing real-time stock trading systems in C++. Ian set up his own games production house call ICE which did Turbo and Europa amongst others. Last I heard, which was about 6 or 7 years ago, he was headed to the States.

I lost interest in home computers for a long time and didn't really play games at all except for the odd arcade driving game until a couple of years ago when I got a couple of Voodoo cards for my work PC and discovered Quake. I've gotten right back into home computers now, although on a slightly different scale, with a network of Sun Sparcstations, a permanent internet connection and my own web sites. Its interesting to do a speed/memory/storage comparison of then and now. I started out with a 1K ZX81 and now I have 256M in my biggest machine, that's a quarter of a million times more memory amongst many other improvements. I still have all the old kit in my attic in London, maybe someday I'll dig it out and see if I can read those old microdrive catridges and floppy disks.

Hope this was interesting, it has been for me going back to those days and from all the interest on the web I see that the old games still live on. Thanks to everyone who's taken the time to collate information, build emulators and collect games.

Alan Laird - 2/1/2000.

Another article regarding the conversion can be found in the following issue of Sinclair User magazine from 1988:


Tuesday, May 11, 2010

OutRun Easter Egg - The Definite Guide!

For a while it's been known that on some versions of OutRun holding the start button, just before a checkpoint, will reveal a secret message: "PROGRAM YU SUZUKI 1986 SEP".


However, it's also been known that this easter egg does not work on all versions of the game.

Well, that's until now. I've decompiled the code related to this and will list the differences below, including how to enable this easter egg on later revisions of the game.

Sitdown/Upright Revision A: This version works as stated. Just before any checkpoint, hold start (just before the sky is due to cycle to the upcoming level colour) to reveal the message. Easy.

Sitdown/Upright Revision B: Activating the egg on this version is more complex. First you will will need to achieve a high score, and enter "YU." as your name, complete with trailing full-stop.


Furthermore, the easter egg can only be activated when transitioning from Stage 2 to Stage 3 on this version of the game. Yes, they've actually included extra code to handle this.



It should also be noted that the egg can only be displayed once and is then deactivated. Also, if the user enters "YU." again on the high score table, the egg will also be deactivated. I'm not certain why this required such a rewrite - it's not as if it allows the user to cheat in the game.

The easter egg code is buried in the middle of a routine to handle setting up the sky palette fade from one level to the next. Which possibly indicates that the programmer wanted to keep the code hidden from more common routines that were shared with the team. I wonder who wrote this piece of code, and why it was heavily altered between revisions?

Aside from that I've completely disassembled the entire service test code - which enabled me to figure out a bunch of minor book keeeping information. I've also disassembled the palette changing code that handles the road, ground and sky when transitioning between levels. I've even disassembled some rather dull code relating to the coin chutes. Next - there's a load of tilemap code to be looked at. The quest continues!

Saturday, May 01, 2010

Service Test

I'm debugging the service test code at the moment. After some of the recent decompilation work, I fancied something easy.  Nevertheless there are still some cool things to be discovered.

One thing you'll notice in MAME, is that the "Motor Test" fails:


The motor test, which only runs if the DIP switches are set to the Moving cabinet type, essentially moves the cabinet from left to right. The limit switches activate at the extremities and the pot values from the motor are recorded. A magnet also detects the centre position.  

I quickly hooked up a simulation of the motor hardware in the Jemu2 driver I coded, using knowledge from the decompilation. Here are the results:

Notice that there are no error messages, and the values are correctly recorded. 

As far as I can see register 0x140001 works as follows:

Bit 3 = Set to indicate left limit reached
Bit 4 = Set to indicate centre reached
Bit 5 = Set to indicate right limit reached

The desired motor position is written to register 0x140003.

The actual motor position can by read by writing '12' to the analogue select register 0x140012.