3DNet.net is registered with the internic!!! You can now connect to the IRC network using the following servers.

id.3dnet.net:6667
best.3dnet.net:6667
planetquake.3dnet.net:6667

We also hope to have monolith.3dnet.net up and running later on tonight (the guys who worked on Blood).

Remember, if you are a 3D Game Developer and wish to help out with the network by running servers, please let us know at;

3DNet@underworld.idsoftware.com

The quality of Quake's software has been a topic of some discussion lately. I avoid IRC like the plague, but I usually hear about the big issues.

Quake has bugs. I freely acknowledge it, and I regret them. However, Quake 1 is no longer being actively developed, and any remaining bugs are unlikely to be fixed. We would still like to be aware of all the problems, so we can try to avoid them in Quake 2.

At last year's #quakecon, there was talk about setting up a bug list maintained by a member of the user community. That would have been great. Maybe it will happen for Quake 2.

The idea of some cover up or active deception regarding software quality is insulting.

To state my life .plan in a single sentance: "I want to write the best software I can". There isn't even a close second place. My judgement and my work are up for open criticism (I welcome insightfull commentary), but I do get offended when ulterior motives are implied.

Some cynical people think that every activity must revolve around the mighty dollar, and anyone saying otherwise is just attempting to delude the public. I will probably never be able to convince them that isn't allways the case, but I do have the satisfaction of knowing that I live in a less dingy world than they do.

I want bug free software. I also want software that runs at infinite speed, takes no bandwidth, is flexible enough to do anything, and was finished yesterday.

Every day I make decisions to let something stand and move on, rather than continuing until it is "perfect". Often, I really WANT to keep working on it, but other things have risen to the top of the priority que, and demand my attention.

"Good software" is a complex metric of many, many dimensions. There are sweet spots of functionality, quality, efficiancy and timeliness that I aim for, but fundamentally YOU CAN'T HAVE EVERYTHING.

A common thought is that if we just hired more programmers, we could make the product "better".

It's possible we aren't at our exactly optimal team size, but I'm pretty confidant we are close.

For any given project, there is some team size beyond which adding more people will actually cause things to take LONGER. This is due to loss of efficiency from chopping up problems, communication overhead, and just plain entropy. It's even easier to reduce quality by adding people.


I contend that the max programming team size for Id is very small.

For instance, sometimes I need to make a change in the editor, the utilities, and the game all at once to get a new feature in. If we had the task split up among three seperate programmers, it would take FAR longer to go through a few new revs to debug a feature. As it is, I just go do it all myself. I originated all the code in every aspect of the project, so I have a global scope of knowledge that just wouldn't be possible with an army of programmers dicing up the problems. One global insight is worth a half dozen local ones.

Cash and Brian assist me quite a lot, but there is a definite, very small, limit to how many assistants are worthwhile. I think we are pretty close to optimal with the current team.

In the end, things will be done when the are done, and they should be pretty good. :)

A related topic from recent experience:

Anatomy of a mis-feature
------------------------
As anyone who has ever disected it knows, Quake's triangle model format is a mess. Any time during Quake's development that I had to go back and work with it, I allways walked over to Michael and said "Ohmygod I hate our model format!'. I didn't have time to change it, though. After quake's release, I WANTED to change it, especially when I was doing glquake, but we were then the proud owners of a legacy data situation.

The principle reason for the mess is a feature.

Automatic animation is a feature that I trace all the way back to our side-scroller days, when we wanted simple ways to get tile graphics to automatically cycle through animations without having to programatically each object through its frames.

I thought, "Hmm. That should be a great feature for Quake, because it will allow more motion without any network bandwidth."

So, we added groups of frames and groups of skins, and a couple ways to control the timing and syncronization. It all works as designed, but parsing the file format and determining the current frames was gross.

In the end, we only used auto-frame-animation for torches, and we didn't use auto-skin-animation at all (Rogue did in mission pak 2, though).

Ah well, someone might use the feature for something, and its allready finished, so no harm done, right?

Wrong. There are a half dozen or so good features that are apropriate to add to the triangle models in a quake technology framework, but the couple times that I started doing the research for some of them, I allways balked at having to work with the existing model format.

The addition of a feature early on caused other (more important) features to not be developed.

Well, me have a new model format for Quake 2 now. Its a ton simpler, manages more bits of precision, includes the gl data, and is easy to extend for a couple new features I am considering. It doesn't have auto-animation.

This seems like an easy case -- almost anyone would ditch auto-animation for, say, mesh level of detail, or multi-part models. The important point is that the cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obsticle to future expansion.

Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web.

The trick is to pick the features that don't fight each other. The problem is that the feature that you pass on will allways be SOMEONE's pet feature, and they will think you are cruel and uncaring, and say nasty things about you.

Sigh.

Sometimes the decisions are REALLY hard, like making head to head modem play suffer to enable persistant internet servers.

I wanted to take a moment to explain a situation that has gotten far out of control.

There is a small group of people on Undernet IRC who seek to discredit me and marr my image as some egomaniac, powerhungry asshole. You may have read some "webpages of hate" erected to me, or read some logs that either quote me out of context, bend the truth to suit "their" needs, or do not show the whole story.

I want to state that if I've offended anyone in the net.community, I wanted to offer my humblest and heartfelt apologies to you. When people back me into a corner by telling lies, getting involved in petty IRC powerstruggles, make libelous and rude remarks about id Software, and even grasp at straws and make jabs at my high hairline of all things, you can bet I'm not going to lay down and take it. I react.

Again, to the general net.community, if I've offended anyone, I sincerely apologize, but my quarrel is not with you. I will not ever set foot on Undernet again as a result of the op situation, and to the people that attended #quake and #quake2 in hopes of talking to an id guy and having your questions answered, I'm sorry, but it won't be me answering them there.

Thank you for reading this and I hope it's been with an open mind.

---

ironman.planetquake.com:6667 just went online as a part of 3DNet. I believe this will be changing to chat.planetquake.com and/or chat.quakespy.com in the coming days, but I'll keep you posted.

Feel free to use that server if you are on the west coast.

Origin expressed an interest in attaching to the network, and I'm speaking to the manager of Unreal's IRC network in linking up with 3DNet as well. All in all, not a bad first 24 hours of existence.

---

I would like to extend an invitation to 3D, First Person gaming developers (Rogue, Ritual, Raven, Valve, Epic, Apogee, Ion Storm, etc..) to help in the creation of a new IRC network called 3DNet, by running IRCD's.

The justification for this network is that we (the 3DNet founders) wish to offer a stable, high profile alternative to Undernet and EFNet for anyone who is interested in the 3D First person game genre. It would also offer a controlled enviroment to offer a platform in which to market and discuss your games by you relegating control of said channels to whomever you want. By running the servers yourselves, you don't have to deal with the "BS" associated with conventional IRC networks.

The IRCD of choice for 3DNet, is the Undernet IRCD which we can provide to you and help setup. You will require a box running some flavour of Unix.

We already have two servers attached to the network;

idcube.idsoftware.com:6667
bigmac.noc.best.net:6667

with PlanetQuake due to sign on within the next 48 hours.

The structure is pretty loose, with proposed channels such as #quake2, #sin, #daikatana, #halflife, #unreal, #prey, #qspy, etc... as well as seperate channels for each company for general discussions (#id, #ritual, #raven, #ionstorm, #apogee, etc...) No pr0n, no warez, just games discussions.

Should any developers be interested in contributing to the network, please e-mail 3DNet@underworld.idsoftware.com should you have any further questions or concerns, and one of the managers will get back to you.

We'll wait for a period of two weeks to gauge response from publishers and developers, and I'll post an update as to the future of the network then.

Thanks for your co-operation,

-Christian

PS: On a bit of a personal note, I think this would be a great way to bring the game developer community closer together online.

July 9, 1997
------------------

Saw that article on why Quake is so slow with non-Intel CPUs. While the original author seems to know things technically, he's actually incorrect with his assumption that memory copying is the issue. It's not. We don't do that much memory copying to begin with, and we don't use the FPU to do it at all.

The reason that Quake is slower on AMD and Cyrix CPUs is that they don't have good floating point. Period. They don't pipeline as well as the Intel processors (if at all) and a lot of our code really benefits from pipelining, e.g. dot products and matrix operations.

Hopefully this will be addressed in future versions of non-Intel processors.

July 8, 1997 (early AM)
------------------

Software rendering of transparency now works for sprites, particles, and Alias models. Should have it working with walls tomorrow (I hope). Culling of Alias models to the view frustum works.

Getting this stuff is frustrating, since John has to come in and hold my hand because I'm so damn unfamiliar with the code (and my brain has been frozen for the past couple days for some weird reason *irk*), and the whole point of my existence is so that he doesn't HAVE to worry about this stuff.

Oh well, it should get better in the coming days and weeks.

Anyway, after the rest of transparency is implemented I have the skybox to do, which may not be trivial, but I'll burn that bridge when I get to it.

