Doom-Ed

Don’t send any bug reports on the 3.12 release to me, I just forward them
over to jcash. He is going to be managing all future work on the Quake 2
codebase through the mission packs. I’m working on trinity.

3.12 answered the release question pretty decisively for me. We were in
code freeze for over two weeks while the release was being professionally
beta tested, and all it seemed to get us was a two week later release.

Future releases are going to be of the fast/multiple release type, but
clearly labeled as a “beta” release until it stabilizes. A dozen
professional testers or fifty amature testers just can’t compare to the
thousands of players who will download a beta on the first day.

I have spent a while thinking about the causes of the patches for Q2.
Our original plan was to just have the contents of 3.12 as the first
patch, but have it out a month earlier than we did.

The first several patches were forced due to security weaknesses. Lesson
learned — we need to design more security conscious to try to protect
against the assholes out there.

The cause for the upcoming 3.13 patch is the same thing that has caused us
a fair amount of trouble through Q2’s development — instability in the
gamex86 code due to its decending from QC code in Q1. It turns out that
there were lots of bugs in the original QC code, but because of its safe
interpreted nature (specifically having a null entity reference the world)
they never really bothered anyone. We basically just ported the QC code
to regular C for Q2 (it shows in the code) and fixed crash bugs as they
popped up. We should have taken the time to redesign more for C’s
strengths and weaknesses.

I just read the Wired article about all the Doom spawn.

I was quoted as saying “like I’m supposed to be scared of Monolith”, which
is much more derogatory sounding than I would like.

I haven’t followed Monolith’s development, and I don’t know any of their
technical credentials, so I am not in any position to evaluate them.

The topic of “is microsoft going to crush you now that they are in the
game biz”, made me a bit sarcastic.

I honestly wish the best to everyone pursuing new engine development.

8 mb or 12 mb voodoo 2?

An 8mb v2 has 2 mb of texture memory on each TMU. That is not as general
as the current 6mb v1 cards that have 4 mb of texture memory on a single
TMU. To use the multitexture capability, textures are restricted to
being on one or the other TMU (simplifying a bit here). There is some
benefit over only having 2 mb of memory, but it isn’t double. You will
see more texture swapping in quake on an 8mb voodoo 2 than you would
on a 6mb voodoo 1. However, the texture swapping is several times faster,
so it isn’t necessarily all that bad.

If you use the 8 bit palettized textures, there will probably not be any
noticable speed improvement with a 12 mb voodoo 2 vs an 8 mb one. The
situation that would most stress it would be an active deathmatch that
had players using every skin. You might see a difference there.

A game that uses multitexture and 16 bit textures for everything
will stress a 4/2/2 voodoo layout. Several of the Quake engine licensees
are using full 16 bit textures, and should perform better on a 4/4/4 card.

The differences probably won’t show as significant on timedemo numbers,
but they will be felt as little one frame hitches here and there.

I have been getting a lot of mail with questions about the intel i740
today, so here is a general update on the state of 3D cards as they relate
to quake engine games.

ATI rage pro
————
On paper, this chip looks like it should run almost decently — about the
performance of a permedia II, but with per-pixel mip mapping and colored
lighting. With the currently shipping MCD GL driver on NT, it just doesn’t
run well at all. The performance is well below acceptable, and there are
some strange mip map selection errors. We have been hearing for quite some
time that ATI is working on an OpenGL ICD for both ‘95 and NT, but we
haven’t seen it yet. The rage pro supposedly has multitexture capability,
which would help out quite a bit if they implement the multitexture
extension. If they do a very good driver, the rage pro may get up to the
performance of the rendition cards. Supports up to 16MB, which would make
it good for development work if the rest of it was up to par.

3DLabs permedia II
——————
Good throughput, poor fillrate, fair quality, fair features.

No colored lighting blend mode, currently no mip mapping at all.

Supports up to 8MB.

The only currently shipping production full ICD for ‘95, but a little
flaky.

If 3dlabs implemented per-polygon mip mapping, they would get both a
quality and a slight fillrate boost.

Drivers available for WinNT on the DEC Alpha (but the alpha drivers are
very flaky).

Power VR PCX2
————-
Poor throughput, good fillrate, fair quality, poor features, low price.

No WinNT support.

Almost no blend modes at all, low alpha precision.

Even though the hardware doesn’t support multitexture, they could implement
the multi-texture extension just to save on polygon setup costs. That
might get them a 10% to 15% performance boost.

