Doom-Ed

Bad news.

It looks like this is when “unsupported” really becomes unsupported

Glquake and QuakeWorld were fun to do, but keeping the datasets compatable with quake 1 really has held me back a lot. I badly wanted to get one more release out, but circumstances have forced me to finally ireversibly break with compatability, and I just don’t have the time to devote any effort to a stagnant codebase. You probably wont see any more releases from Id until hexen 2 ships. Sorry.

I have given Zoid and Jack Mathews free license to extend and upgrade the QuakeWorld codebase from the last released revision, so this may actually mean that QW receives more attention than I was able to give it.

On the bright side, the new bsp format will offer some great new capabilities that will be apreciated by all:

Greater robustness. Only one bsp tree is built, and no surfaces are generated that weren’t part of the map brushes.

No fixed clipping hull restrictions. You can now set any mins/maxs you like.

You can tell the texture that a trace clips on in the game, so different surface attributes are now possible.

Textures are no longer stored in the bsp file.

Full color lightmaps for glquake. The “surprise” that I mentioned before was colored lighting hacked into glquake in a way that didn’t require a change in the format, but this is better.

If any hard-core add on hackers can present a serious case for additional modifications to the bsp file, now is the time to let me know.

As some of you may know, a port of Quake was demod at apple’s WWDC. Here is the full info:

A couple weeks ago, I got an email saying: “Hey! We heard you are porting quake for WWDC!”.
I replied: “Uh, first I’ve heard of it… I was planning on supporting Quake 2 on it late this year…”

Well, I stole some time and went ahead and did it (mostly last weekend — running tight!). I’m quite happy with how it turned out, and I’m glad it made it for the demos.

It is actually a port of the current research QuakeWorld-merging-into-Quake2 codebase, so it only plays network games at the moment.

It is running through 24 bit display postscript, and doesn’t have the assembly language compiled in, so don’t believe anyone that says it was running faster than under windows. It was a fast demo system. There is a good chance that it will be a bit faster then win32 when I am done with it, because the direct-to-screen API doesn’t require all the locks and unlocks of Direct Draw, and the sound access will avoid the DirectSound penalties, but basically they should be the same.

98% of the support I need for games is present in rhapsody, and now that there is an existing game for it, the remaining decisions can be rationally guided.

I am still going to press the OpenGL issue, which is going to be crucial for future generations of games.

I am definately going to support Quake 2 on rhapsody. I may make a public release of the QuakeWorld demo, but I will probably wait until we get the full screen api working. Omnigroup has a little qspy-like openstep program that we can use with it.

I have gotten several emails speculating that there will now be a native glide port of quake. Here is the straight answer:

I have considered a glide port many times (especially now that the rendering code is in a dll), but I allways reach the conclusion that it wouldn’t be justified.

On the plus side, it could get a 10%-15% speedup over the OpenGL driver without going through too many contortions. Primarily by saving transforms for the lightmap pass and doing tightly packed vertex arrays for the enemy models.

The big drawback is that every codepath that gets added holds back future innovation. Just having software and gl is a lot of work, and I have allready commited to verite support. This is a difficult point for some people to understand, but it is crucially important. The more places I need to rewrite a feature, the less likely I am to put it in. If I only had the opengl version to worry about, Quake 2 would be so much cooler…

Brian Hook has been hired as our new programmer. Brian wrote the glide API for 3dfx, worked on CosmoGL, and wrote a book on 3d programming that he is now horribly embarrased about.