From: "Jim Dose'" email@example.com
Subject: GL Doom
Date: Tue, 2 Dec 1997 15:43:59 -0600
X-Mailer: Microsoft Internet E-mail/MAPI - 220.127.116.1111
I've been a right bastard about not keeping up with my GL Doom email, so I thought I'd send a general email out to everyone who asked. I lost all my e-mail a while back when my hard drive crashed, so if you know someone who asked but never got a reply, please let them know I wasn't trying to blow them off. :)
I haven't had as much time lately to really work on the conversion. I currently have the renderer drawing the walls and floors as texture spans as the are in the software renderer. There's lighting on the walls, but not the floors, and sprites are being drawn, but not with the right texture. I figure that this is one nights work to get the game looking "normal". I haven't tested the game on less than a p200, so I'm not sure how it will perform under the average machine, but I don't expect it to be blindingly fast because of the number of spans that have to be drawn each frame. Rendering as polys is definitely the way to go.
The reason I chose to do spans first was because it left the base renderer intact and I could concentrate on ironing out any Windows compatibility problems. Actually, the first version I had running was simply a blit of the 320x200 game screen through Open GL. Surprisingly, this actually was very playable, but certainly wasn't taking any advantage of 3D acceleration. Once the game was running, I started converting all the span routines over.
One problem with drawing spans is that the engine doesn't calculate the texture coordinates with fractional accuracy, so the bilinear filtering works vertically, but not horizontally on the walls. I may try to fix this, but since I plan to use polys for the final version, it's not really high priority. Also, spans don't really allow for looking up and down.
When I tackle the conversion to polys, one big problem I'll encounter is drawing floors. Since the world is stored in a 2D bsp tree, there is no information on the shape of the floors. In fact the floors can be concave and may include holes (typically, most renderers break concave polys down into a collection of convex polys or triangles). In software, the floors are actually drawn using an algorithm that's similar to a flood fill (except that a list of open spans is kept instead of a buffer of pixels). This makes drawing the floors as polys fairly difficult.
One method I may use to draw the floors as polys was suggested by Billy Zelsnack of Rebel Boat Rocker when we were working at 3D Realms together a few years ago. Basically, Billy was designing an engine that dealt with the world in a 2D portal format similar to the one that Build used, except that it had true looking up and down (no shearing). Since floors were basically implicit and could be concave, Billy drew them as if the walls extended downwards to infinity, but fixed the texture coordinates to appear that they were on the plane of the floor. The effect was that you could look up and down and there were no gaps or overdraw. It's a fairly clever method and allows you to store the world in a simpler data format. Had perspective texture mapping been fast enough back then, both Build and Doom could have done this in software.
Frequently asked questions:
"What 3D cards will GL Doom run on?"
Basically, it should run on anything that GLQuake does, since I'm developing under the same mini-driver. It will also run under software GL, but only fast enough for screen shots.
"Will I be able to play it under NT?"
I'm developing this under NT and 95, which pretty much covers the majority of users.
"Will a version be out for Linux?"
When I'm done, the code will be available for anyone who wants to port it to other platforms or APIs (someone could do a D3D version, for example). This is up to Id, of course, since I don't own the rights to the Doom source code, but I believe that John was planning on releasing it sometime after Quake 2 was released.
"Don't add mlook since it changes the game!"
Looking up & down will probably be a command-line option. It will only work in multiplayer if everyone selects it (to be fair to everyone).
"Did you know there's a Doom TC for Quake?"
Yes, and I can't wait to play it, but Doom is Doom, and it just isn't the same.
"Can I have a copy?/Can I be a beta-tester?"
I won't be giving any copies out to anyone until I've got a reasonably impressive looking version done. Plus, I will only release them with Id's approval, since, although they are not developing it, it will be percieved as their product and as such I wouldn't want to release it unless they were happy with the image it represents. As far as beta-testing goes, there will probably be a public beta, similar to GL Quake.
"Will there be an 8 player version?"
Maybe. It does add more net traffic, but it shouldn't be more than most LANs can handle.
"How about internet play, ala Quake?"
Joining requires a client/server style network engine and right now that would be a fairly big change. I can see this being done by someone on the net when the code is released, but I don't wish to take that one on myself.
Anyway, that's enough for now. Thanks to everyone for all the encouraging email!
Ritual Entertainment, Inc.