Doom-Ed

I want to apologize for some of the posturing that has taken place in .plan files.

I have asked that attacks on our competition no longer apear in .plan files here. I don’t think it is proper or dignified.

If everyone clearly understood that an individual’s opinion is only that — the opinion of a single individual, I wouldn’t have bothered. Unfortunately, opinions tend to be spread over the entire group, and I am not confortable with how this makes me perceived.

Building up animosity between developers is not a very worthwhile thing.

A little chest-beating doesn’t really hurt anything, but putting down other developers has negative consequences.

I think that we have a track record that we can be proud of here at id, but we are far from perfect, and I would prefer to cast no stones.

The user community often exerts a lot of pressure towards confrontation, though. People like to pick a “side”, and there are plenty of people interested in fighting over it. There are a lot of people that dislike id software for no reason other than they have chosen another “side”. I don’t want to encourage that.

Magazine articles are usually the trigger for someone getting upset here. Its annoying to have something you are directly involved in misrepresented in some way for all the world to see. However, I have been misquoted enough by the press to make me assume that many inflamatory comments are taken out of context or otherwise massaged. It makes a good story, after all.

Sure, there ARE developers that really do think they are going to wipe us off the face of the earth with their next product, and don’t mind telling everyone all about it. Its allways possible. They can give it their best shot, and we’ll give it ours. If they do anything better, we’ll learn from it.

I get asked about the DOOM source code every once in a while, so here is a full status update:

The Wolfenstein code wasn’t much of a service to release — it was 16 bit dos code, and there wasn’t much you could do with it. Hell, I don’t think it even compiled as released.

The DOOM code should be a lot more interesting. It is better written, 32 bit, and portable. There are several interesting projects that immediately present themselves for working with the code. GLDOOM and a packet server based internet DOOM spring to mind. Even a client/server based DOOM server wouldn’t be too hard to do.

I originally intended to just dump the code on the net quite some time ago, but Bernd Kreimeier offered to write a book to explain the way the game works. There have been a ton of issues holding it up, but that is still the plan. If things aren’t worked out by the end of the year, I will just release things in a raw form, though.

My best case situation would be to release code that cleanly builds for win32 and linux. Bernd is doing some cleanup on the code, and some of the Ritual guys may lend a hand.

One of the big issues is that we used someone else’s sound code in dos DOOM (ohmygod was that a big mistake!), so we can’t just release the full code directory. We will probably build something off of the quake sound code for the release.

I think I am going to be able to get away with just making all the code public domain. No license, no copyleft, nothing. If you apreciate it, try to get a pirate or two to buy some of our stuff legit…

I went to siggraph last monday to give a talk about realtime graphics for entertainment.

The only real reason I agreed to the talk (I have turned down all other offers in the past) was because Shigeru Miyamoto was supposed to be on the panel representing console software. Id software was really conceived when me, Tom, and Romero made a Super Mario 3 clone after I figured out how to do smooth scrolling EGA games. We actually sent it to nintendo to see if they wanted to publish a PC game, but the interest wasn’t there. We wound up doing the Commander Keen games for Apogee instead, and the rest is history.

I was looking forward to meeting Mr. Miyamoto, but he wound up canceling at the last minute.

Oh well. I hope everyone that went enjoyed my talk. All the other speakers had powerpoint presentations and detailed discussion plans, but I just rambled for an hour…

I notced that there was a report about my discussion of model level of detail that was in error. I have an experimental harness, an algorithm, and a data structure for doing progressive mesh style LOD rendereing in the quake engine, but I suspect it won’t make it into the production Quake 2. Other things are higher priority for us. I may assist some of the quake licensees if they want to pursue it later.

—

A couple data / feature changes going into the latest (and I hope final) revision of the Quake bsp file format:

Back in my update a month ago where I discussed losing automatic frame animation in models to clean up the format and logic, I mentioned that I still supported automatic texture animation.

Not anymore. There were several obnoxious internal details to dealing with it, especially now with textures outside the bsp file, so I changed the aproach.

When a texture is grabbed, you can now specify another texture name as the next animation in a chain. Much better than the implicit-by-name specification form Quake1.

No animation is automatic now. A bmodel’s frame number determines how far along the animation chain to go to find the frame. Textures without animation chains just stay in the original frame.

There is a slight cost in network traffic required to update frame numbers on otherwise unmoving objects, but due to the QuakeWorld style delta compression it is still less thatn a Quake 1 scene with no motion at all.

The benefit, aside from internal code cleanliness, is that a game can precisely control any sequence of animation on a surface. You could have cycles that go forward and backwards through a sequence, you could make slide projectors that only change on specific inputs, etc.

You could not independantly animate two sides of a bmodel that were not syncronized with the same number of frames, but you could allways split it into multiple models if your really needed to.

Everything is simple when its done, but I actually agonized over animation specification for HOURS yesterday…

The last significant thing that I am working on in the map format is leaf clustering for vis operations. You can specify some map brushes as “detail” brushes, and others as “structural” brushes. The BSP and portal list is built for just the structural brushes, then the detail brushes are filtered in later.

This saves a bit of space, but is primarily for allowing complex levels to vis in a reasonable amount of time. The vis operation is very sensitive to complexity in open areas, and usually has an exponentially bad falloff time. Most of the complexity is in the form of small brushes that never really occlude anything. A box room with ten torch holders on the walls would consist of several dozen mostly open leafs. If the torch holders were made detail brushes, the room would just be a single leaf.

A detail / structural seperation is also, I believe, key to making a portal renderer workable. I had a version of Quake that used portals at the convex volume level, and the performance characteristics had considerably worse-than-linear falloff with complexity. By reducing the leaf count considerably, it probably becomes very workable. I will certainly be reevaluating it for trinity.