Even though I'm not getting up to speed as much I'd like, things are still on track and I'm pretty happy with the progress we're making.

The way we're doing transparency in software is via lookup tables. We create a 256x256 transparency lookup table where:

transparent.color = table[incoming.color][existing.color];

This gives us a 33%/66% mix (we can swap "existing" and "incoming" and get the inverse blend). This definitely has some negative performance implications because we're using a 64K table (bad cache effects), not to mention the actual code that's being generated for the second table lookup.

Obviously the visual quality isn't the greatest -- with as few colors as we have to begin with, running them through a blender doesn't help matters, so the transparent colors don't look perfect, but they're good enough for the effect we want. The quantization of blending (0%, 33%, 66%, 100%) also is pretty obvious and prevents really smooth translucency transitions.

But overall, we're pretty damn happy with the software transparency. There's some optimization work to be done, but it's looking good.

July 7, 1997 (early AM)
------------------

I'm going to take a break here and not talk about techie stuff. I know a lot of you folks really like the fact that I talk about tech shit instead of what movie I recently saw ("Con Air"), my favorite ice cream ("Breyers Chocolate"), what CDs I'm listening to ("Violator" and 5th Element Soundtrack), etc. But I would like to take a second here to vent, so hold on while I put on my Steed Hat:

I hopped onto IRC because that was a good forum to answer questions, solicit feedback, etc. For several weeks it was a good experience, I had a good time, and I learned a lot about Quakers and even Quake and Quake2, since I had to answer questions I didn't necessarily know the answers to.

But after the sound and the fury was over, and the initial flurry of activity was over, the nasty underbelly of the IRC beast was shown to me. The ego trips that some ops get, the petty sniping, the indiscriminate kicking of people, the whining and bickering when someone from id doesn't do exactly what someone wants, etc.

For this reason I'm just going to stick with my .plan as a way of getting out information, at least until an alternative Quake forum on IRC is made available to me.

By basically trying to help out others I've been subjected to a rash of shit that has become intolerable. I've seen friends publically insulted, and I've put up with people dealing shit to me for various diverse and often unfathomable reasons.

You know what REALLY annoys me? It's when someone has a beef with me, I send them e-mail to clear the air, and they decide to make a fucking Web page devoted to our conversation. Wow, how...stupid.

So with this state of mind in mind:

Top 6 Reasons Why Some People Hate Me or id
*******************************************

6. Because we don't personally answer every e-mail that comes across our desks. Yes, we DO read them, but many of us here receive on the order of HUNDREDS of e-mails a day, and if we did nothing but answer each of them we'd never get any real work done.

Note that bug reports _technically_ are not our problem. Our publisher handles bug reports, because this centralizes a database of bug reports and also allows them to use better facilities to track and reproduce certain bugs. Report bugs to our publisher, and they will get to us and we will look at them and do our best to fix them. That's the way a small developer like us (did I mention we have like less than 15 employees?) can develop products effectively -- our publisher handles non-development related stuff like tech support, packaging, distribution, manuals, etc.

This is how the business works.

So if we don't personally answer a bug report, don't hold it against us. We do read them, we do get them, and we do try and fix them, but we simply cannot answer everyone's e-mail personally.

5. I'm an asshole. Okay, this is a given, and I can deal with that.

4. Because I won't fix bugs in free, unsupported products such as QuakeWorld or GLQuake. What part of the word "unsupported" do people not understand? Yes, it would be GREAT if I could go back and make all of our unsupported products rock-solid, but that would mean slipping the shipping schedule on Quake2 by many months. Does that sound worth it to you? If we ship Quake2 several months late, there are going to be a LOT of irate fans out there, and they won't care if we shipped late because we had to figure out why QuakeWorld was crashing on Jim Bob's AMD K5 machine with a combo VLB/PCI bus and 4MB of RAM with a no-name soundcard under Windows 3.1.

If you don't want unsupported products like GLQuake, VQuake, or QuakeWorld just because they have bugs, let me know, and we can stop releasing them.

3. Because I offer to look into a bug report, but when I ask for exact data about the nature of the bug some folks throw up their hands and say "you won't look at it anyway, so why should I bother?" If these people would actually just do a bug report instead of spending hours on-line crying and moaning the world would likely be a better place.

2. Because I won't implement some feature that a small fraction of the Quake community wants. These features range from things like doing a peer-peer networking scheme to supporting a Glide-only version of Quake. People don't seem to understand that there are THREE programmers are id, of which one of whom (me) is not exactly up to speed yet. Implementing these features are possible, but it's generally a waste of time -- we have to carefully prioritize what features are important, and if we went ahead and implemented every small thing that anyone who sends us e-mail wants, Quake2 would just suck. Designing a game is about balancing trade offs -- and we simply can't throw everything into a game without it suffering in many many ways.

1. Because I stick up for a friend publically who has his own Temple of Hate devoted to him. Sorry, if being a good friend is reason to hate me, burn me at the fucking stake.

Our obligation is to the Quake players around the world. Not the loudest or most vocal group of Quake players, but the average Quake player. Just like the US government's policy shouldn't be dictated by lobbying groups or special interest groups, id simply cannot cater to the needs of EVERY single game player out there. Try and please everyone all of the time, etc. etc.

Anyway...

Trust us to make the right decisions. We've done pretty well so far when it comes to writing cool games, and there's no reason to think that this is going to change anytime soon. Sure, individuals may have specific things about Quake they would like to see improved, but we have to do a tough balancing act. There are things I'd like to see in Quake2, but in order for us to do it would take forever. You have to balance cost of development versus derived benefit. These are tough decisions, especially when we only have a few months left for development if we want to make it in time for Christmas.

Bear with us. I appreciate the help, feedback, and comments that many of you have given to me in e-mail and on IRC. If I seem testy and pissed, it's because...I am.

Good night.

First off I wanted to say that I'll be going to Quake Con. It's virtually in my back yard and I wanted to give a seminar on 3d modeling & animation for those interested. Looking forward to meeting a couple of you Quake celebs and fans, too. We'll also be showing about 40 seconds from the intro cinematic I've been working on in my (spare?) time. It's turned out pretty cool so far and I think you'll like it. Maybe after QC some screen shots'll be available.

So continuing where I left off last week, after I create and optimize the model in 3ds4 I have to do a couple of things before I save it out to a .dxf for importing into Alias. First I reverse the normals on the model since Alias and 3ds normals are opposite (remember what those are, right?). Then I center the models position on the 'home' position or 0,0,0 in x,y,z space. This allows me to have the model in the 'center' of the world and it rotates cleaner in various programs' view windows. Finally I save the mesh out as an object-separated .dxf file.

Next I bring it into Alias Power Animator 8.0 and start to work. Whether it's a character or weapon or whatever, if I animate it I build a skeleton for it. Although I'm a freshman with Alias, manipulating joints are much more palatable than not. Alias is superior to programs like Bones Pro in 3ds4 because the amount of control over each individual vertex is greater. I don't know what Lightwave has to offer in terms of character animation but I do know several companies do use it as well as SoftImage. Alias works for me because it will also spit the finished animation out as a series of .tri files which we use for game data here at id. Bones Pro will create 'morph' target objects which you can manually save out and convert for game assimilation, but unfortunately there are problems with BP's spatial orientation of the resultant morph targets (TOTAL pain in the ASS actually). After the animation is complete, I save it out as a numbered series of .tri files associated with the animation (e.g. run01.tri, run02.tri, etc.) logging the animation in a spreadsheet for reference, sound synchs, and prog input. I finally create a base frame for Adrian, Kevin or myself to texture in John's Texpaint and move on to the next one.

So basically I could write a Brian Hook sized novel on various tips and tricks and WAYS to animate but Steed's animation rule of thumb#1 is PERSONALITY. Here's a tip though: I always use some sort of IK for my character's legs and feet (attaching from the ANKLES to hips as opposed to TOES to hips) but I never use it for the arms (unless the creature is four-legged). Basically a good rule of thumb to remember is never be satisfied with your animation just HAPPENING. Making a character walk the first time is an awesome experience. You made the program work. Whoopee. NOW put some personality into it. This may sound corny or artsy but I have to relate to all my characters or weapons and give them some sort of attitude. Luckily in Q2, all the characters have just a varying degree of bad-assed-ness. Make your characters into little people that are ALIVE and not just ANIMATING. Animation means to 'bring to life'. If you saw your characters on the street would you be convinced they have weight? Have personality? Have intelligence? Again, it may sound goofy, but never settle for skating-feet, jittery, unrealistic character animation. Skating feet-bad. Feet that plant, walk, pivot and turn as our feet turn is good.

