id_notes/John C/1997-01-12_1997-05-22
[idsoftware.com]
Login name: johnc In real life: John Carmack
Directory: /raid/nardo/johnc Shell: /bin/csh
Last login Tue Feb 18 18:02 on ttyp2 from idnewt
Plan:
Ok, off the soapbox and back to normal id stuff...
============================
Jan 12
We now have someone officially in charge of quake/quakeworld unix ports:
Dave 'Zoid' Kirsch.
zoid@threewave.com
Direct any correspondance about the linux ports of quake to him. If any
other unix vendors would like to have quake ported to their environments,
set up an equipment loan with him.
This is a volenteer position, so don't give him a hard time.
============================
Jan 22
A preliminary release of glquake and the 3dfx driver has been put on our
ftp site in the idstuff/unsup directory.
one hour later...
3dfx gave me a new vxd for glquake that fixes crashing problems on some
pentium pro systems. glquake1.zip now contains the current files.
============================
Jan 25
I fixed a couple problems in glquake with some addon stuff -- the goats
demo actually showed up a crashing problem with 256*256 textures, and the
rangers demos showed that players with non-player models and colormaps
were all messed up.
I'll make another release when 3dfx has their next driver drop finished.
============================
Jan 31
I went down to the ferrari dealership today with Ann and American with the
intention of buying a new f355 as a "sensible" car (in contrast to my
other twin turbo monstrosities).
There was an F40 sitting out front.
Umm. Sensible car. F40. Sensible car. F40. Hmmmm.
American played the evil conscience and Ann played the good conscience.
For a while. Then Ann got infected by the Dark Side. :-) I bought the
F40.
Ok, I now have too many ferraris. I have a plan to fix that. This hasn't
gone through all the legal crap necessary yet, but it is my intention to
give away my first ferrari as the grand prize of a Quake tournement.
Yes, I am serious.
DO NOT SEND ME ANY MAIL ABOUT THIS! When we have more to say about it, we
will make a formal announcement. This would be a good time to start a
heated debate in the newsgroups about what the fairest tourney rules would
be, though.
The specs:
1987 328 GTS with turbocharged engine.
Feature in the january, 1994 issue of Turbo magazine.
Made 360 HP at the rear wheels on a chassis dyno.
New engine (I melted the first one...), new paint.
The interior could use a little work.
I plan to also include enough cash to cover tax and insurance.
============================
Feb 5
I've been following the ferrari discussion on r.g.c.q, and here are a
couple clarifications:
The final rounds will definately be one on one deathmatch over a LAN,
probably double elimination.
The big question is how do we get the number of people who would like to
take a shot at it down to a reasonable (64?) number of people for a proper
tournement.
We don't know yet where the final rounds are going to be held, either.
E3? #Quakecon? A microsoft event? A totally specific event?
I know that whatever we come up with won't be 100% fair to our entire
customer base, but it would be really unfortunate if some people got
bitter over it.
============================
Feb 13
There will be a new QuakeWorld release soon with a very different
interface and several improvements.
On the topic of network gaming, I have a couple questions that I would
like answered by anyone with the required technical knowledge:
If I understand correctly, UDP headers are currently not compressed over
PPP links like TCP headers commonly are. During a network game (or
internet phone or videoconference), all the packets are just between two
addresses, but tons of bandwidth (and corresponding latency) is eaten by
sending full headers. Has anyone developed UDP header compression
extensions, and if so, how common are they?
On a lower hardware level, have any modem manufacturers considered
optimizing interfaces or protocols for lower packet latency? Once again,
if I understand correctly, modem transmission involves a level of
packetizing for modulation/protocol/compression work that is underneath
the serial interface seen by a computer. Do partially filled buffers sit
idle for a time if there isn't a continuous stream of data, or do they
immediately flush when a byte failes to clock in? It would be nice to be
able to explicitly syncronize with UDP packets, because a realtime game
running within bandwidth limits is going to send and receive discrete
packets interspersed with idle time, which is not really what modems are
optimized for now. I know that modem data compression is generally a bad
thing for low latency connections right now, but if the modem could be
signaled to flush at UDP boundaries, it would probably become a positive
thing. I'm sure there are also things that could be done at the
modulation/protocol layer to improve latency at some cost in bandwidth or
error rate, but I have no idea if it could be done compatably.
It would be an interesting point of differentiation for ISP's or modem
manufacturers if an "optimize for games" checkbox was available somewhere.
Even at the os level, a "max packets buffered" option would be valuable to
keep packets from piling up when bandwidth is overcommited.
Comments?
============================
Feb 18
Ferrari update. Unless someone can come up with a compelling objection, I
think we have an end plan now:
Intergraph is currently holding a very cool clan tournement that will have
the finals at E3. The ClanRing guys are managing the tournement, and
intergraph is picking up the bill. It's going to be great, with clan
banners and projection screens. They allready have a pretty good prize
lineup of cash and systems.
The current proposal is to expand the event to include one on one
deathmatches in addition to the clan fights. The grand prize will be my
328. I don't think it would go over too well to have a ferrari as clan
property :-)
Intergraph is willing to pay for travel and accomadations for twelve to
sixteen contestants.
We still need to figure out how to select the finalists. The idea is
that we can tell all the press types about the event now, and have a
last-minute runnoff of some sort the month before E3. That way even
people who aren't usually active on the internet can find out about it
through a magazine and take a shot at it.
============================
Feb 19
I made significant improvements to the scalability of QuakeWorld. You
have probably noticed how a 16 player game is a lot worse over a modem
than a 4 player game, even when you aren't around the action. All of
those factors are now gone, so big games play a lot better now, and I have
bumped the maximum players to 32. There aren't really any levels that
will be reasonable with that many players, but if someone wants to create
one, it should be possible now. (obviously you are still going to go slow
if all 32 people decide to congregate in the same room)
The next release of QuakeWorld is going to be completely incompatable with
the current release. Both the client and server have changed protocols,
and the fate of the master server is still undecided.
I have one more really significant thing to try with the network protocols
that I should probably hold up the release for, because it would be yet
another incompatable change.
============================
Feb 23
I took an entire day and a half off from work to spend some quality time
with my F40 at Texas World Speedway. I had a lovely moment pitching my
quarter million dollar car off the track backwards (no harm done), but
otherwise I had a great time. Back to work now.
I should have updates of both QuakeWorld and GlQuake within a week. QW is
crapping out at 27 players for some reason (rather difficult to debug...),
and glquake needs a fix for the hipnotic level pack to work.
My next project is to define a new rendering architecture that will clean
a bunch of stuff up and allow me to combine regular quake, glquake, and a
windows version of vquake into a single executable. I plan on doing the
development work with QW, so I won't be stepping on Michael or Cash's toes
as I go hacking and slashing through the codebase. If everything goes
well, that will become the new guts of Quake 2, and I will probably also
release a unified Quake 1 executable.
============================
Mar 12
The new glquake is on ftp.idsoftware.com. It should work for both the
hipnotic pack and the upcoming rogue pack.
/idstuff/unsup/glq3_11.zip
============================
Mar 12
Ok, this really pisses me off:
Date: Wed, 12 Mar 1997 13:32:43 +0100 From: "%Peter Lawrenz" <%Lawrenz@bln.de>
Reply-To: %Lawrenz@bln.de X-Mailer: Mozilla 3.01 (Win95; I)
To: johnc@idsoftware.com
Subject: Re: E3/Ferrari Event PRESS RELEASE
Will Bryant wrote:
> John Carmack, the co-founder of id Software and creator of the game QUAKE,
> will give away one of his four Ferraris as the grand prize: a red 1987
> Ferrari 328 GTS with a Norwood Autocraft turbo conversion. According to
> Carmack, donating the Ferrari is his way of giving something back to the
> game enthusiasts that have brought him success. "I bought my first Ferrari
> after the success of Wolfenstein-3D," said Carmack. "DOOM and QUAKE have
> bought three more. Four Ferraris is too many for me. Rather than sell off
> one of them or stick it in a warehouse, I'm going to give it back to the
> gamers that brought it to me in the first place. The king of this QUAKE
> deathmatch is going to get a really cool crown."
> "This is the biggest, hottest tournament ever for PC gamers, and we
> encourage all QUAKE players to give it their best shot," said Wade
> Tournament Registration and Contact Information
> QUAKE players who want to participate in the tournament can register online
> at http://www.mpog.com/e3signup.html, anytime between March 24 and May 2,
> 1997. Participation is limited to US residents 18 years of age and older,
> other rules are posted on the Website.
Hi,
the two above statements contradict each other. How many ferraries
would you have been able to buy if the sales of your games were
limited to U.S. only ? It seems to me that you don't value your
oversea customers at all and invite them to pirate future ID
software products.
I paid for Doom I, Doom II and Quake and since this press release I
am not really sure if I should spend any more money on ID software.
There are other companies that might value their customers for
real.
-----
_|_ Sometimes you lose, sometimes the others win.
---*--O--*---
O O X Peter Lawrenz (DFV3772)
X X Quake + Spaceorb360 = FUN
X lawrenz@remove.the.%.from.the.reply-to
FreeFall-> FreeBag-> FreeBeer
AAAAARRRRGGGHHHH!!! I have gotten a few of these "you suck cuz I
can't win your car" type of messages.
I'm giving the car away over the objections of my lawyer and my
girlfriend just because I think it will be a cool and memorable
thing to do. I want it to be as fair as possible, but I just don't
have the time to spare to try and manage it myself. In any case, it
wouldn't be fair to everyone no matter what we did. Sure, it would
be great if we could fly the 10,000 interested people to a football
stadium and have thousands of simultaneous double ellimination
bouts, but it just isn't going to happen.
I pushed against the "us citizans" clause, asking if it would be
reasonable to bring a couple people from europe or australia, or
even just allow some people that covered their own expenses, but
aparently we would have to deal with the local laws in each country
that an entrant comes from, which just wouldn't be reasonable for
us. Even dealing with canada (as we have found out recently with
Christian) can be a big pain in the ass.
It's just a fact of life that locality is an issue. We can't treat
the entire world the same. Go convince another company that "might
value their customers for real" to give you a ferrari.
============================
mar 13
Here is a technical issue to be discussed:
I am strongly considering dropping qc in Quake 2 in favor of exporting
most of the game logic to a seperate .dll file. This wasn't an option
when we had to support dos, but I think it is the correct choice now.
There are a lot of issues involved with this.
As everyone who has tried to do anything serious with qc knows, it has
its limitations (ahem). I could improve the language, or just adopt a
real language like java, but the simplest thing to do would be just use
native code.
It would definately be more efficient as a dll. As we do more
sophisticated game logic, efficiency becomes more and more important.
For simple deathmatch modifications this wouldn't be a big deal, but for
full size game levels it will likely be at least a 5% to 10% overall
speed improvement.
It would be non-portable. I am dreading the reaction to this from the
linux community. Game modifications would have to be compiled seperately
for each target architecture (windows, linux, irix, etc). I do still
intend to have the client be generic to all mods (but more flexible than
Q1), so it is really only an issue for servers.
There are security concerns. I suppose to a world that embraces Active-X,
this isn't really an issue, but binary code patches still spook me.
You would actually need a compiler to hack quake. For the serious
people, this isn't an issue, but it would cut out a number of people that
currently enjoy hacking quake. I have a strange mixture of pride and
shame when I think about the people that have actually started learning
programming in my crappy little qc language.
You could debug your patch in a real debugger! Yipee!
========================================
Mar 18
I have gotten a significant amount of response on the Quake 2 extension
mechanism. I do read everything that comes my way (I can't respond to all
of it, though), and I have learned a few things from the mail.
Nothing is set in stone yet, but it is still looking like a dll is going
to be the primary interface. I have been seriously considering a java
interface, but the tradeoffs (time spent implementing takes away from
something else...) just don't quite add up. Other options, like enhancing
qc or using other languages like perl have very remote chances.
One of the primary reasons is that you can allways build UP -- put more
functionality on top of a dll, but you can't allways build DOWN --
accessing the registry from java for instance.
For Id Software to develop a game, a dll will be most efficient. We have
more cpu power, and we can debug it more easily. We are directing
significant effort towards making Quake 2 a better GAME, as well as just a
better multiplayer virtual world. Quake 1 was pretty messed up from a
game standpoint, and we don't plan on doing that again.
What I can offer the qc hacking crowd is a public release of the qc
interface and interpreter code from Quake 1 when Quake 2 is released. The
user community can then bolt things together so that there can be one
publicly trusted DLL that executes an updated and modified qc language for
portable, secure add ons.
I really do care about portability, but it is just one factor that needs
to be balanced against all the others. Things just aren't clear cut.
Speaking of portability, to remove the guesswork that goes on, here are my
current opinions on the various platforms:
Win32
Win32 rules the world. You are sticking your head in the sand if you
think otherwise. The upside is that windows really doesn't suck nowadays.
Win 95 / NT 4.0 are pretty decent systems for what they are targeted at.
I currently develop mostly on NT, and Quake 2 will almost certainly be
delivered on win32 first. Our games should run as well as possible in NT,
we won't require any '95 only features.
Dos
We are not going to do another dos game. No amount of flaming hate mail
is going to change my mind on this (PLEASE don't!). The advantages of
good TCP/IP support, dynamic linking, powerfull virtual memory, device
drivers, etc, are just too much to overcome. Yes, all of those can be
provided under dos in various ways, but it just isn't worth it.
Linux
I consider linux the second most important platform after win32 for id.
From a biz standpoint it would be ludicrous to place it even on par with
mac or os/2, but for our types of games that are designed to be hacked,
linux has a big plus: the highest hacker to user ratio of any os. I don't
personally develop on linux, because I do my unixy things with NEXTSTEP,
but I have a lot of technical respect for it.
MacOS
From a money making standpoint, the only OS other than win32 that matters,
and it doesn't matter all that much. We have professional ports done to
MacOS instead of unsupported hack ports, which is a mixed blessing. They
come out a lot later (still waiting for quake...), but are more full
featured. I have zero respect for the MacOS on a technical basis. They
just stood still and let microsoft run right over them from waaay behind.
I wouldn't develop on it.
OS/2
A native OS/2 port of any of our products is unlikely. We just don't care
enough, and we are unwilling to take time away from anything else.
SGI
I don't particularly care for IRIX as a development environment (compared
to NT or NEXTSTEP), but SGI has the coolest hardware to run GL apps on.
Safe to assume future IRIX ports, but its not exactly a top priority.
AIX / OSF / HPUX / SOLARIS
I wouldn't start a port to any of these, but if a trusted party (Zoid)
wanted to do them, I probably wouldn't object.
BeOS
I bought a BeBox because I am a solid believer in SMP, and I like clean,
from-scratch systems. I was left fairly non plussed by it. Yes, it is
lean and mean and does a couple things better than any other OS I have
seen, but I just don't see any dramatic advantages to it over, say,
NEXTSTEP. Lion (the company doing the mac quake port) has a BeOS port of
quake sort of working, and have my full support in releasing it, but it
will be strictly an act of charity on their part, so don't expect too
much.
Plan9
I spent a few months running Plan9. It has an achingly elegent internal
structure, but a user interface that has been asleep for the past decade.
I had an older version of quake dedicated server running on it (don't ask
me for it -- I lost it somewhere) and I was writing a civilized window
manager for it in my spare time, but my spare time turned out to be only a
couple hours a month, and it just got prioritized out of existance.
NEXTSTEP
My favourite environment. NT and linux both have advantages in some
areas, but if they were on equal footing I would choose NEXTSTEP hands
down. It has all the power of unix (there are lots of things I miss in
NT), the best UI (IMHO, of cource), and it just makes sense on so many
more levels than windows. Yes, you can make windows do anything you want
to if you have enough time to beat on it, but you can come out of it
feeling like you just walked through a sewer.
In the real world, things aren't on equal footing, and I do most of my
work on NT now. I hold out hope that it may not stay that way. If apple
Does The Right Thing with rhapsody, I will be behind them as much as I
can. NEXTSTEP needs a couple things to support games properly (video mode
changing and low level sound access). If apple/next will provide them, I
will personally port our current win32 products over.
If I can convince apple to do a good hardware accelerated OpenGL in
rhapsody, I would be very likely to give my win NT machine the cold
shoulder and do future development on rhapsody. (I really don't need
Quickdraw3D evangelists preaching to me right now, thank you)
========================================
Mar 23
Michael Abrash is working at microsoft again, due to external reasons.
This is the only time anyone has ever left id that we aren't better off
without. :(
That does give me an excuse to visit seattle more often and pester the
folks at microsft about various broken things...
Look for a hardcover compilation of nearly everything Michael has written
later on this year. Michael and I are probably going to add some
hindsight notes to many of the articles for the new edition.
--------
N64 quake is looking really awesome. We got DM5 (the only level small
enough to fit before we take a lot of space saving measures) running
perfectly in only two weeks. It looks about like glquake with "picmip 1",
and it runs 30fps.
We are going to have transparent water in all the maps, and all the lights
will have full color control, so it should look great.
We don't know what maps we are going to use yet. There will probably be a
combination of modified quake, level pack, and new maps. The biggest pain
is the tiny size of the cartridge. I am going to implement some more
space efficient file formats, and all the maps are going to have the
non-essentials crunched out, but we are still not going to be able to fit
as many on as I would like.
--------
Work is progressing well with the new rendering architectures. I have a
test harness that can dynamically switch between using a ref_soft.dll and
ref_gl.dll for rendering in the same window. I have a lot of work to do
before the entire game will run like that, and there may be some
incompatabilities with normal quake, because this is aimed primarily for
Quake 2.
The interface to the renderers is very cool -- it only takes a single file
of code to harness and exercise all the rendering features. If we
actually release with seperate DLLs, people are going to link the
refreshes into their own programs and use it as an object level rendering
toolkit... You could write a Quake-like game in visual basic. There is a
whole mess of biz type issues with that that I don't even want to think
about now.
========================================
Mar 24
Someone ran into my F40 in the parking lot, then took off. Words cannot
do justice to how I feel right now.
If anyone knows a tall white male in the dallas area that now has red
paint and carbon fibre on their tan pickup truck, turn the bastard in!
========================================
April 2
The second generation QuakeWorld is out and live now. We will probably
release a couple bug fix versions over the next week or so as problems
are reported.
Overall, I'm pleased with the results -- I think I have delivered very
solid improvements in game play. I certainly learned a lot along the
way. If you have anything resembling a decent connection, you should be
able to play a good game. A server with a 400+ ms ping and 10% packet
loss is still not going to play all that great, but you should just avoid
those.
The packet size is about as small as it is going to get for the general
cases. Any more shrinkage will have to be game-specific compression,
like the specialized nail update.
I can make doors and plats move smoothly, but it will take a good chunk
more development. This will probably be done for quake 2.
I have it all set up to clip movement against other players during
prediction, but I probably need a day or two to finish it. I'm not
confidant that I'll get to that anytime soon, though.
I really want to get client side demo recording and more spectator mode
options (see through player's eyes, chase cam, etc), but I just don't
have the time right now.
The next major upgrade will be a quakeworld that can run in software and
OpenGL modes. A verite module will come later.
This combination (QW networking and switchable rendering) will be the
base that we move all of our Quake 2 work over to.
========================================
April 4
Ok, the current OpenGL code no longer scales the status bar and console.
You can stop complaining now. The next release will be the consolidated
rendering code for quakeworld. I'm not sure when I will be able to make
a standalone version.
The consolidated quake will also be available on NT-alpha as well as
x86. If you have a powerstorm-T card, glquake works pretty good. Glint
and oxygen cards don't work well enough, but the normal quake software
version should work fine. We may get a little bit of asm code written
for the software version.
========================================
April 8
Technical note:
Instanced brush models are not going to be well supported in the next
release of the quake engine. Instanced bmodels are models that are
created as an entirely seperate map, like the health boxes and ammo
boxes. We are not going to use any instanced bmodels in q2, but I will
probably leave the drawing code intact for backwards compatability. You
will NOT be able to movement clip against them as a bsp hull, however.
You could still use a solid bounding box if you really have to have one,
though.
Brush models built as part of the world, like doors and plats, will
remain with full functionality.
Instanced bmodels never were lighted properly, and a lot of code gets
simpler with this decision.
========================================
April 9
Would anyone complain if I took out lookstrafe and keyboard look modifier?
I'm cleaning up code, and I don't know of anyone that ever uses those
features.
update : ok, +klook has it's supporters. Anyone for lookstrafe?
=================================
Apr 23:
The consolidated QuakeWorld client has been working pretty well. I've been
playing deathmatch with it in GL mode for the past week. There are still a
number of things to do on it, and I haven't been working on it for a while
due to higher priority tasks. A lot of other non-graphics things have
changed in the new architecture as well.
It is really cool to be able to switch between software and gl without
even restarting the game. We will be testing Quake 2 extensively in GL and
even doing some specific development for it. My current wild guess is that
about 15% of quake 2 customers will run the OpenGL version (there will be
several cards coming out this year that are fast enough, besides just
3dfx), so it is definately a factor in our decisions.
The verite renderer will still be supported in quake 2, but it won't have
the special features of glquake. (it will still have it's own custom
features like anti-aliasing, though)
There is a very cool new surprise feature for you in the next gl release
:)
------------
For the past several days I have been working on a new version of qbsp
that should be dramatically more robust for "crazy" maps. Raven is
approaching completion on Hexen 2, and they have a couple problems in
their maps, so this is my top priority.
I figured out something about CSG / BSP operations that had been kicking
around in the back of my head for almost two years now. The separate (and
epsilon issue prone) CSG phase is not needed at all if you directly
contruct a BSP tree from volumes instead of from polygons. I have that
part working, but there is just so much work in the tools that getting the
rest of the stuff working again is taking quite a lot of effort.
I will make another tool release when things calm down, but understandably
that is about at the bottom of my priority list.
=================================
Apr 28:
I'm sure you have all heard about the 3drealms / quake deal by now. It
took a long time to get everything nailed down, but it should be worth it.
The "quake 2" terminology is a little confusing. They have all the quake /
glquake / quakeworld stuff right now, but they will be picking up the
quake 2 codebase after we finish it.
I'm quite excited about this -- it should be a very complimentary
arrangement. We would never have done a game like Duke at id, but there
are many valid styles of design that are mutually exclusive. Todd and the
rest of the Duke team are hard working developers with a pretty clear
vision of what they want. It happens to be different than our vision, but
the market is plenty big enough for both of them.
=================================
May 6:
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.
=================================
May 12:
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 always 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
already 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...
=================================
May 14:
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 than 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.
=================================
May 22:
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.