They could implement the point parameters extension for a significant boost
in the speed of particle rendering. That wouldn’t affect benchmark scores
very much, but it would help out in hectic deathmatches.

Their opengl minidriver is already a fairly heroic effort — the current
PVR takes a lot of beating about the head to make it act like an OpenGL
accelerator.

Rendition v2100 / v2200
———————–
Good throughput, good fillrate, very good quality, good features.

A good all around chip. Not quite voodoo1 performance, but close.

v2100 is simply better than everything else in the $99 price range.

Can render 24 bit color for the best possible quality, but their current
drivers don’t support it. Future ones probably will.

Can do 3D on the desktop.

Rendition should be shipping a full ICD OpenGL, which will make an 8mb
v2200 a very good board for people doing 3D development work.

NVidia Riva 128
—————
Very good throughput, very good fillrate, fair quality, fair features.

The fastest fill rate currently shipping, but it varies quite a bit based
on texture size. On large textures it is slightly slower than voodoo, but
on smaller textures it is over twice as fast.

On paper, their triangle throughput rate should be three times what voodoo
gives, but in practice we are only seeing a slight advantage on very fast
machines, and worse performance on pentium class machines. They probably
have a lot of room to improve that in their drivers.

In general, it is fair to say that riva is somewhat faster than voodoo 1,
but it has a few strikes against it.

The feature implementation is not complete. They have the blend mode for
colored lighting, but they still don’t have them all. That may hurt them
in future games. Textures can only be 1 to 1 aspect ratio. In practice,
that just means that non-square textures waste memory.

The rendering quality isn’t quite as high as voodoo or rendition. It looks
like some of their iterators don’t have enough precision.

Nvidia is serious and committed to OpenGL. I am confident that their
driver will continue to improve in both performance and robustness.

While they can do good 3D in a window, they are limited to a max of 4MB of
framebuffer, which means that they can’t run at a high enough resolution
to do serious work.

3DFX Voodoo 1
————-
The benchmark against which everything else is measured.

Good throughput, good fillrate, good quality, good features.

It has a couple faults, but damn few: max texture size limited to 256*256
and 8 to 1 aspect ratio. Slow texture swapping. No 24 bit rendering.

Because of the slow texture swapping, anyone buying a voodoo should get a
six mb board (e.g. Canopus Pure3D). The extra ram prevents some sizable
jerks when textures need to be swapped.

Highly tuned minidriver. They have a full ICD in alpha, but they are being
slow about moving it into production. Because of the add-in board nature
of the 3dfx, the ICD won’t be useful for things like running level editors,
but it would at least guarantee that any new features added to quake engine
games won’t require revving the minidriver to add new functionality.

3DFX Voodoo 2
————-
Not shipping yet, but we were given permission to talk about the benchmarks
on their preproduction boards.

Excellent throughput, excellent fillrate, good quality, excellent features.

The numbers were far and away the best ever recorded, and they are going to
get significantly better. On quake 2, voodoo 2 is setup limited, not fill
rate limited. Voodoo 2 can do triangle strip and fan setup in hardware,
but their opengl can’t take advantage of it until the next revision of
glide. When that happens, the number of vertexes being sent to the card
will drop by HALF. At 640*480, they will probably become fill rate bound
again (unless you interleave two boards), but at 512*384, they will
probably exceed 100 fps on a timedemo. In practice, that means that you
will play the game at 60 fps with hardly ever a dropped frame.

The texture swapping rate is greatly improved, addressing the only
significant problem with voodoo.

I expect that for games that heavily use multitexture (all quake engine
games), voodoo 2 will remain the highest performer for all of ‘98. All
you other chip companies, feel free to prove me wrong.

Lack of 24 bit rendering is the only visual negative.

As with any voodoo solution, you also give up the ability to run 3D
applications on your desktop. For pure gamers, that isn’t an issue, but
for hobbyists that may be interested in using 3D tools it may have some
weight.

Intel i740
———-
Good throughput, good fillrate, good quality, good features.

A very competent chip. I wish intel great success with the 740. I think
that it firmly establishes the baseline that other companies (especially
the ones that didn’t even make this list) will be forced to come up to.

Voodoo rendering quality, better than voodoo1 performance, good 3D on a
desktop integration, and all textures come from AGP memory so there is no
texture swapping at all.

Lack of 24 bit rendering is the only negative of any kind I can think of.

