Use this button to link to Quake2.com.

Fingers [John Carmack] [American McGee] [John Cash] [Christian Antkow] [Brian Hook] [Paul Steed] [Paul Jaquays] [Todd Hollenshead] [Barrett Alexander]

7/31/97
Since you can access past plan postage on the usual places who post it, I'm only including the last post prior to the one I'm updating from now on. This will of course save space and make for faster downloads, etc., etc.

Saw Michael Hadwin's post and I have to say "BUT THEY WERE HERE FIRST!" Truly those ADV guys ROCK! They gave me all kinds of cool stuff as well before swaggering over to Ritual. Unfortunately our id momma over here (Donna J) caught me and Twillits fast forwarding through one particularly graphic teenage-lesbian-slut-being-raped-by-a-many-tentacled-demon-through-every-orifice scene from one of the NINE videos they graciously gave me. I'll plug them again: ADV is fucking cool!

Speaking of chicks I finished up the cyborg version of the crackwhore and she anxiously awaits Adrian's ministrations. Once he textures her maybe Xian will put her up ala the crackwhore. I also started animating the female player character. In her idle frame she's crouched down into an aggressive position with a weapon and when she's idle for too long she straightens, putting one hand on her hip and hoisting the gun up placing the butt of it on her other hip. Turned out pretty cool. I gave her body armor/chest plating so her breast are large but don't sway. The plate look doesn't make her look cartoony, though just well endow...er armored. I gave her big boots and knee pads, but left the rest of her in a form-fitted kevlar bodysuit which shows off some abs of steel and a shapely and very fine ass. This baby's definitely got back!

Speaking of which, I have to say that women in general rule! Even though we're basically different species co-habitating on the same planet, I am such a hopeless philogynist. All those curves. Mmmm, mmm, MMM. Sorry. I went to Hooters today and Six Flags Hurricane Harbor last Saturday which featured hundreds of brightly-colored bikinis filled with (mostly adolescent) voluptuousness.

Ah well back to the FUCKING grind. Gotta keep puttin' the finishing touches on the weapons (you should really dig the cartridge-feed action on the rocket and grenade launcher). The levels look outstanding as well. Boy this is a cool project to work on. I can't wait for you all's reactions when you play it.

Later
ps

Yes we will have see-through windows (i.e. transparent brushes). Adrian and Kevin have done some dirty, grimy stained glass textures that are very cool. Indestructible versions of the windows will be integral to any in-game scripted cinematics ala the Rangers movies. These will help us by allowing the player to watch a scripted action without interfering. Although we are currently discussing the content and scope of the scripted sequences, they will most likely be helpful (e.g. give the player clues about attributes of levels to come or locations of weapons/ammo/health caches.) Bottom line is that yes we will have windows. I'm assuming they will be breakable but I may be incorrect.

ps

Q: have you guys settled on required hardware yet?

A: For the game? No. For the editor you would be wise to own a GL card that allows you to do desktop GL. NT is the OS of choice for us, but since the editor is win32 you could run it under 95. You would also do well with at least 64mb of ram, and a GL card with tons of texture memory wouldn't hurt. Of course, you don't need any of this stuff if you don't mind editing maps with an editor that moves like a snail. Bottom line, if you are serious about making maps and you want to use the best editor in the world, wait till the QE4 code is released and get yourself a pimp-ass machine like the one described above.

Q: are the textures gonna be contained within the new bsp files? if not, how are new textures gonna be used in levels?

A:Textures will NOT be contained in the BSP file in Quake2. You would have to ask John the second question.