Sorry if I didn't cover enough about the complexities of modeling or animating, but my best advice for you is entombed above. I've been animating for FOUR years now. It has taken me this long to be comfortable with my skill. Four years from now (assuming you've read all this techno/babble jargon and pearls of wisdom because you want to become an artist ala Steed) where will you be? Me? I'm just at id. Whoa.

Ugliness of the Nutcase
-----------------------
Lag creates/exposes many more bugs than it will ever cover up. Our initial testing is on our LAN: no latency, no data loss. There are many times where we can only reproduce bugs on internet games because of the latency/loss issues.

Just because you disagree with a design decision doesn't make it a bug. Here are a couple of popular non-bugs:
Lightning gun discharge hurting people not in the water. It is supposed to work that way. The gameplay explanation is not that you electrified the water, but that you tried to use an electronic device in the water and it blew up. Explosions do not stop hurting at air/water boundries.
Rockets (or nails) "losing" their quad effect. The quad is taken into account at time of impact, not at time of launch. This is not a bug; that's how it is supposed to work. I agree it should have been done the other way, but that doesn't make it a bug. And now for one that fits in the same catagory but gets quite a different reaction: rocket jumping. I don't recall hearing any complaints about rocket jumping, but it is an unintentional behavior. We didn't plan on it, so it's closer to being a bug than the other two.

Are any of us saying that Quake is bug free? Not hardly. Just that we find these lame accusations that we would intentionally not fix bugs and even lie about their existance to be terribly insulting (not to mention untrue).

Are "official" complaints more serious than unoffical ones? I don't give a damn how a bug gets to me; it gets put on a list and looked at in turn. We don't personally respond to every single email we receive. Guilty as charged. I'm tempted to ask every single person that I have replied to via email or phone to send this guy a note. It's rare that a day goes by where I don't send at least a quick response to a couple of the emails I receive every day. Unfortunatley we just don't have the time to answer them all. That's one of the reasons we out some things in our .plans. My QuakeC tips, for example, are things that I've found I was getting asked about (or were the cause of somebody's problem) quite frequently.

One final point. Quake is done, complete, finished. We are not working on it any more. Do not expect any new versions from us. However, we do still want to hear about bugs in Quake. There are a number of Quake engine games currently under development that could use that info. Also, we want to make sure they do noy happen in Quake2.

Sorry to rant. I usually reserve my .plan for useful and/or humorous info.

FOR IMMEDIATE RELEASE

Yep, though we'll probably get hammered for "copying" Frag.com's idea for the Screenshot Archive, we decided to go ahead.

http://meccaworld.com/sa/ the Screenshot Mecca

After a month of preparing, last week we got the news that Frag had themselves launched the Screenshot Archive. Suffice it to say, we turned pale. Then considered scrapping our project. In the end, though, we opted to carry on, and now are announcing the Screenshot Mecca -- We had to come up with a new name, since our original was "the Screenshot Archive." :-(

So, to the guys at Frag.com -- Thanks for stealing "our" thunder! ;-)

In the end, we offer something different, and MORE in each individual game screenshot area. Say, with Jedi Knight -- MeccaWorld 134 | Frag -- 38... And on down the line.

###

For more information, visit MeccaWorld, or contact Malcolm

July 6, 1997
------------------

Got Alias model frame interpolation working over the weekend. I'm pretty happy about this, actually, even though it took me longer to do than I had hoped. Such is the joy of modifying software you didn't write, but hey, that's why they pay me the Big Bucks (tm).

Unfortunately software frame lerp doesn't look as good as GL frame lerping since the Alias models are not rendered with subpixel accuracy in the software rasterizer.

This week I hope to get much of the software rasterizer cleaned up and revved up to achieve parity with the GL renderer. Remaining features that need to be added (in order of priority) include:

- culling Alias models to the view frustum
- translucency for world polygons
- sky rendering
- translucent particles

It's gonna be a long week.

[HOOK] ignus: Nothing terribly new. Got interpolation working with the software renderer, and I'm busy trying to get view frustum culling with the Alias model renderer.
[HOOK] Right now I don't think the level editors can control translucency specifically, I think r_wateralpha will control that. But I'm not sure.
[HOOK] q200: There is no GLQuake2, on the GL renderer in Quake2. It will have roughly the same raw performance as GLQuake.
[HOOK] Dragonass: You will be able to select if you want GL via 3Dfx or software rendering. You can even select "on the fly".
[HOOK] DJ_Rican: We support GL, not 3Dfx. Ergo we support anyone who has an OpenGL driver compatible with Quake2, which today consists of PowerVR PCX2 and 3Dfx. I'm assuming a few more will work also, including 3DLabs Permedia2.
[HOOK] DJ_Rican: Matrox probably won't be a good Quake2 accelerator.
[HOOK] Dragonass: Originally we wanted Rendition Verite support out of the box, but because of various reasons, including the loss of some key employees at Rendition and also because we have limited manpower here, we may not be able to have Verite support "out of the box". Verite support may be added after Quake2 ships, however. This is something we're tryingn to work with Rendition on, and will hopefully have a decision as to how we want to handle Rendition's

I didn't get a chance to update my .planfile last night, but just wanted to let everyone know that;

ftp://ftp.idsoftware.com/idstuff/quakeworld/deathpack1u.zip

is *the final* bugfixed version.

I just wanted to apologize to everyone that downloaded deathpack1.zip. It had a bad vis error that I somehow didn't catch on the first pass. Death32 was also brightened up quit a bit.

Both maps have been bsp'd for transparency. As usual, these maps are running on inferno.idsoftware.com.

Just a quick note to everyone who's not familiar with turning on transparent water, the command is;

r_wateralpha n (where n is a number between 0 and 1. I use 0.4 personally)

You *NEED* to run GLQuakeWorld to see transparent water. It does not work in software. With consumer level GL boards approaching sub $100 pricetag levels, you know what to ask Santa for this Christmas (along with a copy of Quake II =)

[digsavior] Hook: is the shotgun in quake2 single or double barreled?
[Hook] digsaviour: it's a "supershotgun", single barrel
[GLOCK] Hook: Is it true that the Quake2 will require the cd to play?
[The_Hook] GLOCK: To _start_ playing, yes
[GLOCK] How about in a lan game?
[Mock5] The_Hook, is quakeworld going to be standard issue with quake2 and is there going to be any regular NetQuake still? also, are you going to improve quakeworld any? because right now, quakeworld sucks for me
[The_Hook] Mock5: Quakeworld technology will be an integral part of Quake2.
[Mock5] Hook, will it get any better??
[Dark_Hele] Will quake2 have set levels for translucency, so that there will be more more tampering with r_wateralpha?
[The_Hook] Georg: Correct. Q2 will consist of a huge integration: QUAKE, WINQUAKE, GLQUAKE, and QUAKEWORLD. And at that point previously "unsupported" software gets promoted to "supported" because it will be part of a shipping product instead of a freebie.

[Slipgate] So, Hook, (feel wierd saying that still), what I don't understand is that if everything is drawn in 256 colors, wouldn't viewing it in 16 bit mode be the same 256 colors then? Is it just the smoothing and not really new colors (aside from the colored light)? I never understood that with Doom 95 or GLQuake, given that all the graphics are made with 256 colors anyways.
[Hook] Slip: Good question. Basically, yes, fundamentally our initial artwork is not going to be more than 256 colors, but with 16-bit graphics the lighting will look much smoother and nicer. If you look at the Quake software renderer, as things get very dark they tend to converge on a few basic dark colors. With the 16-bit renderer (i.e. GL) you can see the color differentiation even when it's really dark.
[Hook] peel: It's the lighting, bilinear filtering, MIP mapping, and all the other cool stuff that hardware gives you.
[Vlad|Drak] Hook: is dithering a process that could be done at level-load? Or could individual palettes be constucted for each level?
[Hook] vlad: Sure, if we started with RGB source art then we could do a lot of interesting hacks, but the fundamental problem is that if we quantize down to an 8-bit palette from RGB art, thinks just look fugly. It's better to start with a palette and have the artists work with that than vice versa.
[_defile_] Hook: what is your opinion on microsoft's decision to not develop a stronger link between Open-GL and D3d? wouldn't you say microsoft owes a lot to id for sparking more interest in computers in general than microsoft ever could do alone? I know many of us would never have touched computers if not for Wolf3d or Doom to draw our attention.
[Hook] defile: It sucks that Microsoft isn't behind OpenGL, but we can and will move on without them. Look at the Direct3D games out there and look at GLQuake and draw your own conclusions.
[asToniSh] hook: what do you think about the rest of DirectX (Draw and Input esp.)
[Hook] the rest of DirectX looks reasonable, although they made it unnecessarily complicated
[spRocket] hook: is Q2 by Christmas still reasonable at this point?
[Hook] sprocket: Definitely. We should hit Christmas just fine.

July 4, 1997
------------------

It's the 4th of July, and right now the only people in the office are me and Christian. How pathetic is THAT?

Quick comment about developing for Win95 and WinNT -- bugs manifest themselves differently on different systems. We had an out-of-bounds array indexing bug that just didn't show up on NT, but generated an exception on Win95. That took a few hours to nail down. I've already found two bugs where a floating point exception was generated (the result of using uninitialized floating point values) on Win95, but under NT they were hidden.

Moral: if developing for Win95 and WinNT, test periodically on your Win95 system. I know, developing on Win95 sucks, but it really does save some headache.

[Hook] there are no real vehicles in Quake2, at least as far as I've been told
[Hook] Dark_Helm: All underwater objects will be identically difficult to view, i.e. opacity doesn't change with depth.
[Hook] Blood: As far as I'm concerned Monster3D and Righteous3D and Obsidian are the same thing.
[Hook] thinker: If we made you shittier as you got hit more, then the game would be no fun -- first person to land a hit would win.
[Hook] Blitz: Verite involvement is being re-evaluated.
[Hook] thinker: Quake is NOT about realistic, it's about fun.
[Hook] it's amusing that some scrub is msging me in another window offering to get me the Quake2 beta, then arguing with me when I say that it doesn't exist. *sigh*

Hello,

I browsed by your page for the first time today - it looks great!

I noticed that in your news section a couple days back you quoted the Defiance announcement that was on Redwood's. I'm on the Defiance team, and we've got some cool shit planned for Quake2...

I'm also working on a site called WM_QUAKE2 that will be a major place for Quake2 mod dll programming. The site is going to be hosted by PlanetQuake and will appear sometime next week.

Until Quake2 is released (or I can get my hands on some insider info on how it is structured) WM_QUAKE2's main attraction is going to be the "DLL primer for QuakeC guys" I am writing up. It explains all the inards of a DLL, how to write one in C, how to use the FREE compiler I found on the net, and alot of other stuff I can't remember right now :) Along with that, I'm going to be answering any and all questions QuakeC guys have about the upcoming conversion from QuakeC to ANSI C under Windows. I'm going to have a weekly article that answers the most interesting questions I get, and eventually I'll compile a bigass FAQ for everyone to look at.

Eventually I want WM_QUAKE2 to become the biggest source of information for Quake2 moDLL programmers (I've written "mod DLL" so many times I got sick of it and decided to make my own little acronym :). If all goes well it will have a huge tutorial section and stuff like that... but it's too early to be able to tell how much time I will be able to devote to it.

Anyway, stay tuned to planetquake for info on WM_QUAKE2's arrival...

Later,

Russ

Hi:

I have read that Quake2 will require the original cd-rom in the drive at boot up time. No big deal really, but you might want to find out if (you might already know the answer) this also holds true for -dedicated servers. Obviously 99% of those people running -dedicated servers have no more than (note the clever choice of wording) one copy of quake on cd. But, they are most likely to also be using it on another machine to play as well. So, they have two copies of quake loaded onto two different machines. Not many people are going to buy themselves two copies of quake2, one for their server and one for themselves. If the cd is required for the -dedicated server as well then I would expect a whole lot less quake2 servers to be put up.

Of course this might also have been asked and answered before and I just didn't catch it. If so, sorry. :?)

July 3:

This little note was issued to a lot of magazines by microsoft recently. Just for the record, they have NOT contacted us about any meetings.

All the various dramas in this skit haven't quite settled down, but it looks like microsoft is going to consciously do The Wrong Thing, because of political issues. Sigh.

Our goal was to get the NT OpenGL MCD driver model released for win-95, so IHVs could easily make robust, high performance, fully compliant OpenGL implementations. Microsoft has squashed that. Flushed their own (good) work down the toilet.

The two remaining options are to have vendors create full ICD opengl implementations, or game specific mini-drivers.

Full ICD drivers are provided by intergraph, 3dlabs, real3d, and others, and can run on both NT and 95 (with code changes). Microsoft still supports this, and any vendor can create one, but it is a lot of work to get the provided ICD code up to par, and bug prone. On the plus side, non-game tools like level editors can take full advantage of them.

Minidrivers certainly work fine -- we have functional ones for 3dfx and powerVR, and they have the possibility of providing slightly better performance than fully compliant drivers, but partial implementations are going to cause problems in the future.

We will see some of both types of drivers over the next year, and Quake 2 should work fine with either. We also intend to have Quake 2 show up on several unix systems that supports OpenGL, and I still hope that rhapsody will include OpenGL support (we'll probably port a mini-drivers if we can't get real support).

Once again, we won't be idiotic and crusade off a cliff, but we don't have to blindly follow microsoft every time they make a bad call.

Subject: Microsoft D3D vs. OpenGL
Author: Julie Whitehead at Internet
Date: 6/23/97 10:01 AM

Dear Editor,
You may be aware of a press release that was issued On June 12, by Chris Hecker, former MS employee and developer of D3D [sic]. The statement asks Microsoft to develop a stonger link between D3D and OGL.The press release, was signed by several game developers representing the top tier 3-D game developers. Microsoft is dedicated to maintaining an active relationship with its DirectX developers. In response to this request Microsoft will host the developers included in the statement at a developers roundtable in July. The purpose of the roundtable is to openly consolidate input and feedback from developers. Tentative date for the roundtable is immediately following Meltdown, July 18.

Direct3D is Microsoft's recommended API for game developers with more than 100 developers using Direct3D as the defacto consumer API. OGL is widely regarded as a professional API designed for high precision applications such as CAD, CAM, etc. Our hope is that this round table will provide Microsoft with the feedback required to evolve our 3D APIs in a way that delivers the best platform for our developers.

If you have any questions or wish to speak with a Microsoft spokesperson, please let me know.

Julie Whitehead

7/2/97
WARNING: I DON'T TALK ANY SHIT IN THIS POST AND IT MAY BE SOMEWHAT EDUCATIONAL.
Sorry I didn't post an update on Monday. I took the day off and Tuesday was pretty hectic. So I'll get right to the gist of today's post: Model creation and animation.

First, I build everything in 3DS4. I am not saying this program is better than anything else out there, but I personally know the program like the back of my hand. I started and christened a training program with 3DS3 at Origin way back in '94 and it went pretty well helping me learn just as much about the program as what I taught. In Quake2 I am primarily responsible for character modeling and animation. (Kevin shares this responsibility as well but is gifted enough to do both that and texturing and project management.) This includes enemy animations and view-model weapon animations. It takes me anywhere from 4 hours to a full day to create a character in 3DS4 and about the same for a weapon. The difference being I have to do an additional world model and view model for the weapons. Character models are easier or harder based on how much I can cannibalize from existing meshes (trust me, if I can buy or steal a model with permission and modify it to my needs, I have no pride. In the end you won't be able to tell the difference.) Which brings me to a very good point, boys & girls: DON'T REINVENT THE WHEEL. If you have a choice of buying a mesh of a super-hero or taking a month to build one, buy the damn thing and fuck with it. The Crackwhore is actually a 522-face optimized version of a 10,000 face Steed-perfect wet dream of a model that took me over ONE YEAR to make. Oh and BTW one of the coolest things for an animator or computer artist is that you can set up a figure with the right skeletal or IK settings and DUPLICATE them. As many as you want in a given animation. Think about it.

Shit. This might have to be a two-parter since I have to finish the rocket launcher anim tonight. So when I build in 3DS4 using pre-existing models or starting from scratch I give a moderate concern for face count. Fortunately I've been doing this long enough to get a fairly accurate feel for mesh face-count by eye. I build a model based on Adrian's or my sketch (mostly Adrian's) and then try to optimize it to no more than 600 faces. View model weapons are no more than 400 faces and world model weapons are around 200 faces. Since Kevin and Adrian do the textures (skins), I don't really care too much about that at the time of creation. Well, I DO care to the extent that when I create a base frame for the model, I divide the model or weapon up into segments which will support the planar projection method of generating a base skin.

For example, ALL my character's arms are detached, but the legs and torso are usually one piece. This is so I can get a basic full-frontal torso/legs projection with the feet twisted side-on, and have a side-on shot of the arms thus providing the best area coverage. I usually detach the heads as well. The cool thing about Alias Power Animator is that detaching doesn't have to me 'segmenting' (e.g. a seam between head and neck doesn't have to look like there is a division, but is done for a purely texturing reason. This technique of separating parts for texturing sake is mainly do to our 'planar projection only' limitation of texmake/texpaint but is also valid for those of you lifting mapping coordinates from whatever modeling package you're using. I'm pretty sure that the Valve guys get their mapping from their modeling (MAX, Lightwave?) and I think the guys at Ion are as well.

Okay. Gotta go. Tomorrow I promise to talk about animating and some directory/naming convention/spreadsheet stuff I do to keep track of all this stuff.

Yeah and I lied about talking shit. I've worked for and/or been to many companies: Origin, EA San Mateo, EA London, EA Canada, Iguana, Virgin, Blizzard, Foundation Imaging, Disney Interactive, Apogee, Ego Storm and a half dozen smaller lesser known companies and you know what? Without dissing most of those other guys id Software RULES. Kevin, Adrian and John are three of the most impressive human beings I have ever had the privilege to swing a sword for. Beware friends. I am fucking INSPIRED.
xxxooo

> MedDLe2p was shaping up to be a great product. I like the interface,
> and hope it's as clean and easy to use as NME's will be. I have a
> question: if there aren't any drastic changes in id's MDL format, will
> NME support Quake 2? And what about other games, namely Half-Life, with
> it's skeletal animation system?

You can bet on it. I can support _any_ format that I want, since NME's final version runs with a 16bit paletter, there is no issue as to what the export palette is, since it uses a skeletal system of it's own, it can support other apps that do too. As soon as I get to Florida I'm gonna spend 4-5 entire days a week on the plugin system...There will be little that NME won't be able to do. Thanx for your support.

I've uploaded deathpack1.zip to;

ftp://ftp.idsoftware.com/idstuff/quakeworld/maps/deathpack1.zip

It's death32b (which features subtle QRAD lighting and watervis)
and base32a (which features watervis) running in a loop.

As usual, these maps are running on inferno.

July 2, 1997 (early AM)
------------------

You know, sometimes you know what the Right Thing is, but until you do it, you don't KNOW it's the right thing. I couldn't get SciTech's MGL working today, so I had to find something to do, and that something was to move away from statically binding to an OpenGL import lib and switching to a pure dynamic run-time binding to OpenGL. This is facilitated by manually calling LoadLibrary and GetProcAddress in order to fetch pointers to OpenGL functions. This is a pain in the ass, and there are some minor compatibility issues (e.g. using GLU isn't possible), but I managed to get it to work.

The general scheme is to use a set of function pointers to OpenGL functions. In our case we created a set of function pointers with the prefix "qgl" instead of "gl", e.g.

void (*qglEnable)( GLenum e ) vs. void glEnable( GLenum e );

I then bind each of these manually via:

hinst = LoadLibrary( selected_lib );

qglEnable = GetProcAddress( hinst, "

Now here's the cool part -- "selected_lib" can be any valid DLL with the OpenGL functions we need. On an Intergraph Realizm we'd use "OPENGL32.DLL", but for 3Dfx we can rename their DLL to "3DFXGL.DLL" and specify that instead.

Now here's where things get really cool. For starters, we can now have multiple OpenGL implementations coexisting peacefully on the same system without any conflicts of any type. And, even better, we can change which GL renderer we're using *on the fly*. This means you can run down the hall in your PowerVR renderer, then stop and issue the following commands:

]/gl_dll pvrgl.dll
]/vid_ref gl

And the graphics engine (NOT the entire game) will restart at the exact same spot you were just at, with no changes in state in the whole game. This means you can park somewhere and compare quality between several different OpenGL implementations simultaneously. For example, on one of our systems we have a Permedia 2, PowerVR, and 3Dfx, and we can switch between all three of those dynamically (the PVR driver still needs some work to get up to Quake2 spec, but we're confident that will happen in a timely fashion).

This does have its complications. Since we still want to use GL.H for the various #defines and enums and what not we still need to include it, and that means that I can't call all our functions "glXXXX" and have to use the "qglXXX" convention. This meant grepping through all our source code for GL calls and manually changing them to "qgl" calls. Not a big deal.

You also have to bypass the GDI OpenGL hooks, such as ChoosePixelFormat, etc. but this isn't too bad. You can call into the driver's equivalent function directly by prefixing the "wgl" extension, e.g. "wglChoosePixelFormat". Now, we still have a problem because we can't call our function pointers for the WGL stuff "wglXXX", so those became "qwglXXX", so there is a lot of manually editing shit left and right.

The only real bitch is that we've rendered this non-portable since we now rely on "qgl" being dynamically linked via proc pointers to an OpenGL, and this is very much a Win32 centric concept. If we port to Linux or something else we'll probably need to do a set of C-macros to convert from "qgl" back into "gl" calls, but that shouldn't be a problem.

So yeah, it's a pain in the ass to get up and running, but it only took a few hours and it's SO WORTH IT. Really. Being able to jump back and forth dynamically between different renderers is just plain cool and really makes debugging and level design so much easier.

Two gripes about OpenGL:

1. I'd like to see IHVs provide debugging versions of their DLLs. DirectX does this, and it's a real big help when you're trying to figure out what the hell is breaking in your code. Having an OPENGL32.DLL and an OPENGL32DBG.DLL would be very convenient -- something that basically pops up a MessageBox the moment it notices something bad is happening. This can save a LOT of time when trying to figure out, for example, where you're passing an incorrect enumerant or something into the API.

2. I've bitched about this before on comp.graphics.api.opengl, and I'll bitch about it again -- on the PC there are too many OpenGL implementations, each with its own header file (GL.H). This causes all kinds of conflicts, since proprietary enums are defined in every IHV's header file, meaning that if you want a single binary to support multiple OpenGL implementations with their extensions that you'll have to create a "SuperGL.H" or something similar manually.

This would be easy to fix if GL.H was defined to be ONLY the core set of GL prototypes and definitions for a base OpenGL 1.x implementation for a specific operating system. Then each IHV would have a specific header file that adds ONLY their extensions, constants, etc. For example, if I have an execute that wants to support the following OpenGL implementations:

PowerVR
3DFX
Intergraph Realizm
3Dlabs Permedia2
Dynamic Pictures

I would ideally like to do this:

#include
#include
#include
#include
#include
#include

But today I actuall have to go into 5 different GL.H files and take out the pieces that don't match and append them to the end of a composite GL.H.

This is not fun.

This hasn't been addressed yet in the OpenGL world simply because this is a problem unique to the PC -- workstations typically don't have multiple OpenGL implementations floating around on a single platform.

Not a killer, but a pain in the ass nonetheless.

Next up...the software rasterizer.

[hook] Darin_Z: Been working on getting the GL renderer in Quake2 to dynamically load different OpenGLs. This will help us avoid the stupid "Rename your opengl32.dll" bullshit we're doing today with GLQuake.
[hook] argh! Okay, this modem shit -- it's not EASY to implement the modem code, but it's not exactly impossible. The deal is that it's rather a waste of time -- we feel that modem-modem play is not appropriate for Quake2, and that our time is better spent improving the rest of the engine. Finally, it's just that modem support DOES exist via DUN, so having us add it would be sort of redundant.
[hook] HOWEVER, we haven't exactly ruled out modem-modem play.
[hook] Okay, terminology clarification: NATIVE modem-modem play.
[hook] We're not saying that MODEMs are old tech or shitty. Modems are great for dialing into a server. What we're saying is that MODEM-to-MODEM is probably not a good idea, but as I've said a billion times before, it's possible today and tomorrow via DUN.

Some people have been complaining of problems loading death32ab in GL QuakeWorld. Use;

glqwcl -heapsize 32000

and see if that helps. I should have a final version of the map done sometime in the wee hours of this morning (like 3am CDT)

It will we released on;

ftp://ftp.idsoftware.com/idstuff/quakeworld/maps

John Carmack allowed me to QRAD my death32 map and release it.

I am running a *BETA* version of it right now on Inferno. Please do *NOT* distribute this. I will probably have a final version sometime in the next 24 hours, but if you want to take a peek at how a Quake I map looks like with QRAD, feel free to connect to the server and download the map (1.8 megs).

Death32AB (as it's called temporarily) has been BSP'd for transparent water as well. Yes, I know that some areas of the map are dark, but that's what playtesting is all about.

July 1, 1997
------------------

I generally give people the benefit of the doubt and show respect by default and even bother addressing their arguments somewhat seriously, UNTIL they give me a reason to ignore them out of hand. I really dislike people who ignore valid technical arguments and instead concentrate on someone's history or background, but in this case I'm going to have to dismiss this individual out of hand because he has proven to me, and others, beyond a shadow of a doubt, that he has no comprehension of the facts. I could go into a long back-and-forth war of words, but the simple fact is this -- I know what I'm talking about, and he is, at best, taking wild shots in the dark.

So, in the interests of productivity, I'm dropping it. He's already cost me an hour of work, and that's more than I can spare. The best thing I can do now is to continue busting ass on Quake2 so that when it ships, you Quakers out there will feel like your money was well spent.

As a final note, keep this in mind: it is in our best interests to ship a product that as many as you enjoy as we can possibly manage. It's not in our best interests to ship a product that sucks, or one riddled with bugs. For these reasons we, unlike most other game companies, distribute shareware, demos, and playtests that are freely playable on the net. This is to generate real feedback. As many of you remember, QTEST underwent some pretty significant changes before Quake emerged, and a lot of this was based on feedback from fans everywhere.

Lying to our consumer base, or specifically excluding features that the _majority_ of the consumer base wants for no good reason, is just foolish and bad business.

You can run a successful business in many ways. We choose to do it by writing a great product and by cultivating a loyal fan base. This is the right thing to do. Not all businesses feel this way, but we do. None of us here are hurting for money, and even if lying about something would gain us 10% more sales, the fact is that it's not worth it.

Guy Kawasaki once said something like "Never lie, never cheat, and never steal, because life is much simpler when you don't have to remember what you've lied about, who you've cheated, or what you've stolen."

I'm a staunch believer in this philosophy, and it saddens me that I'm accused of lying by someone who has never met me and, more importantly, has demonstrated an inability to prove that we have lied. It takes more than innuendo, made-up facts, "photographic evidence" that is not released to the public, and unfounded allegations to be proven correct. Fortunately, I am quite confident that these are all that will ever be provided.
Alrightee, back to work....

> Mr. Carmack:
> Since Quake 2 will be played with the CD in the CDROM it tends to
> make the gameplay choppy and broken up from time to time when
> accessing program data or music.(Tombraider) a good example. Can
> you fix this by just having to start sequence of the game with the
> CD in the drive and then be able to take it out once the game
> begins? One more question. Since Quake 2 is not a sequel to Quake
> how will id carry the story of the search for who or what quake is?

You can install to your local drive, then the cd is only needed at startup.

Quake 2 has no story relation to quake 1.

John Carmack

June 31, 1997 (early AM)
------------------

You know, I've tryed to stay pretty temperate with my .plans, and I've stayed out of the goofy sniping that other folks are doing with their .plans, but this is the first time I've personally been attacked by a complete and utter stranger, and I find it a little disturbing, so I'm going to take a little break today and address the issue of my "lies" posted at http://madness.unreal.org.

Some poor misguided soul at unreal.org has decided, unilaterally, that I and id software (by association), are lying about modem-modem support, so it seems I should clarify my earlier statements and correct this fool's technical inaccuracies.

Now, I'm on a 14,400 connection so it pretty much goes without saying that I don't play much Quake over the 'net. I do, however, play it for about an hour a day on a direct connection. Both myself and the guy I play against have noticed that a lot of the apparent lag-related bugs that people dislike about Quakeworld are equally present in our games, so we started recording demos of everything in order to study them more closely at a time when we weren't "in the heat of battle".

It's unclear what speed and what version of Quake is being used. There were bugs in earlier versions of QuakeWorld (that were fixed) where individuals could suffer "over damage" do to dropped packets.

The demos that we've recorded - and I'm talking about dozens of demos amounting to hundreds of hours - are in effect photographic evidence that the deathmatch code in Quake is bugged to a ridiculous extent.

It's interesting that I hear about this via this manner. Bugs can't be fixed unless someone sense in a bug report. We have not witnessed any of these bugs, and if such a bug exists we would obviously like to.

It's also interesting that with the number of QuakeWorld servers running and the sheer number of games going on that I haven't seen any bugs of this type being reported. If it is as common and as egregious as he indicates, then I would expect it to be a pretty significant bug.

The fact of the matter is that most people are pretty happy with DM play as it is today, and any bugs that do exist are minor enough that they aren't being reported.

We would love to write bug-free code, but we're human, so bugs will exist. We don't ignore them, but we can't fix bugs no one tells us about. Accusing us of lying in a public forum, without having approached us privately, just seems like a particularly excessive way of getting a bug fixed.

But, as I mentioned, this is not a bug I have ever heard of.

It strikes me as rather obvious that id must know about these bugs. For them to deny that they are aware of them would be for them to admit that they did not adequately playtest the game. So, with the proviso that they knew about them, one has to wonder why they weren't corrected before the game was released. The answer, in my mind at least, is an obvious one - they knew that 99% of multiplayer games would be played over the Internet, and the genuine bugs in Quake could simply be attributed to the dreaded effects of "lag". Essentially, they must have left the bugs in because they felt they could get away with it.

No game is PERFECTLY playtested, that's just a fact, but we DID release a widely available QTEST to the net for free to hash out most of the bugs. That is a far more strenuous playtest than you will see from most companies, who usually distribute beta copies to a few dozen sites for playtesting. QTEST is arguably one of the most thoroughly play-tested games in the history of mankind.

I would argue that 99% of multiplayer games are NOT played over the Internet, and tossing out arbitrary numbers to boost an argument is unacceptable. The vast majority of games that I have personally played have been on LANs. When I worked at 3Dfx, when I played at home, and even here at id, we played Quake on a LAN, where pings are uniformly very very low. Thus the notion that we'd use lag as a mask for known bugs is just plain silly -- the first people to spot these bugs would be id employees, since we deathmatch quite a bit here on a very low ping network (<35 ping for most of us playing at inferno), and the thousands of others playing on LANs would notice grossly obvious bugs (such as the one you indicate exists) pretty damn quickly too.

The number of people playing on either a modem or a direct connection may be small [...]

I'll let the above statement speak for itself.

With reference to Brian Hook's comments, "this is the choice you'd have to make - modem-to-modem, or Internet play, but not both. They require radically different programming models". If it's so difficult to support all three types of connection then I'd like to hear an explanation of how it was possible in the original Quake.

A clarification. My statements seemed to convey the impression that I said that it was _impossible_ to do modem-modem support directly. This is not the case. Quake1 had modem-modem support, and as those of you who played it found out, the person sitting on the host had a pretty significant advantage. A ping of 0 vs. >100 can make a big difference, oui?

My statements were meant to indicate that modem-modem support was effectively _pointless_, not impossible.

The simple fact is that the multiplayer code will be changing in the sequel, and would therefore require the support for all three types to be rewritten, which would involve a lot of work.

These arguments are based on a lot of assumptions that are, quite simply, the musings of someone ignorant on the subject. Here are some simple facts of the matter: whether modem-modem, IPX, TCP/IP, or a magic network fairy are used as the _transport_ mechanism is largely irrelevant to the actual network gameplay management code.

Three code bases wouldn't have to be touched, we'd just have to write modem support in, which would take time that we don't feel is worthwhile. No "hidden bugs" or other crap, it's just that modem-modem play wouldn't be that much fun for many customers. I would say that modem-support is much like native support for 3Dfx -- the big question is "Why?". DialUp Networking provides support for modem-modem play if people want to inflit themselves with this.

Supporting modem-modem isn't a question of laziness or having to touch too much code or finding bugs or some such other nonsense -- it's simply a question of whether it's worth our time.

Right now it's not.

As I stated on IRC, _philosophically_ and _technologically_ modem-modem play with the Quake networking model is simply not a Good Idea. It's not impossible, and the DialUp Networking hack works just fine with WinQuake and should work fine with Quake 2, "fine" being defined as "two folks can play against each other, but one of them is probably going to get his or her ass kicked because of shitty ping."

I think I can safely say this individual is talking out of his ass.

It seems obvious that, considering the small number of people that would actually use anything other than the Internet support, id do not consider that extra work to be worth while.

It's obvious we don't consider native modem-modem support to be worthwhile, but the reasoning outlined above is just wrong. We based the decision on lack of native modem-modem support on technical reasons. We can say this with some degree of authority. Mr. Commentator above simply doesn't have the authority, knowledge, or background to determine our motives.

That, combined with the fact that dropping support for consistently low-lag connections will actually help to maintain their public image, makes their Internet-only decision a sensible one for the immoral minds of business. It does not, however, change the fact that what they're telling the public is deceptive and, essentially, a lie.

And the above statement is unfounded, baseless, without corroborating data, and, quite frankly, libelous.

I'm writing this because I hate to see businesses telling lies to their customers. Actually, let me rephrase that - I don't mind them telling lies, but I hate to see them getting away with it. Over the course of a short-lived voyage into business that I am now thankfully no longer a part of, I have seen this sort of thing far too many times. I've heard this sort of lie. I've told this sort of lie, and I know when someone else is telling it.

It amuses me to see that because someone else is capable of immoral behaviour that, by projection, _everyone_ must be capable of that same behaviour.

I'd hope that the above analogy of "since I've lied before, you must be willing to lie too!" doesn't sway too many people.

The fact is that this individual's posting was factually incorrect, and rested on a rather thin line of assumptions, presumptions, what-ifs, and outright cynical guesses about another company's motives. Very little, if any, factual data was presented other than "I've seen some bugs in deathmatch", which was somehow extrapolated into "and for this reason they aren't providing modem-modem support natively".

As for other "lies" or misinformation on my part, it's quite true that I'll occasionally screw up and say something that isn't correct. I'm a new employee here, so I haven't exactly sucked up 8 years of knowledge in 3 weeks through some form of mental osmosis. When I fuck up, I'll admit it, it's that simple.

But I do not and would not intentionally lie about anything of this nature, and this individual's statements amount to libel. It's okay to have an opinion, but he overstepped his bounds considerably by presuming and assuming quite a bit without doing proper fact checking.

June 31, 1997 (early AM)
------------------

I'm working on the software renderer (finally!). I'm going to be using SciTech Software's MGL library for virtualizing fullscreen/windowed programming under Win32, which is going to make our lives MUCH more convenient. I'm doing that soon, and after that it's time to getting down to doing "nitty-gritty" real work, including putting in transparent particles and water/glass surfaces.

It's becoming more apparent that we're going to use LoadLibrary and GetProcAddress and dynamically link in OpenGL instead of doing load-time binding. This is a pain in the ass since I have to build a GL function pointer table and init it, which is a lot of typing, but it shouldn't be a real big hassle and I'll only have to do it once.

This has several nice beneifts though. For starters, we can get rid of the plethora of OPENGL32.DLL files we have laying around, which cause ALL kinds of ugly coexistence problems. The batch file/directory hack we're using right now is just the Wrong Thing. With this new architecture we'll let the user select from a menu for the rendering system they want, e.g. a list like the following would be conceivable:

SOFTWARE RENDERING
RENDITION VERITE
WIN32 OPENGL
3DFX (OPENGL)
POWERVR (OPENGL)

And in _theory_ if someone did an alternative rendering DLL, like a Direct3D rendering DLL or something similarly hideous, it would just magically show up on the menu as an option. We're not encouraging third parties to do this though because of the support issues.

Anyway, now that my computer hardware problems are largely settled I'm all happy that I can get back to work. I still have minor bugs to fix with QE4, but those are slowly but steadily being squashed.

I just recently formed a team of programmers that are gearing up for some Quake 2 mods but I need help bringing in some more programmers and artists for the team. I was wondering if you could include something in your news section informing people about the new group. I wrote up a message below that can be inserted into your webpage if it's ok with you.

A new programming group titled Defiance is looking for programmers with experience in dll programming, C programming and/or experience with CGI Scripts. They are also looking for talented computer artists for the team. Email Jason for details or check out the Defiance Homepage.

June 29, 1997
------------------

Nothing specific to Quake2 in this plan update, just some advice for those of you writing OpenGL programs.

- you really need check OpenGL for errors frequently and predictably via glGetError/gluErrorString. Doing this will really save you some headache down the road.

- when using multiple RCs, you need to *always* know which RC will be current at a given time you execute some GL calls. With Windows this can be pretty tough to do because of the event driven model -- GL actions may be the result of many different Windows messages, or may be the result of your program doing something while idling. For this reason, you need to know exactly which RC is current when you're calling into OpenGL. An easy way to do this is to simply call wglMakeCurrent( NULL, NULL ) when you're done rendering. This tends to reveal which groups of GL calls aren't setting their context correctly.

June 28, 1997
------------------

The GameSpot article that says Quake2 is supporting Direct3D and a 3Dfx-native version is INCORRECT. At this time we have NO intention of supporting Direct3D. We also do NOT have a 3Dfx-native version of Quake2 planned -- GLQuake and Quake2's GL renderer provide this functionality.

June 28, 1997 (early AM)
------------------

Quick note: PLEASE stop posting logs of all my visits to IRC, since I really don't have much to say anymore on IRC, I'm mostly there seeing what others are talking about. My visits are pretty boring these days.

If you DO post a log, at least edit it so I don't look like a complete dork all the time....

Just started clearing out Sandy's office to make room for our test systems. It looks like the three primary test systems will be a P90, P5/200MMX, and a Pentium 2/266, defining our various low, mid, and high-end computers.

It really sucks that I can spend an entire day at work and not write a single line of code -- I've spent most of today dealing with getting computers to work. What a pain in the ass. *sigh* Tomorrow xian and I are going to go get the rest of the stuff we need to set up the lab, and hopefully by tomorrow night we should be rocking. I'll also likely set up a work area in there for system tear down, configuration, and testing.

On another note I tried to get QE4 compiled and running on a DEC Alpha, however it turns out the DEC Alpha version of Microsoft Visual C++ is only at 4.0, at least the copy we have is. Which means no OpenGL 1.1, which Quake2 and QE4 absolutely require. So until I get MSVC 5.0 (which I hear is flaky as hell)

Saw a comment on the WAVE Report on multimedia (http://www.fourthwave.com) that the TriTech Pyramid3D doesn't seem to be doing so hot with finding OEMs. Ouch, so maybe that one isn't going to make a difference for Quake2, which would really be unfortunate since they promise to have a full real OpenGL implementation.

Also mentioned is the new OAK chipset, which sounds pretty cool. Unfortunately they don't seem to mention OpenGL support. I have an e-mail in with them so hopefully I can get a developer board and convince them to do some OpenGL drivers.

Next week I'd better be working on the software renderer in earnest or I'm going to be sorely pissed. It's amazingly easy to get distracted here -- I really like working the late hours when distractions are minimized. When it's just John and I we get a lot of work done.

Disruptor and I discovered that Microsoft makes a black version of the MS Natural keyboard. Needless to say, I own one now. I feel more productive already. When I get the black Logitech 3 button mouse, I think I'll be REAL productive. If I had an all black computer, well, I'd be psycho cool. Dare to dream, I say...

Saw "Face Off" tonight. Pretty entertaining if you can swallow the rather far-out-there premise. I still think I prefer John Woo's older movies with Choy Yun Fat, e.g. "Hardboiled" or "The Killer" or "A Better Tomorrow".

6/27/97
Well, well, well. It seems that post E3 summations have been pretty good to us. Not only does it feel like I eat breakfast all the time now, considering the competition (or trying not to) our criticisms were very mild. To give our code guys their due (you know that CARMACK guy) however, they did do about six weeks of code merging and converting in two weeks so I was impressed that the monsters had as much brains as they did.

In my recent baiting/gloating/soap-boxing I completely forgot to mention the Art Institute graduation ceremony thing. I basically just stood up in front of (500?) or so people (staring at me like I was this source of enlightenment) and told the graduates that education is only half the equation at best. The rest is all these (seemingly waning) concepts like strong and positive attitude, dedication, hard work and perseverance. (Don't faint when I say that I said this) Like it or not we share the planet with other people and have to be somewhat socially successful if we want to get anywhere within a company or organization. I continually struggle (no shit) with saying what's on my mind and how I feel, and saying the best thing for the audience/person at the receiving end of the verbiage. While intellectually I see the need for all of us to get along, my white trash, muscle car, football-loving, fighting, fucking, motorcycle riding, pool playing, beer-drinking, Conan wannabe ASS says to crush all who annoy me. I must say though that judging from your gracious e-mails (love and hate), speaking my piece is not such a bad thing and at the very least is entertaining. So for all you Hypocrites (yeah, you-who-recently-waged-war- with-the-former-lord&master-but-now-cries: "Why can't we awl jest git along?"), PC Police, Pussies and Whiners: FUCK YA.

So on Monday, veering away from my usual, um...let's see..."egotistic, self-centered, self-serving diatribes" I'll start posting start to finish how I build and animate models for the game including hardware/software, etc. Thanks again for the support, people.

Oh BTW: I did mean mis-aligned as in a certain type of 'texture counting'. But then again that wouldn't be talking shit or anything. Nice picture of the money too, Dude.

[Hook] morbid: I'm working on hardware acceleration, so I work with the hardware vendors and do testing and suggestions for John. I haven't ramped up on the rendering engine yet, since I've only been here for three weeks.
[Hook] But I plan on taking over the software renderer for John.
[Hook] I don't know how many weapons are going in, I think 12-13 though if I remember Steed correctly.
[Hook] No deathmatches with Quake2 have occurred as far as I know.
[Hook] No, there are no plans for modem-modem play.
[Hook] I think we're acting like Quake never happened, but that's a question for PaulJ.
[Zith] hook: are you guys keeping any of the code from quake1 or has it been totally rewritten?
[Hook] A lot of the code is still around, but modified.
[Hook] I think Quake2 will likely be a bit slower, mostly because we're doing more stuff like colored lighting. And the levels are a lot more complex and bigger.
[Zith] hook: any features you'd like to see in quake2 that won't make it? Are you guys going all out, or are there some compromises?
[Hook] Zith: No, all the features I want are going to be in there. We're going to do as much as possible but still ship by Christmas. Really neat new stuff will likely wait for Trinity.

June 27, 1997, part 3
------------------

3DLabs brought up an interesting point -- if you're syncing to vblank then it's possible to increase overall framerate slightly by upping your monitor's refresh rate. So I moved the Permedia2 from 60Hz to 75Hz, and sure enough the framerate for 640x480@16bpp jumped from 18.7 to 19.2fps. This means that overall performance went from 18.2 to 19.2fps (~5.5%) just by doing small tweaks to the display settings.

June 27, 1997 (noon)
------------------

According to 3DLabs the _are_ syncing, contrary to what it looked like to me. They gave me some tips to try and improve performance, but it didn't really help all that much. Numbers barely increased.

(FPS scores for TIMEDEMO DEMO1, no status bar, P5/200MMX w/ 32MB of RAM)

Card 512x384 640x480 800x600

Voodoo (nosync) 47.6 32.7 N/A
Voodoo (sync) 36.4 26.2 N/A
PowerVR PCX2 26.1 22.4 18.1
Permedia 2, 16bpp 23.7* 18.7** 13.0
Permedia 2, 24bpp 21.1* 15.9 N/A

* 512x384 window on a 640x480 desktop
** using 8 sub-buffers instead of 3

June 27, 1997 (early AM)
------------------

Okay, we need the Brian Hook FAQ, since I'm getting the same questions every night on IRC:

1. I got this job because I knew John Carmack and Michael Abrash for several years before being asked to join. Yes, I was asked, I didn't ask. I didn't send in a resume. I was actually gainfully employed (owned my own company even!) and quite content doing what I was doing, but id managed to woo me away from...me.

2. To be successful in the game industry I have simple advice:

- never lose faith
- keep coding..practice practice practice!
- don't be an asshole
- do what's best for you
- don't sell yourself short
- keep trying
- have rocking demos available to show people
- don't get discouraged

3. NO, ID IS NOT HIRING AT THIS TIME! Don't ask me for a job or hint at it, since I don't have any control over that.

4. NO, I WON'T GIVE TOURS!

June 26, 1997 (late PM)
------------------

Texas Instruments came by and dropped off a stack of Permedia2 boards that we could use for testing. It's become pretty apparent that the 3DLabs drivers are significantly less stable under Win95 than under WinNT. I'm unsure if this is related to the drivers themselves or the ICD implementation from Microsoft under Win95.

So we reran some benchmarks today. Today we tested the Voodoo vs. Permedia2 vs. PowerVR PCX2. The results are as follows:

(FPS scores for TIMEDEMO DEMO1, no status bar, P5/200MMX w/ 32MB of RAM)

Card 512x384 640x480 800x600

Voodoo (nosync) 47.6 32.7 N/A
Voodoo (sync) 36.4 26.2 N/A
PowerVR PCX2 26.1 22.4 18.1
Permedia 2, 16bpp 23.7* 18.3 13.0
Permedia 2, 24bpp 21.1* 15.9 N/A

* 512x384 window on a 640x480 desktop

Some observations and comments.

1. Voodoo still kicks the living shit out of everything in existence. I'm sure that this disparity between 3Dfx and the rest of the known world won't be as obvious in the future, but for the time being the Voodoo is still the pimp master chipset.

2. There is a huge performance difference between enabling sync vs. nosync with the 3Dfx, for obvious reasons (use SET FX_GLIDE_SWAPINTERVAL=0 to disable sync). Whether a game is playable sans vertical synchronization is debatable, but the tearing _is_ visible and a little disconcerting. But if frame rate is all you care about...

3. The Permedia2 has many of the same problems as the Permedia and the PowerVR boards, specifically lack of blending modes that are compatible with GLQuake and Quake2. Since this now brings us up to two boards that fall into the classification of "boards that run Quake reasonably yet won't support colored lighting" it's becoming more apparent that we need to really look at supporting monochrome light maps.

4. There is only a very slight performance hit for running in 24bpp vs. 16bpp with the Permedia2 - 10 to 15%. And it looks MUCH better in 24bpp - the Permedia2 has pretty startlingly grainy dither patterns when running in 16bpp.

5. Permedia2 has several distinct advantages over the other chipsets. For starters, it's a full Windows accelerator with VGA support. It also includes a _full_ OpenGL implementation (well, as full as 3DLabs good manage *ahem*). While performance for the Permedia2 dragged behind the others by a reasonable amount.

6. The Permedia2 was notably lack per-pixel MIP mapping, and this becomes _real_ obvious when you get used to playing with MIP mapping. It's also unclear whether the Permedia2 was synching to vertical retrace during swaps. If it wasn't, it's performance will likely degrade even further once syncing is enabled (if it is at all).

7. I'm still confident that if we tweak Quake2 a bit (i.e. doing something to enhance particle system performance and multitexture stuff) that the PCX2 will get pretty close to the 3Dfx in terms of real world performance (i.e. with sync enabled). If we get a 30-40% increase in performance (which isn't out of the question), that's enough for it to catch up. Similar performance gains for doing the same thing with the Voodoo likely won't give us as large a return, since the Voodoo is fill-rate limited. Maybe a 10-15% performance increase would be possible.

The Permedia2 is beginning to look like the "No Brainer Cheap Level Editing Board". Its performance in QuakeEd is exactly half of that of the Realizm, but a Permedia2 board w/ 8MB should cost well under $1000, while a Realizm would cost many times that. Not only that, but once we hack in the support for white light maps the Permedia2 might even make a good GLQuake/Quake2 board if you run at a lower resolution (400x300?). Lack of colored lighting is a pretty big bitch with the Permedia2, since a level editor won't be able to test lighting on a Permedia2, but other than that it looks like a fine level editing graphics adapter -- reasonable performance, features, and price.

And it runs under both Win95 and WinNT.

The Realizm still outclasses the Permedia2 in every way, but at a pretty hefty increase in price and also at the cost of losing Win95 support.

Anyway, I'm pretty damn happy. We now have three boards that will easily run Quake2 by Christmas. I'm still waiting on the Rendition V2200, ATI Rage Pro, and NVidia RIVA128. I'm also anxious to test the E&S 3DPro and Glint MX to see how well they represent the high-end of WinNT OpenGL accelerators.

Best case scenario right now gives us around 8-10 boards capable of running Quake2 out of the box by Christmas. These boards would be the Voodoo/Voodoo2, ATI Rage Pro, NVidia RIVA 128, TriTech Pyramid3D, Rendition V2200, 3DLabs Permedia2, PowerPVR PCX2, Voodoo Rush, and whatever else is available in the consumer space. Obviously some of the higher end CAD boards would hopefully run it, including the Intergraph Realizm and Intense 3D 1000, Dynamic Pictures Oxygen (although they have LONG way to go...), Real3D R3D 100, E&S 3DPro, and 3DLabs Glint MX.

If I have 4 consumer accelerators and 2 high-end accelerators "Quake2 Ready" I will be very happy. If I have significantly more than that I will be abso-fucking-lutely ECSTATIC, and I think 6 consumer accelerators and 4 high-end accelerators isn't out of the question.

Things are looking up in the hardware world and for OpenGL in general.

Slipgate: Alright, first, what did you think when you first heard that they were considering a grappling hook for Quake 2.
Mike: I thought it was the most awesome thing I'd ever heard. I never dreamed that my little QC hack job had been cool enough to get Tokay's attention. I even sent id an application, hoping that maybe they were impressed enough to hire me. Never got a reply... oh well.
Slipgate: Were you pissed you didn't get a reply from them about the application?
Mike: Not really. My ISP at the time was so twitchy that my application could easily be cycling through several servers in Zimbabwe right now. I probably should have sent in more applications, but I never got around to it... coding takes a lot of time, and college takes even more.
Slipgate: Did you ever ask if they received it or did you just give up in frustration (or any other emotion)?
Mike: So it's really nobody's fault (ever notice how people always say that, instead of "I screwed up"? )
Slipgate: Yes, I do.
Mike: I asked a few times on IRC. Trouble is, on IRC, whenever some id guy shows up, he gets bombarded with dozens of questions, and mine always get lost in the shuffle.
Mike: Dis did tell me that they aren't seeking any more employees right now, though. Carmack wants to keep it small.
Slipgate: Oh :). Alright, what did you think when you heard the grappling hook wasn't in Quake 2.
Mike: It sucked. I was kinda hoping to get at least parenthetical mention in Quake 2 (imagine how that would look on my resume). I might even be able to get a job programming, instead of all these temporary box-moving and assembly-line jobs I've been working. I'm still kinda depressed about that, but I suppose Carmack et. al. know what they're doing. Besides, I can always write another hook add-on. (Some levels that made use of the hook would have been nice, though... )
Slipgate: what programming languages (aside from QC) do you know? Assembly, C, C++, Pascal, and Basic, I assume.
Mike: I know BASIC, Pascal, ASM, FORTRAN, COBOL, RPGII, C, C++, and a dumpload of scripting and other weird languages. Most of these I learned as part of a "well-rounded" cirriculum at JP Tech (motto: "We used punch cards when punch cards weren't cool!") Slipgate: Wow. So, is there anything else you'd like to tell people waiting for Quake 2 or potential employers or anyone?
Mike: Yeah... don't release the source code.
Slipgate: How old are you?
Mike: I'm 25.
Slipgate: Cool. What coding work have you done before?
Mike: I've never actually done any coding work. Sad, but true. Can't get a job without experience, and can't get experience without a job, is the way the programming world works. Aside from writing a few minor video games, I really don't have any non-educational coding experience.
Slipgate: Well, homebrew crap is the best crap in my opinion. Teaches you the most.

> is that one chick still gonna be in q2? was she a player or an enemy?

undecided

> is it true that after the player fires a grenade, he flips the enemy off?

Yes, that was in the original animations, but I don't know if it's going to stay in.

Brian

Yes, Sandy Petersen has left, but for all you Quake fans, don't worry about the impact this will have on Quake 2. Sandy's departure from id was amicable because it was apparent that Sandy and id Software had different visions.

By leaving id Software, Sandy is now free to pursue his own goals. This will not tangibly affect Quake 2, because he had not been significantly involved.

We wish Sandy and Ensemble Studios the best of luck with their future endeavours.