>> Sunday, July 31, 2011
It's a sad fact, but almost inevitable that the last wave of games on any console are technically superior and criminally overlooked as the next generation of hardware swings into view. Released in 1997 well after many considered CD-i commercially dead, 'Atlantis' proved the black box still had some life left in her. As a first person shooter it surprised many with fast paced action and a nifty 'CD Swap' feature allowing you to play any Music CD through the CD-i whilst hammering away at the game! Requiring little persuasion from Black Moon the chief programmer Paul Clarke describes his time raising Atlantis...
If you work in and around Philips and CD-i then you will uncover a lot of really fantastic people. Philips as a company, and an endeavour like CD-i in particular, attracts and gets the most out of great, talented, people. Johnny is a good example of that, though there are many, many others. Although I left Philips in '99 I still keep in touch with lots of Philips guys, though I had lost touch with the ADS boys. I meet up with the rest of the research group I worked in from Philips Research Labs, Redhill each year. There are lots of great CD-i tech-heads there, though they are working on other things now of course.
Soon after joining Philips Research I developed a Non-Intrusive Real-time Debugger (affectionately known as the NIRD, pronounced "Nerd"). This was a really cool piece of kit and software that allowed us to debug CD-i titles (mostly games) in real-time by snooping the expansion bus of the player and understanding what was going on. So for a while I worked researching the feasibility of doing this, then developing the hardware, on-board software, and PC host software to make the system fly. Then I got into refining it and using it at CD-i title developers in UK, Europe and US - helping high-profile titles get to the market on time. The NIRD became a product from Philips Media that they sold to development houses and used themselves. Through doing this work I got right into the detail of how CD-i worked and it's most intricate levels; for example knowing which memory areas operated fastest, how to make every bus cycle count, etc.
In our spare time, usually friday lunchtimes, we played games. This was considered okay as we were in the Interactive Systems Group of the labs, and understanding what people do in their homes and with what kit was really important. It also fitted with our research work around set-top boxes, digital video recorders, virtual reality user interfaces, artificial intelligence, etc. One of the games we played was of course Doom on the PC, though Philips also bought us each new console as it came out to play with.
I got into creating a few Doom levels with the public domain level editors, and the public specs of these allowed me write a utility to extract Doom graphics out of the WAD files. As a coder interested in putting together and refining game engines, the most frustrating thing is often the rubbish graphics that we can produce. By borrowing the Doom graphics I could make the demo 3D engine look cool too, and this ensured I got some attention from Philips Media. I also wrote a utility to allow me to use the public domain Doom level editors to lay out level designs for my engine, rather than have to write a level design tool. Simple hacked utilities like this meant that I could focus on the tricks I would need to do to get reasonable playable performance (15 - 25 fps) out of the engine, rather than work on graphics, sound or level designers like most game developers have to.
When Philips Media agreed to publish a game, I started working with the ADS boys. I could write a lot about this but Johnny has already said a lot. They were a good bunch of guys, really committed to the art of getting the best game play, graphics and performance possible out of CD-i. It was gut wrenching to see the team pulled apart as we learned that Atlantis would be the last game they produced.
Regarding the DOOM demos I put together, I need to be clear. I wrote my own 3D engine that had a number of tricks / compromises to allow it to run at over 15 fps to get playability right. I'll cover some of these below, but it meant that actually, in terms of game comparison, the Atlantis 3D engine was weaker than ID's Doom predecessor Wolfenstein (ie there is no height element, no stairs, no lifts, etc, just a flat world). At that time the Doom code wasn't public domain, and we would never have been able to get it running fast enough if it had been, so to be clear Doom never ran on CD-i. What we did have was a custom 3D engine allowing you to run around a world filled with Doom graphics, wall textures, yes the baddies, and status bar. That's what Johnny meant. It allowed me to concentrate on the code and produce demo's which looked cool. Years later, when the Doom code was made publically available by Id, we did port it to some experimental Set Top Boxes, and that was really cool. Doom on a big TV with descent speakers was just great.
When we were deciding what to do with my 3D engine, I did discuss with Dave Mac (mentioned by Johnny) about talking to Id about a Wolf3D port. However, we put gameplay first and this meant a number of tricks (yes I'm coming to them) that meant it wouldn't have worked. I did produce a demo of my engine with Wolf3D graphics to illustrate the point but we didn't take it further.
3D Engine: The 3D engine itself is a fairly standard "ray caster" that effectively uses a map data structure as a data source together with the players position and orientation, and produces a data structure across the width of the screen showing for each "column" of the screen the distance to the wall (which drives the height of the wall to render), the texture ID (which directs you to the correct texture bitmap tile to render) and the texture column (which is the vertical slice of the texture tile to render). Yes, it was written in C, optimised to hell, and had assembler inserts in a couple of places. The NIRD was used to validate that every cycle was optimised - but fortunately the C compiler for CD-i used together with the right types of variables (to drive 16-bit or 32-bit data access) produced tight code.
Attack of the N.I.R.D: The ADS team paid tribute to the power of N.I.R.D in this touching credit screen from Arcade Classics. The definition of N.I.R.D is Non-Intrusive Real-time Debugger! Rendering and tricks: This is the area which makes or breaks a game, and where the vast majority of CPU time is spent. The key reason why you can't just port Wolf3D or Doom to CD-i is that the 68070 processor on the CD-i player just can't write full screens made of textures and sprites to the screen fast enough due to simple math around the processor and the amount of video memory required to be accessed, read (textures) and written (video).
Version 1 of the rendering engine worked at about 1 fps, which is clearly unusable. Through experimentation and optimisation I ended up with a solution that gave playable game play above 15fps. To do this we used the two video planes of CD-i. The background plane is used to display the wall textures, plus ceiling, plus floor. We used the power of the CD-i hardware to mirror the ceiling with the floor around the mid-point of the screen. So, you only write the top half of the screen, and the CD-i hardware mirrors it down onto the bottom half of the screen. That means that you are now only rendering half the amount of video memory which takes half the time. We also ran that video plane at half resolution (again assisted by CD-i hardware). So actually, we were rendering just quarter the height of a full video screen, and half the width. The pixel doubling took it back to half height and full width, and the mirroring made it full height and full width.
On levels where we had horizon detail (such as the first level with the monuments in the background), and on others where we graduated the floor or ceiling to give the illusion of light, we changed the palette on a line by line basis, which is something that the CD-i system does in hardware for free from a CPU perspective. The foreground video plane was used for sprites, status bar, etc and ran at full resolution to ensure the baddies, bullets, etc, were as high quality as possible. Optimised renderers were written in assembly code for both background and foreground to get the speed up.
I believe it is these tricks using the video hardware such as pixel doubling, mirroring, palette changing, and transparency between planes that Dave Mac was alluding to in the magazine. They cost no CPU power at all once set up at the start of the level, and reduce the amount of time the CPU needs to spend rendering per frame. However, as the walls are mirrored top to bottom, we could not do games like Wolf3D. The demo we did produced predictably odd swastika's and Hitler wall tiles. Fun, but wasn't going to go anywhere.
Memory: Different memory banks work at different speeds, and in particular the expansion memory on the DV cartridge ran faster than the rest of the memory. We used this carefully for certain things, such as rendering code (run often) and textures (read often during rendering). Monster AI: I wrote a language (Sprite Behaviour Language, or SBL) to express monster AI in, and a compiler to convert it to optimal machine code. This allowed us to express actions as keywords that were easy to read such as look, shoot, move, etc and get a richness of AI.
Sound: A great guy called Chris Thorne wrote all the music and did all the sound FX. I was part of his interview process that brought him and other designers into Philips as we sought to break ground in design around all sorts of home-based technology. You should track him down as he is an interesting guy. We had good video and audio studios at Philips Research and Chris augmented this with additional kit and software that gave him what he needed. There was talk of an audio CD to accompany Atlantis (as with Burn:Cycle [which was debugged with the NIRD]), but it was decided not to follow through with this. Chris did produce a demo, and it was fantastic, but it never got released. I have a copy, but don’t see how I can share due to copyright reasons. Shame, it is really really cool.
Cyber-chute bonus levels: While on holiday in Cyprus, in the middle of game production, I was lying in the sun wondering how to improve the game. All of the levels have orthogonal walls, but the rendering engine itself could render curved walls as all it needed to blit the screen was a data structure of wall texture IDs, distance (to scale the wall), and column number of the texture. Whilst CD-I couldn’t work out these details for a curved world in real-time it struck me that there might be a way of doing this offline for bonus levels. I might have been a bit of a spod then, but even I didn’t take a calculator on holiday. So, in long-hand and a touristy notebook I worked out in long-hand a way to do the bonus chute drops between level themes. Basically I found a way of cramming the “view” of a drop chute at so many positions across it (can’t remember how many) in a real-time stream of data from the CD at so many fps. So, the CD-I can stream 75 2k sectors per second from the CD. Effectively it streamed off all the data the renderer needed to know for so many positions across a drop chute in real-time. You then know the user’s position across the width of the cute, and constrain how this position can move per frame, and you have the means to have an interesting segway level. With my notes in hand I hacked some data and wrote the renderer the day after my leave. I had a clever student working with me (Jain Shah) and got him to write a PC tool to do all the offline tool work to build the real levels and associated data structures, and the scheme worked really well. It works a bit like the really old chute drop games. You’re moving inexorably downwards through a complex shape and have to miss bumping into the walls to gain max points.
The experience: Working on RamRaid (the online version) and the Atlantis were some of the most enjoyable work days of my life. With little design brief the creativity in the team ran free. The ADS guys were crazy guys committed to the art of game design and game play. Paul Reid, mentioned in Johnny’s interview, was a great guy absolutely committed to the team. Andy Morton and Tom Drummond were very odd but amazing game guru’s who were kind enough to accept me into their world. Johnny was amazing, and brought my 3D world on CD-i to life. Fire up your CD-i player, and just look at the graphics that he produced, and enjoy the DV clips that we did with Rak. In particular, look at Johnny’s sprites, and savour their animation frames, especially their death sequences. Every frame is a joy.
In another parallel universe the investment in CD-i and its successors continues and ADS is thriving, with the lads and myself happily hacking things to blow peoples minds, give them a thrill, and make the more technical wonder how we do that.
Many thanks to Paul Clarke for his statement & With KUDOS to Johnny Wood for the fantastic artwork submissions. This is part of The Black Moon Project