(-plucky: i'm gonna hafta send john an email now i guess :)

Q: are you sticking with the .pak file format?

A: I do not believe so. I would go ask John but he is in a meeting right now.

(-plucky: looks like i have two things to ask him about)

Q: how much more time-consuming is vis to run on the larger maps?

A: Much more. But this is not really because of the tools. This mainly has to do with the way that we are creating our maps now.

Q: what is the average size (brush/entity count) and compile time of the q2 maps?

A: Well, brush counts have more than doubled. The map I am working on right at this moment contains over 3000 brushes... and it's not finished yet. Number of entities remains about the same... maybe a little more than in Quake maps. Compile time has gone way up, but this is directly related to the complexity of our maps. We are currently using an SGI Origin 2000 with 16 r10k processors, and 512mb of ram to BSP our maps. (When I say "bsp our maps" I mean the entire process of bsp, vis, light) An average BSP takes anywhere from 15 minutes to over 3 hours. Depends on the map. The map I am working on is relatively small in total floor space, but contains complex machines and tons of detail. It takes about 2 hours to BSP the entire thing.

Q: do you know when the qe4 editor source is going to be released?

A: Well, this is something that John has talked about for a long time now. In my opinion we should get Quake 2 out the door before we bother releasing the new tools. I think that the source may be released with the game, or around the same time. But it may never be released... we'll just have to wait and see.

One more comment on stipple -- if two transparent objects overlap each other and you're using stipple, one will disappear completely since the stipple pattern is aligned in screen space. This is apparent when rendering a translucent sprite (e.g. rocket blast) over a window; in our case, windows are always rendered last and thus the window overwrites the sprite since they're on the same stipple grid.

To counter this I introduced a "stipple polarity" that is even for alpha surfaces (water, windows, etc.) and odd for sprites (explosions). This means that sprites and windows/water can overlap correctly, but windows/water won't overlap each other very well, which is actually better behaviour than if we offset the stipple grid for windows differently than that for water. In the latter case water+windows would become completely opaque, which isn't necessarily a good thing.

Slight correction and clarification to yesterday's plan update.

For starters, I goofed and printed particle times in software on a Pentium/90 and in hardware on a PPro/200! Oooops. The actual numbers should be about 8ms/frame for software on a PPro/200 and about 20ms/frame on PPro/200 w/ 3Dfx and about 40ms/frame w/ Realizm. These are all at 640x480. So sorry about the confusion.

So a particle drawing extension (hi Chris!) is still a good idea, but I haven't gotten around to specing out the extension.

I've also received a lot of mail about inline asm, so I thought I'd talk a little bit about it some more.

Some more comments/advantages of using the inline asm include:

- you can use the C preprocessor
- you can put a bunch of asm statements inside a single asm block a la:
__asm
{

mov eax, value
mov ebx, value
add eax, ebx
}

- you can intersperse C and asm:
value = 10;
__asm
{
mov eax, value
mov ebx, value
add eax, ebx
}

printf( "blah" );

HOWEVER, I would NOT recommend mixing C and asm in the same function. It sounds like a good idea in theory, but in practice, it's a kind of evil you've never read about.

- I'm using Microsoft Visual C++ 4.2, for those of you wondering
- According to some e-mail I received, MSVC 5 supports MMX instructions
- I'm unclear when an LEA is necessary vs. a MOV to load a pointer value into a register. I just haven't gotten around to experimenting with this, but this is definitely something you need to watch out for -- sometimes when you think you're updating what a pointer's target you're in fact only updating the pointer's target ADDRESS!

Got two more monsters coded into the game last night, and I did a bit more work on my last map. I think I can safely say, I've set a new record for the longest vistime on any single map.

12.6 hours spent just in VIS on our Origin 2000 machine.

quake2 +set maxclients 200

:)

The stage is set for ultra-large servers. Imagine everyone at QuakeCon in one gigantic level! A single T1 could run 80 internet players if it wasn't doing anything else, a switched ethernet should be able to run as many as we are ever likely to have together in one place.

There will be a number of issues that will need to be resolved when this becomes a reality, but the fundamentals are there.

There will probably be issues with UDP packet dropping at the ethernet card level that will need to be worked around with a seperate qued thread.

Quake 2 isn't as cpu intensive as QuakeWorld, but I'm not sure even a Pentium-II 300 could run 200 users. An alpha 21264 could certainly deal with it, though.

The new .bsp format has greatly increased size limits, but you could still make a map that hits them. The first one to be hit will probably be 64k brush sides. Ten thousand brushes can make a really big level if you don't make it incredibly detailed. Loading a monster map like that will probably take over a minute, and require 32+ megs of ram.

I should probably make an option for death messages to only be multicast to people that are in the potentially hearable set, otherwise death messages would dominate the bandwidth.

Everyone should start thinking about interesting rules for huge games. A QuakeArmies dll has immense potential. Enemy lines, conquering teritory, multiple clan bases, etc.

Cooperating servers will be possible with modified dlls, but I probably won't include any specific code for it in the default game.dll.