Their current MCD OpenGL on NT runs quake 2 pretty well. I have seen their
ICD driver on ‘95 running quake 2, and it seems to be progressing well.
The chip has the potential to outperform voodoo 1 across the board, but
3DFX has more highly tuned drivers right now, giving it a performance edge.
I expect intel will get the performance up before releasing the ICD.

It is worth mentioning that of all the drivers we have tested, intel’s MCD
was the only driver that did absolutely everything flawlessly. I hope that
their ICD has a similar level of quality (it’s a MUCH bigger job).

An 8mb i740 will be a very good setup for 3D development work.

Just got back from the Q2 wrap party in vegas that Activision threw for us.

Having a reasonable grounding in statistics and probability and no belief
in luck, fate, karma, or god(s), the only casino game that interests me
is blackjack.

Playing blackjack properly is a test of personal discipline. It takes a
small amount of skill to know the right plays and count the cards, but the
hard part is making yourself consistantly behave like a robot, rather than
succumbing to your “gut instincts”.

I play a basic high/low count, but I scale my bets widely — up to 20 to 1
in some cases. Its not like I’m trying to make a living at it, so the
chance of getting kicked out doesn’t bother me too much.

I won $20,000 at the tables, which I am donating to the Free Software
Foundation. I have been meaning to do something for the FSF for a long
time. Quake was deployed on a dos port of FSF software, and both DOOM and
Quake were developed on NEXTSTEP, which uses many FSF based tools. I
don’t subscribe to all the FSF dogma, but I have clearly benefited from
their efforts.

Ok, I’m overdue for an update.

The research getaway went well. In the space of a week, I only left my
hotel to buy diet coke. It seems to have spoiled me a bit, the little
distractions in the office grate on me a bit more since. I will likely
make week long research excursions a fairly regular thing during non-
crunch time. Once a quarter sounds about right.

I’m not ready to talk specifically about what I am working on for
trinity. Quake went through many false starts (beam trees, portals,
etc) before settling down on its final architecture, so I know that the
odds are good that what I am doing now won’t actually be used in the
final product, and I don’t want to mention anything that could be taken
as an implied “promise” by some people.

I’m very excited by all the prospects, though.

Many game developers are in it only for the final product, and the
process is just what they have to go through to get there. I respect
that, but my motivation is a bit different.

For me, while I do take a lot of pride in shipping a great product, the
achievements along the way are more memorable. I don’t remember any of
our older product releases, but I remember the important insights all
the way back to using CRTC wraparound for infinate smooth scrolling in
Keen (actually, all the way back to understanding the virtues of
structures over parallel arrays in apple II assembly language…).
Knowledge builds on knowledge.

I wind up catagorizing periods of my life by how rich my learning
experiences were at the time.

My basic skills built up during school on apple II computers, but lack
of resources limited how far and fast I could go. The situation is so
much better for programmers today — a cheap used PC, a linux CD, and
an internet account, and you have all the tools and resources necessary
to work your way to any level of programming skill you want to shoot
for.

My first six months at Softdisk, working on the PC, was an incredible
learning experience. For the first time, I was around a couple of
programmers with more experience than I had (Romero and Lane Roath),
there were a lot of books and materials available, and I could devote
my full and undivided attention to programming. I had a great time.

The two years following, culminating in DOOM and the various video game
console work I did, was a steady increase in skills and knowledge along
several fronts — more graphics, networking, unix, compiler writing,
cross development, risc architectures, etc.

The first year of Quake’s development was awesome. I got to try so many
new things, and I had Michael Abrash as my sounding board. It would
probably surprise many classically trained graphics programmers how
little I new about conventional 3D when I wrote DOOM — hell, I had
problems properly clipping wall polygons (which is where all the polar
coordinate nonsense came from). Quake forced me to learn things right,
as well as find some new innovations.

The last six months of Quake’s development was mostly pain and suffering
trying to get the damn thing finished. It was all worth it in the end,
but I don’t look back at it all that fondly.

The development cycle of Quake 2 had some moderate learning experiences
for me (glquake, quakeworld, radiosity, openGL tool programming, win32,
etc), but it also gave my mind time to sift through a lot of things
before getting ready to really push ahead.

I think that the upcoming development cycle for trinity is going to be
at least as rewarding as Quake’s was. I am reaching deep levels of
understanding on some topics, and I am branching out into several
completely new (non-graphics) areas for me, that should cross-polinate
well with everything else I am doing.

There should also be a killer game at the end of it.