Strife: Doom Engine
[Update: Looks like a lot of what I say in this post is false. See the comments.]
Strife is the only game on my stack that uses the Doom engine, so let’s talk a little about what that means.
Back in 1994, I spent a few months working for one of Id Software’s competitors, Looking Glass Technologies, working on their texture-mapping routines. Given the coordinates of a polygon and their corresponding positions in a texture image, we had to render the the texture onto the polygon in perspective as fast as possible. These days, this sort of operation would be handled in hardware and abstracted through a library like Direct3D or OpenGL, but we didn’t have those things. Instead, we wrote highly-optimized code to loop over the polygon, scanline by scanline, find the appropriate point in the texture, and copy the pixel color over.
Overdraw was our nemesis: each polygon was expensive enough to render that it was a big waste whenever we rendered a polygon that was covered up by something else. Even when a polygon was only partly covered-up, it was worthwhile to try to figure out how much of it was visible and only render that part.
Sometime in the middle of all this, Doom was released. It was clear that it didn’t have all the capabilities of our library — we were rendering polygons in perspective at arbitrary angles, while Doom seemed to be only capable of horizontal and vertical surfaces, and could only rotate the camera about a vertical axis (no tilting up or down). But it was really fast. Faster, in fact, than could be entirely explained by the simplification made possible by using only horizontal and vertical surfaces. Add to this the complication that they were using highly irregular map layouts: instead of using a grid of map tiles, like Wolfenstein 3D or Ultima Underworld or System Shock, the map was a collection of walls of arbitrary length at arbitrary angles, which more or less defeats the means we had been using to eliminate overdraw.
By now, the secrets are well known. They had in fact managed to completely eliminate overdraw through a single stroke of genius: they didn’t render polygons at all. They rendered the entire scene at once, in vertical scanlines. For each horizontal position, the engine goes pixel by pixel, rendering ceiling until it hits wall, then rendering wall until it hits floor. I’m glossing over a lot of details, but that’s the essence of the Doom engine right there.
This has a couple of consequences. For one thing, it’s basically impossible for a Doom-engine game to take advantage of modern 3D hardware, because modern 3D hardware is all about rendering polygons. I can imagine someone making a Direct3D version of System Shock by taking the source code and remapping all the graphics functions to Direct3D equivalents. It might not be a perfect fit, but I imagine it would be doable with a little massaging. But there’s basically nothing in the Doom engine that even vaguely resembles a Direct3D call.
Second, the fact that the view was always horizontal in Doom wasn’t just a matter of the programmers not bothering to implement it, as with jumping and crouching. It is in principle impossible for the Doom engine to tilt the camera, because that would ruin the vertical scanlines — suddenly you’d have them intersecing the edges of walls and so forth.
And yet, Strife allows the player to look up and down. It manages this by cheating: instead of tilting the camera up, all it really does is render a higher-up slice of the same horizontal view. This isn’t quite the same thing as moving the camera upward. Rather, it’s an unnaturally distorted view, more like what you’d get by taking a photograph with the camera tilted and then looking at the photograph at an oblique angle, or something like that. (I’ll try to find or make some illustrations explaining this better.)
It’s easy to interpret this distortion as mere perspective, though, unless you’re really close to something, which makes it more noticable.