> Will rotating brushes be allowed to rotate on all axis (axes?
> axises?). Can that rotation, once set, be changed by, say, an event
> trigger?

The engine will automatically rotate only on cardinal axis, but you can change the rotational velocity to anything you want, or even modify it every frame.

John Carmack

As far as I know, the word "Gib" was invented here at id during the DOOM days. At first it was how we referred to the little chunks of meat that we left laying around the level in order to add atmosphere to a level. The editor included all types of "Gib". The editor entities were created by John Carmack and John Romero. I am pretty sure that Romero was the inventor of the word, and I know for a fact that he (and everyone else at id) pronounces it "Jib", not "Gib".

When Christian started working here he would say "Gib". After much beating and torture I have convinced him that he was wrong. If you find yourself having a hard time saying "Jib" then please whack yourself in the head a few times and try again.

**Ugrent update to the Gib-Jib Debate**

The TRUE inventor of the word "Gib" turns out to be Adrian Carmack, who explains as follows:

"Gib is short for gibblet. Gibblets are guts of a chicken. I first heard a friend of mine use the term. Once I started working at id, I would call the guts I drew "gibs"."

Thanks Adrian. Now we can all sleep a little easier.

Just tested the performance of particle rendering. Particle performance on OpenGL is pretty, um, sucky. On a Pentium Pro 200 we're seeing about 30-40ms/frame being consumed for particle rendering on Realizm, and about 20ms/frame being consumed on 3Dfx.

In software, the C-only path is about 18-19ms/frame, and the optimized routine I just did in assembly gets about 12-13ms/frame (30+% increase in performance). I could spend another day tweaking it some more and maybe eke out another 5%, but that simply isn't worth it.

It's getting close to time to specing out the particle drawing extension for OpenGL. I think that even a basic set of speedups should garner 25-50% better performance -- hell, having to do only 1/3rd the transforms would help, and in the case of PowerVR and 3Dfx they could even optimize their triangle setup (although this may not be worth it since it would mean bypassing SGL/Glide).

Doing a glDrawParticlesQUAKE extension won't help that much with timedemo or single player performance, since particles don't consume that much time in those types of games. But with deathmatch play, particle rendering is going to consume a SHIT load of time. With the rail gun, explosions, rocket trails, blaster trails, and sparks, I could see our particle buffer being full for lengthy periods of time (the buffer holds 4K particles right now, and we aren't that anxious to crank it up).

Spent last night and a little bit of today working on the assemblified version of the particle drawing code. It should be a lot faster now, but we won't know until we do some comprehensive benchmarking on it, which hopefully will occur within the next day or two.

I used inline assembly for the whole thing, and it seems to work quite well. You get access to static and global variables very cleanly, including structure definitions. No more need for .INC files and stressing over your C struct declarations having the same offset values that your ASM modules are expecting.

For example, you could do:

typedef struct
{
float x, y, z;
} vector;

vector a, b;

__declspec( naked ) void DotAB( void )
{
__asm fld dword ptr [a.x]
__asm fmul dword ptr [b.x]
__asm fld dword ptr [a.y]
__asm fmul dword ptr [b.y]
__asm fld dword ptr [a.z]
__asm fmul dword ptr [b.z]
__asm fxch st(2)
__asm faddp st(1), st
__asm faddp st(1), st
__asm fstp result
__asm ret
}

Note that the above code isn't tested, so don't go cutting and pasting and blaming me for any bugs!

Anyway, point being that the structure declarations carry over straight into the inline asm with no muss and no fuss.

One thing you can't do is jump to a label that is out of scope. This means you can't do:

void blah( void )
{
__asm jmp thingy
}

void foo( void )
{
thingy:
__asm ret
}

Because "thingy" is in a different scope than "blah()". This may be solvable but it's not a big enough issue that I'm going to worry about.

A note about optimization -- it's VERY easy to get bogged down when writing asm code with stupid details in places that don't matter. It becomes a matter of habit to do things like watch for pairing, AGIs, 16-bit prefix stalls, etc. when looking at code, and you can easily get sucked in optimizing code that is rarely executed (e.g. loop setup code).

So before wasting time optimizing something (and making it potentially quite a bit uglier and more difficult to debug), make sure it's worth it!

Case in point: I use a function pointer to draw the pixel for the alpha blended particle pixels. At first blush this seems astronomically stupid (and after benchmarking it may BE astronomically stupid), but when you get down to it it actually is only about 20% of the overall clocks being spent to draw a pixel.

The CALL/RET pair is like 5 cycles -- not bad at all. And since there's no stack frame to setup or fix, or registers to save, or whatever, it "just works", which is always a good thing.

The alternative would have been to have self-modifying code (fixup the JMP target) or to replicate tons of code and inline the pixel blending stuff, neither of which are conducive to stable code.

The other thing I did was remove a bunch of unrolled code that special cases 1x1, 2x2, 3x3, and 4x4 particle sizes. Having this huge chunk of code saved us from doing:

__asm dec ecx
__asm jnz top_of_horiz_loop
.
.
__asm dec edx
__asm jnz top_of_vert_loop

Along with some PUSH/POP pairs. Um, not worth it.

So now I have some pretty tight assemblified particle rendering code that is A.) easy to understand B.) pretty fast (I think) and C.) very easy to debug and maintain. I could make it a little faster at the expense of A.) and C.), and unless we think it's going to make a HUGE difference, I don't think I want to bother.

July 28, 1997
------------------

Spent today getting stippled translucency to work. I haven't tested its performance vs. the table based "real" translucency, but in theory it should have at least 2x the performance because only half the number of pixels will be rendered. Hell, with 25/33% transparency, only 1/4th the pixels need to be rendered. And stippling has the added perk of not requiring a read from the backbuffer.

The down side to stippled alpha is that it's, well, pretty butt ugly. If you're running a high res desktop with a smallish window then it looks just fine, but if you're running low-res, it looks like the complete and utter Hell of White Noise.

Stippled alpha will likely be off by default, but it will be controllable via the video options menu and also by a cvar ("r_stipplealpha") for those folks that can live with the slightly degraded image quality in exchange for a possibly hefty performance boost.

Oh, stippled translucency is only available in the software renderer. Most good hardware doesn't see a significant performance boost from stippling.

I'm beginning to go back and optimize other chunks of code now. I still need to add stipple support to the sprite and Alias model renderers, but before I do that I'm going to see about optimizing our particle renderer, since particle rendering looks like it may become a serious performance issue, especially if we have 4000 particles in the world at a time (we regularly see this, since we're particle crazy these days).

We're starting to lean away from dedicated .ASM files and instead move to using inline assembly. Here are some reasons we like inline asm:

- don't need MASM
- don't need to do this Custom Build bullshit in MSVC
- compiler handles parameters, return values, etc. automagically
- when using __declspec( naked ) you are in charge of EVERYTHING

There are some downsides to inline asm, including:

- compiler dependency
- inability to precisely control alignment
- difficulty doing weird stuff like self-modifying code, etc.
- turns off optimizer for functions with inline asm

We'll see how the inline asm thing turns out.

I read your request for clarification on the release date of Quake 2. Actually, Quake 2 could ship for Christmas and ship on November 18. The term Christmas release covers a broad period of time ranging from about October till a week prior to Christmas.

Sorry I cannot be more specific. However, given the complexity and size of Quake 2, the final implementation, clean up, and testing of the game is going to take longer than with prior id releases. Therefore, speculation as to the exact date of the game's release is simply guess work.

With that said, we are committed to get Quake 2 finished for Christmas and feel that it is a reasonable deadline given our current development status.

Kevin Cloud

I've pretty much finished all my map work for Q2 (architecturally anyway), and now I'm working with John Cash in getting all the remaining game code implemented and working (monster code, weapon code, etc...) It'll be refreshing to work with standard C code in a real development environment instead of QC for a change =)

I've also recieved a number of e-mails about DM 4.0 rules. Alot of people like it for the simple "carnage factor" and yet others don't like it. That's why it's called an "option". You don't have to run it if you don't want to, but it's mindless fun once in a while. Still going through and tweaking the odd rule here and there.

On another note, someone sent me e-mail with regard to a deathmatch mod called FairDM.

"Hi. I released a patch called "FairDM" a few days ago. (about 4 or 5) In it you had all weapons and unlimited ammo (sound familiar ). I know this sounds crazy, but I can't help myself from asking you to mention me in your next plan for having the same idea. OK, that's all Mr Crazy has to say :).

[FA]Tex-Murph"

It's funny how two people can think so alike.

1:16am... My night is just starting... /me goes back to work.