Okay, a couple of quick things:Quake2 Chick - Dyno
- Fullscreen Rendering
We're probably going to stick with DDRAW for fullscreen software rendering, but I haven't implemented it yet so I don't know what issues will creep up, but whatever they are we can solve them (hopefully).
- 3D Hardware
I have new drivers from Rendition for their V2200, and ATI sent me a couple of their Rage Pro boards to test. When I get to a stopping point I'll do yet another round of tests, and maybe even test on the P2/266. At this point I'm disinclined to do much testing until we can get numbers on Quake2, since GLQuake is not necessarily indicative of what we're doing today.
- The Epic Deal
Alright, I blew out of control and was overly abusive to the Epic guys. One thing I keep forgetting is that an interview involves a great deal of spin doctoring and bias on the part of the journalist, so often times the interview comes off massively skewed. A plan file, on the other hand, is pure, uncut, and unadulterated "what you have to say" -- and in this case, there's no excuse except naivete and overzealousness on my part for blowing out of control like that.
So my apologies to Perry, Schmalz, and Sweeney.
I guess my opinion of magazine journalists has been steadily dropping lately, and I just need to start taking print ads with a grain of salt. A journalist isn't trying to get out information or the truth, they are typically trying to get some shit stirred up -- controversy and animosity sell magazines. And I played into their hands beautifully, since I'm sure they made some sales of their magazines from .plan. Oh well, you live and learn.
This really bothers me a lot, since I think BOOT is overall a pretty cool magazine.
- MSVC 5
Installed MSVC5 + SP1 and it seems to work. Will mess with it some more and if it looks stable we'll switch over completely.
The show "Oz" on HBO is fucking insane. Janeane Garofalo is #1 on my list of people I want to marry.
The 3DNet service bot is now up and running.Maiden Voyage - Dyno
Drop by the oper's channel, #underworld, to inquire about registering a channel.
To check to see if a channel has been registered already, try
/msg lobotomy chaninfo #chan
Please note: Major game channels are reserved for their publishers and typically do not have ops (The standard for 3DNet).
(To connect to 3DNet, you can use irc.3dnet.net and it will connect you to a random server)
>How does id plan on supporting the Quake 2 programming community? WillPaul Jaquays .plan update - Slipgate
>there be any kind of SDK released (documentation, example source code,
There will be a ton of source code released.
>Is there any reason why programmers won't be able to create .DLLs using any
>tools that they wish (VC++, VB, etc)?
If you do it in something other than C / C++, you would have to reimplement all the functionality in our base game.dll. Its possible, though.
>Do you know of any freeware/shareware compilers that can create DLLs? It'd
>be a shame to alienate all those creative programmers that can't afford a
GCC and LCC can both create windows dlls and should work, but we haven't tested either of them.
>Based on the fact that Quake 2 will use .DLLs, what are id's plans
>concerning non-wintel platforms? I understand that in the "big picture",
>these other platforms don't really add up to sqatto.
The dll's should be source code portable to all architectures, but they will need to be recompiled.
>What are your security/virus/trojan concerns regarding user-created .DLLs?
>It's entirely possible for Joe Programmer to write a patch that hides a
>"feature" like smoking the hard drive of anyone who frags Joe 3 times in a
>row. I'm assuming that the best solution would be for programmers to
>submit their source code to some trusted authority that could review,
>compile, and distribute it.
Yes, it has some scary issues.
>In Quake, it's quite difficult for programmers to alter the status console.
> How will this be different in Quake 2?
It is fully programmable. You will love it.
>In Quake 2, will it be possible to run more that one patch at the same time
>(assuming that they don't have any fundamental conflicts)?
No, the dll is still monolithic.
>I'm guessing that in addition to being much faster than QuakeC, DLLs will >also provide more functionality. Is this true? Can you elaborate?
You can do any system calls you like. Saving player databases or sideband communicating with other servers, for instance.
QUAKE STORYJohn Carmack .plan update - Slipgate
I've had a request (which means that there's a lot more of you out there who don't write) to explain why I'm saying that Quake 2 is not a sequel to Quake. The word sequel implies a continuation of what has gone before. In this case, a continuation of the battle against Quake, the mythical overlord of evil, by soldiers fighting in an undefined army in undefined places. Although many of the features of Quake 2 will be similar to Quake players (such as a 3D environment, some weapons that function similar to those of Quake, lava, slime and use of game's logo in certain special game powerups), it is not a continuation of the Quake story.
With Quake II, id has chosen to follow a different story line (and they did this before I got here). Instead of a vague "Kill the minions of Quake" sort of imperative, we have created a brand new story with a solid, homogenous, entirely futuristic, totally militaristic story line. In Quake 2, you are a soldier in the TCM (Terran Confederation of Man) army, a combined force put together from the surviving armies of nations on the planet Earth and those of Earth's colonies on the Moon and the new independent nation of Ares on the planet Mars. Humanity is commited to what we hope will be the terminal battle of an ongoing war to not only repell alien invaders from our system, but to destroy their ability to make war of any kind. The battle (in this episode) takes place on the planet Stroggos, the alien homeworld, the core of their barbaric "civilization." Levels are designed to be played in a logical, sequential progression. And here, your mission doesn't end until the big guy, the core of the problem goes down for the long dirtnap.
OK, now WHY are we calling it Quake 2, when it's not really a sequel to Quake? Several reasons. Trademarking. The names we were going for, the ones that to our thinking, really expressed the concept and theme of the game were owned by someone else (when it appears that you may have money to actually cover real or imagined damages, "foxxing" really gets ugly. They don't just tell you to cease and desist). We kept putting forward names to our copyright attorneys and they kept telling us "You're not safe from liability with that one." The deadline for having our real and true name in time for E3 came, and our hands weren't grasping that one great name. And there it was waiting for us like an old lover ... our working title ... Quake 2. It knew we'd come home to it at last. It should have been obvious. We've built up a great deal of name recognition with Quake. We shouldn't just throw that away.
Now let's get back to ol' Quake. When I was in Role Playing Games, it was common practice for people to play pre-made scenarios (kind of like Quake is a premade scenario). Often, the writer of the scenario would leave some unanswered questions in it. Dungeon Masters would latch onto these and make new adventures that resolved those story lines (sort of like home brew Partial Conversions). Id has left a big story thread hanging here ... where's Quake? What's he like? What are his powers? Might be real cool if somebody ran a contest to create the ultimate Quake PC, a couple episodes of single player game action in which the player actually gets to confront the mythical Quake in his lair ... and take him the cleaners.
I've been helping Bear just a teeny bit in getting this out, mainly by confirming that it runs on my Mac at home, which is the baseline machine (a 6100 Power PC). If you don't have a 3 button mouse for your Mac yet, get one to play this game (I like the one from Logitech).
QUAKE 2 EDITOR
I HAVE THE POWERRRRRRR!!! The new BSP system just landed last night and John Carmack linked it to our editor tools. Oh, MY!! The things we can do with brushes now!! Christian's map that was taking a full day (+) to BSP, zipped through in 39 seconds!!! I can make any texture squirm and warp, flow like a river, act like water, do damage, be slippery, glow, be transparent, be really transparent .... the possibilities are near endless. WOW!!
Duty calls (and boy is my duty ever fun!!)
I don't listen to a lot of music, so here's the books I'm listening to, and/or reading in my spare time:
HONOR BOUND by W.E.B. Griffin (WWII military fiction about the Marines) (on book tape)
EXECUTIVE DECISIONS by Tom Clancy (more tales of Jack Ryan in Washington. Picks up where DEBT OF HONOR ended).
I want to apologize for some of the posturing that has taken place in .plan files.
I have asked that attacks on our competition no longer apear in .plan files here. I don't think it is proper or dignified.
If everyone clearly understood that an individual's opinion is only that -- the opinion of a single individual, I wouldn't have bothered. Unfortunately, opinions tend to be spread over the entire group, and I am not confortable with how this makes me perceived.
Building up animosity between developers is not a very worthwhile thing.
A little chest-beating doesn't really hurt anything, but putting down other developers has negative consequences.
I think that we have a track record that we can be proud of here at id, but we are far from perfect, and I would prefer to cast no stones.
The user community often exerts a lot of pressure towards confrontation, though. People like to pick a "side", and there are plenty of people interested in fighting over it. There are a lot of people that dislike id software for no reason other than they have chosen another "side". I don't want to encourage that.
Magazine articles are usually the trigger for someone getting upset here. Its annoying to have something you are directly involved in misrepresented in some way for all the world to see. However, I have been misquoted enough by the press to make me assume that many inflamatory comments are taken out of context or otherwise massaged. It makes a good story, after all.
Sure, there ARE developers that really do think they are going to wipe us off the face of the earth with their next product, and don't mind telling everyone all about it. Its allways possible. They can give it their best shot, and we'll give it ours. If they do anything better, we'll learn from it.
Launched from a giant SPACE carrier, you are part of a secret ASSAULT force sent through an INTERPLANETARY gateway in single manned PODS. Shortly after landing on an ALIEN surface you learn that HUNDREDS of your men have been slashed to just a few. Now you must FIGHT your way through heavily fortified MILITARY installations, lower the city's defenses and shut down the enemy's WAR machine. Only then will the fate of HUMANITY be known.Sounds cool :).
Larger, Mission-Based Levels : You have a series of complex missions, what you do in one level could affect another. One false move and you could alert security, flood an entire passageway, or worse.
Superior Artificial Intelligence : This time the enemies have IQ's the size of their appetites. They can evade your attack, strategically position themselves for an ambush and hunt your ass down.
In-Your-Face Sound and Graphics : Hear distant combat explosions, and rockets whizzing past your head. And with a compatible 3-D graphics accelerator, experience smoother, 16-bit graphics and real-time lighting effects.
Wicked Multiplayer Capabilities : Up to 32 players, friends or foes, can go at it in a bloodydeathmatch via LAN and over the Internet.
Well hi there,That settles the music poll :).
Heres the scoop:
There will be 15 tracks..there will be ambience stuff (some)...and music is always a matter of taste..it will rule..;)
August 25, 1997Irc.Quake2.com!
The latest issue of BOOT has an article called "Carmackageddon" that makes the Unreal guys look like a bunch of frustrated high schoolers. Really guys, can you shove your collective feet ANY further down your collective mouths?!
Go check it out -- it's pretty funny the shit they talk for never having shipped a 3D product. They note how Quake is "dated", yet not a single other full 3D environment shooter has shipped since Quake. Unreal has been under development, according to that article, for 3.5 years -- since before Quake. Yet they haven't shipped.
If these guys were so damn studly and original, they'd be doing something other than trying to one-up the God of First Person Shooters. I mean, they're welcome to try, but I just want to save them some embarrassment...
Number of times Epic mentions Quake in their interview: 21
Some choice quotes:
Schmalz: "...a lot of people say their games have amazing AI, but we have the proof to back it up".
Um, so where can I buy this proof?
Schmalz: "I expect Quake 2 to be pretty impressive...when it comes out."
The ellipses were his, not mine. I KNOW you aren't trying to say we have a problem shipping on time....
Schmalz: "We've been creating content for the latest technologies. A lot of the other games coming out in the next little while are bland; the content is obviously affected by the older technologies."
If you quit worrying about the latest technologies maybe you'd ship a game before id ships TWO.
Interviewer: "What kind of unique weapons are there in Unreal?"
Schmalz: "There's one weapon we call the 'Stunner'. It's like a charge-based thing; you press it down and it charges up and blases the guy."
Gee, kinda like the plasma cannon from Descent? I thought he asked for "unique."
Sweeney: "Unreal is designed to be a game engine rather than a specific game." "The engine itself is based on a little programming language I set up called Unreal Script." "When you see people buying Unreal three years from now, it won't be because we made it such a great game initially, it will be because the game was expandable enough that the community developed around it and was able to do cool stuff with it."
Gee, kinda like....
"Unreal(ized), the RC Cola of First Person Shooters"
August 24, 1997 (early AM)
This is a HUGE plan update, so fair warning...
...ON THE MIRACLE OF SETENV AND MAKING QUAKE2 INTO AN OS:
I told John about my "putenv" gamma hack for 3Dfx, and he thought it was pretty cool, but in typical Carmack fashion he improved on it by simply suggesting the (obvious to anyone smarter than carrot, that set of people not including me unfortunately) addition of a new command called, ta-da, "setenv".
This would work much like the Unix "setenv" command and all it does is simply set the given environment variable to some value for the life of the program. Easy enough. For 3Dfx you could change your gamma, swap interval, dual head, and whatever other configuration stuff you want very easily.
]/setenv SST_GAMMA 1.3
Woo-hoo! Way more general than just doing a new command called "gl_gamma" or "3dfx_gamma" or something.
There have been requests from people to pretty much make Quake2 into a full-fledged operating system. I have friends at 3Dfx and SGI that basically do this with Emacs, but they're freaks.
Now, believe it or not, it would be reasonably trivial for us to make Quake2's console into a complete shell. It would probably take less than an hour to do basic stuff like spawning commands:
Then we could add "ls", "cd", "cp", command line completion, and...
Oh God, the horror, the horror....
Okay, I digress. Point being it's possible, but it's also a slippery slope once you start doing stuff like this. Security issues, robustness issues, portability issues, whatever. Not cool, and we're not going there.
...ON OUR NEW GRAPHICS ARCHITECTURE
Anyway, we've decided to ditch MGL, at least in terms of our all-in-one super-ultra-graphics-lib. There's nothing wrong with MGL, but we're simply more comfortable controlling all of our own code than we are outsourcing part of it.
The MGL (http://www.scitechsoft.com) is an abstraction library that literally does EVERYTHING. It will render graphics for you to GDI, to VESA 2.0 modes via WinDirect, to DDRAW surfaces, to OpenGL systems based on MESA, SGI, or Microsoft OpenGL. It does a LOT of stuff, and for many game developers it's the right choice. Hell, id used it for WinQuake.
But lately we've been trying to re-stress portability -- I realized earlier tonight that a lot of my code was becoming alarmingly Win32-centric, and pulling all that the Win32isms out was what I did tonight. Now porting to another platform should only take a day or so, and that's something we'd like to test in the near future (e.g. porting to IRIX on our O2).
And when you use someone else's graphics library, you've lost portability, or at least it's out of your immediate control.
So that's one issue. Other issues include the fact that MGL was a very complex library that did a lot of things that we didn't need to use, but which we had to work with anyway. This extra complexity for features unnecessary to us was proving to be cumbersome. Also, we ended up having to link MGL directly into our QUAKE2.EXE instead of into the rendering DLLs, and that gave both John and I a pretty uneasy feeling. If Rendition wanted to do a Verite rendering DLL, then it would have become a serious issue very quickly.
Finally, this comes back around to my "NIH is good" philosophy that makes software engineering professors cringe in pain. NIH, for those of you just now joining us, is the "not-invented-here" syndrome that lots of companies and computer scientists bitch about. It's where you arbitrarily refuse to use someone else's code simply because you didn't write it. It's a mixture of arrogance and an unwillingness to trust someone else to do a good job coding.
THAT kind of NIH probably is bad. Doing anything arbitrarily and out of dogma is generally a bad thing. But THAT kind of NIH is not what we're doing here.
Our NIH is based on experience and pragmatism. When your projects are small enough (and it makes me shudder to think that Quake2, in the grand scheme of things, is considered pretty small), it just makes complete and utter sense to do as much as you can internally and only outsource stuff when you absolutely have no alternative.
It's bad enough we have to use other people's compilers (MSVC), debuggers (MSVC, NuMega BoundsChecker), libraries (C-RTL, OpenGL), and operating system services (DDRAW, GDI), so going out and looking for yet more third party stuff to toss into our code is just not that appealing. The more you control, the better you can address any issues that come up such as bugs, portability, usability, whatever.
The time for Software ICs has not arrived. And it never will so long as we use programming languages consisting of ANSI C plus lots and lots of duct tape (I'm talking about C++). In the old days the argument against using prepackaged libraries was usually along the lines of performance, but that's not the issue anymore. Anything you'd use a library for had better not be performance critical, or if it is, the provider of that library had better have a vested stake in seeing it achieve maximum performance (OpenGL is a perfect example of this). In the Good Old Days you'd do all kinds of weird special case optimizations in order to milk the last drop of performance out of your program, and a general purpose library simply didn't guarantee that kind of performance.
Today, the issue with prepackaged libraries, as we've found out, is being able to control your code to a very fine grain -- your library interface, the code quality, the feature set, whatever. Performance was NEVER a factor when we were debating whether to use MGL or not.
Anyway, that's the NIH and MGL situation in a nutshell.
Now, there's more....
The way we're addressing graphics now is to use standardized video modes instead of arbitrary video mode widths and heights. Our supported modes will be:
The same set of modes will exist in the GL refresh as in the software refresh, however they will use different variables ("gl_mode" and "sw_mode" respectively). This will allow you, for example, to always use 320x200 for software rendering and 640x480 for OpenGL rendering.
So we have our list of standardized video modes. Now we have to deal with how we're going to get graphics on the screen, and it actually breaks down pretty simply:
- for software rendering into a desktop window, we're going to use GDI's CreateDIBSection and do a BitBlt. In 8-bit modes this should be fast since we'll put the desktop into an identity palette mode. In >8-bit modes this will probably be slow, unless hardware accelerates the DIB blit to the desktop, which I doubt will happen.
- for software rendering with fullscreen support we're going to use DirectDraw. Our code should be compatible with anything from DX3 on up, so we may not need to install DX5 on people's system, but that's something that we're going to have to decide. I'm a little leery of mucking about with end users' operating systems -- something that any game company that did an install of DX2 or DX3 on users' systems can attest to -- but if this gives us strong 320x200 fullscreen support, we may go that route. A lot of thinking has to be done with regards to that though.
- for OpenGL rendering to a window, we're going to just OpenGL and GDI, i.e. "normal OpenGL programming". Nothing fancy, nothing weird, should just work with just about anybody.
- for OpenGL rendering in fullscreen modes we're going to use regular OpenGL and rely on ChangeDisplaySettings to do the right thing. This is an iffy proposition, since CDS isn't exactly happy-happy on Win95. On WinNT 4 it's a little better, but some IHV's drivers, notably 3DLabs, really really have emotional problems with CDS. We're working with them on this though.
ChangeDisplaySettings is notoriously flaky, so we're still unsure how well this is going to work out in the end, but right now I'm trying to be optimistic about things. One thing about it is that it won't let you change color depth under Win95 without rebooting (I think OSR2 fixes this to some degree, but I'm not counting on everyone having OSR2 installed). So this means that fullscreen OpenGL sessions will run at the same
This is going to suck in a few instances. If you normally run a non-16-bit desktop, you're going to have to change your display properties and reboot before running Quake2 with OpenGL hardware acceleration. This will be true for RIVA128, V2200, Rage Pro, and all other 2D/3D boards. The Voodoo could give a shit -- it'll just magically work.
On NT4 we MIGHT consider putting in some kind of optional override that will allow you to change your desktop depth without rebooting, but like I said, CDS is pretty flaky, and we're reluctant to rely on it doing the right thing when we need it to. Maybe something like a "+set gl_trust_CDS 1". I dunno, gotta think about that one for a while.
Oh, in case this hasn't been mentioned, we have not intention of supporting WinNT 3.51 or Win 3.x. The former doesn't have decent OGL drivers, nor does it have a proper ChangeDisplaySettings. The later doesn't have full Win32.
Anyway, that's that in a nutshell. We own all the code that is part of Quake2, and our new graphics architecture is coming along. We have the GDI stuff and OpenGL stuff working, so all that's left is cleanup, debugging, and getting DirectDraw to do what we want it to. After that the video driver rendering harness will be complete, and then all we have to worry about is, like, the rest of the game...
...ON 3D ACCELERATORS
Saw that RIVA128 boards are going for about $190 w/ 4MB. Rendition V2200 boards are supposed to be going for $199 w/ 4MB and $249 w/ 8MB. The fact that they can do 8MB is just abso-fucking-lutely cool. If only we actually had one here we could test....
With Permedia2 boards going for $199 w/ 8MB, and V2200 boards going for $249 w/ 8MB, NVidia's primary flaw is showing through pretty badly. 4MB is NOT that much RAM for an accelerator, not when you're trying to do 3D on a desktop.
I still don't know what's up with the RAGE PRO, ATI doesn't return my e-mails.
August 22, 1997 (cont.)
If I haven't said anything about a particular chipset or board it's because either A.) I can't because of NDA issues or B.) I don't have an opinion yet.
This is a roundabout way of asking folks not to send me e-mail asking for my opinion on the Rendition, TriTech, ATI, etc. parts.
August 24, 1997Get the point?
Quake 2 Stuff
First pass archictecture is done for all my levels. Now it's add the monsters and tweak the textures and wait to see how the next round of BSP changes afffect things I already know I have to chop stuff out of several of them).
One of the news items on Tin's Quake2 Nutshell pointed me to a website that was putting up reader contributions. The subject: The plot for Quake 2. I read through 'em and it quickly became obvious that either A) our message about what Quake 2 was about wasn't getting through, or B) nearly everyone who contributed was a tad short in their clue inventory. I put together this little piece to honor the occasion:
Your ears ring from the force of impact ... or is that echoing rocket fire? Your vision only just now begins to clear. Around you, the shattered remnants of your single man drop pod lay scattered. With your hide safe on the planet surface, their work is done. Your eyes focus and adjust to the light of an alien sun. Anxiously you search the grim, metallic ruins around you in shock and dismay. It's different, not what you had imagined at all. Where are the occult references, the satanic symbols, the mish-mosh of medieval fantasy and modern military surfaces? Dammit! Where are the rock band references?!!
And suddenly it dawns on you. You finally understand what everyone has been trying to tell you for months.
This ain't just another Quake mission.
It's Quake 2! And it ain't no sequel.
COMING SOON TO A PENTIUM COMPUTER NEAR YOU
Copyright 1997. id software, inc.
Before you freak out too much maybe I should let you in on the joke. American McGee really did come to my dad's music studio. My dad is Gorebag. And while he was here American decided to play a joke on his friends back at id software by fulfilling their worst nightmares. That's what these sound bites are... Their Worst Nightmares.... totally stupid sound bites.It's ok.. I'm guessing anyone who went and listened thought it wasn't for real anyways.
I can't put the real sound bites on the web. You will have to wait until Quake II comes out. By the way I wasn't fooling about me and my brothers getting to play Quake II. He Fed Ex-ed a computer out here and we really got to play. It is going to be so totally kewl I can't wait for Christmas to come.
I am looking for interested parties to join up in a exciting TC in the works for Quake 2. Have you ever seen the mini-series/tv-series "V"? well, its just crying out to be made into a TC. I had planned on making it into a Quake TC, but, that damn real life thing took over.Modelling contest
So, if your a mapper, modler, texture artist, sound p1mp, or a webgod, please email me at: firstname.lastname@example.org, and let me know that your interested, and what your talent is, and we can arrange for you to send some examples of your work.
August 22, 1997PC Gamer shots update
From the inside jacket of White Zombie's "Astro-Creep:2000":
"The point is: we obtain parametric equations by setting one of the coordinates equal to a function of a parameter, substituting for this coordinate in the given rectangular equation, and solving for the other coordinate in terms of the parameter."
And people wonder why I think White Zombie kicks ass.
August 22, 1997 (early AM)
Okay, today is the big .plan update dealing with 3D accelerators. It's not quite as complete as I'd like, since we're still missing the Rendition V2200 and ATI Rage Pro, but for now it's still good information.
These numbers were acquired using GLQuake 0.93, by typing at the start level "TIMEDEMO DEMO1; TOGGLECONSOLE". Tests were run on a P5/200MMX machine with 32MB of RAM with a real Intel motherboard running Win95 OSR2 and WinNT 4 SP3.
The PowerVR numbers were acquired under Win95 (since PowerVR only works under Win95 right now), and the RIVA128, Voodoo, and Permedia2 numbers were gathered under WinNT (RIVA128 only supports OpenGL under NT, and Permedia drivers are far more stable under NT than Win95). The resolution was 640x480 with flashblend enabled. With Permedia we used the "-lm_4" parameter which uses four component alpha-only lightmaps to get around deficiencies in their hardware.
3Dfx Voodoo, 16bpp, GL_ZTRICK=1, no-sync mini-driver 31.8fps
3Dfx Voodoo, 16bpp, GL_ZTRICK=0, no-sync mini-driver 30.1fps
3Dfx Voodoo, 16bpp, GL_ZTRICK=1, sync mini-driver 26.1fps
3Dfx Voodoo, 16bpp, GL_ZTRICK=0, sync mini-driver 24.3fps
RIVA128, 16bpp, GL_ZTRICK=0 OpenGL MCD 23.8fps
RIVA128, 16bpp, GL_ZTRICK=1 OpenGL MCD 23.8fps
PowerVR PCX2, 16bpp, GL_ZTRICK=0 mini-driver 23.0fps
Permedia2, 16bpp, GL_ZTRICK=1 OpenGL ICD 18.4fps
Permedia2, 16bpp, GL_ZTRICK=0 OpenGL ICD 18.3fps
Okay, some comments:
- it looks like the OpenGL MCD is a pretty bad performance drain for various reasons I haven't quite narrowed down. If/when NVidia do an ICD, their perrformance should go up quite a bit.
- currently only Voodoo gives us the option of disabling syncing to vertical retrace. As you can tell, it can make a pretty significant difference. In the future triple buffering may make this issue go away to a large degree.
- we expect to see more performance improvements from the PowerVR, however we only saw a 10% performance jump in performance when we tested on a P2/266, which indicates we may be approaching the limits of their current hardware.
- the RIVA looked pretty damn good. The primary deficiencies with the part are that it can only go to 4MB and that it doesn't have an OpenGL driver under Win95. Hopefully the latter will be taken care of in the upcoming months, and the former will be taken care of by their next generation part.
Right now it's pretty obvious that for pure playability (single player) it's close to a toss up between PCX2, RIVA128, and Voodoo, with the Voodoo currently just barely edging out the other two ON THE P5/200MMX. This is VERY important -- these numbers do not necessarily correlate to the same relative performance on slower or faster machines, and I'm actually reasonably certain that the RIVA128 is faster with GLQUAKE on a P2/266, but formal testing on our P2/266 hasn't been done yet. In another week or so I'll rerun the tests, hopefully with some new boards tossed into the mix.
One thing most people have found out is that the performance characteristics you see in single player vs. deathmatch are radically different. For this reason we're making at least one performance and compatibility testing map that will have individual rooms each testing the performance of a specific feature, e.g. particles, transparency, fill rate, triangle setup, etc. As many of you have found out, things like particle performance and texture download speed are really important in deathmatch and almost irrelevant in single player mode.
The individual numbers by themselves won't really help determine how good a card is, but it can let driver writers figure out where their bottlenecks are residing.
Also, along with some standard demos a la TIMEDEMO, I'm going to try and push for a multiplayer deathmatch demo that will have lots of explosions, particles, and all other kinds of wacky shit going on to act as a real stress test.
It's entirely possible that a board that's good for single player could suck for death match. For example, if board A has less fill rate than board B, but much faster texture downloads and particle rendering it could actually give much more consistent performance with deathmatch play.
Hi John,Brian Hook .plan update
I am writing this, since there seems to be a lot of confusion about the reasons for the performance-gaps that can be found when swapping an INTEL Pentium for an AMD-K6.
What I am really after is a statement about the reasons for this behavior. Some people state it is plainly the poor FPU-performance, others doubt it and state its really the pure Pentium/PentiumPro optimization of the engine that causes these gaps.
The general opinion is that the K6 does not even reach a P54 when it comes to FPU ops (I personally share this point of view), however different benchmarks yield different results, and obviously it depends on whether FPU ops are 'pipelined' or not (did I get this right?).
If this claim is correct, will your upcoming Quake2-Engine be more 'K6-friendly', than the current one?
Non-pipelined floating point processors can only have a single floating point operation working at a time. The pentium can have three or four if you structure your code correctly.
If you can interleave integer instructions between all the floating point, amd and cyrix can perform well. Unfortunately, there usually aren't any integer operations to do when you are doing a lot of floating point.
Quake 2 will behave similar to quake 1.
Someone sent me e-mail asking me if we plan on supporting gamme correction in Quake2. This would be nice, unfortunately Microsoft and/or the folks that write drivers for GDI/Win32 have decided that implementing two key Win32 driver functions (Get/SetDeviceGammaRamp) isn't that important. Microsoft makes it an "optional" API to implement, and even incorrectly documents it between their SDK and DDK.Quake 2 Central
This would ideally give us some degree of gamma control
For Quake2 I intend to support changing gamma on the fly for 3Dfx. It's going to be a pretty ugly hack and not the sort of thing that you'll want to mess with often. Basically, with 3Dfx Voodoo you can't use the Win32 APIs for controlling gamma because it's not a Win32 accelerated device (it's a secondary graphics device). For this reason we'd have to access it directly, either through an OpenGL extension or through Glide or through something else.
I chose something else.
Since we have the capability of reinitializing the graphics subsystem from scratch we can actually set the 3Dfx global gamma environment variable, SST_GAMMA, to our desired value then restart OpenGL subsystem so that the change "catches". It's not the most elegant solution, basically coming down to the following:
sprintf( buffer, "SST_GAMMA=%f", gl_gamma->value );
putenv( buffer );
Pretty gross, but it works.
Now, for other systems this shouldn't be a huge issue -- global brightness is the kind of thing you'd probably like to control from your standard control panel display applet. All the other accelerators out there will do this, e.g. RIVA 128, PowerVR (through its "host" graphics adapter), ATI Rage Pro, etc.
There are actually two issues to deal with when it comes to gamma. The first is gamma correction to control scene brightness. This is what I'm talking about today. The second issue is using gamma correction for special effects such as screen flashes. This will likely be addressed in a future OpenGL extension for games that will allow different hardware vendors to implement screen flashes in the form most effective for their architectures. I'll talk more about this at a later date.
I plan on doing an update in the next couple of days outlining the performance differences we're seeing between RIVA 128, Voodoo, Permedia 2, and whatever else we may have lying around. I can tell you this right now -- the RIVA isn't a Voodoo killer, but it's REAL damn competitive across the board. NVidia did a rocking job with that chip. Unfortunately, the first few boards are only shipping with WinNT MCDs for OpenGL, so those of you running Win95 are shit outta luck until NVidia releases a Win95 OpenGL driver (and I'm doing everything I can to convince them to do this).
Chris, quit reading this crap.
8/20/97It's an exciting world :).
Hey. My name is Paul. Me am an artist at id. Me make art real good. Oops! I'm sorry, guess I was trying a little too hard there to fit in. Basically, the game is going great. It's on time and on line with everything we want to do with it. I've got the male and female player characters to finish up, one base monster and three of the bosses left. Cinematics are coming along. Weapons are done and from what I've seen of some screenshots being posted lately, some of our competition might possibly be influenced by our stuff. That's cool. Some people have claimed that I was influenced by Turok (keep meaning to play it), but that's a compliment since the guys at Iguana are very, very talented. Fortunately as Brian Hook posted in his plan recently, we don't hide what we're doing behind secrecy. We'll tell you or show you anything we're doing because we encourage competitors to give us some...well 'competition'. Do something better than us and we'll just have that much more incentive to up it a notch. Sorry I digress into the realm of ego. Very soon though we'll give the other guys something concrete to strive for. Ain't it exciting?
One thing I been missing is a color-indicator for the msgs...when I go onto a CTF-server I can't possibly know the names for all members in my team (I usually go from server to server), so whenever somebody msg "get our flag back" or "back to base", I don't know if it's my team or not...a little color indicator right next to the msg would help a lot there.Zoid's response to this was:
Interesting idea. Quake2 doesn't have color mapping. It only has skins. But a RED or BLUE team indicator could be interesting.And, when I asked him how soon after Quake 2's release a Linux port to run a Quake 2 server on most web servers, he had this to say:
To be decided. John and I are both very hip on a Linux version, tho.PC Gamer shot of day
Aug 18Excuse me while I party :). I don't know if I like the idea of cleaning it up, but remembering the Wolf source... it'll have to be cleaned up or it won't work for us. I'm ecstatic beyond words right now.
I get asked about the DOOM source code every once in a while, so here is a full status update:
The Wolfenstein code wasn't much of a service to release -- it was 16 bit dos code, and there wasn't much you could do with it. Hell, I don't think it even compiled as released.
The DOOM code should be a lot more interesting. It is better written, 32 bit, and portable. There are several interesting projects that immediately present themselves for working with the code. GLDOOM and a packet server based internet DOOM spring to mind. Even a client/server based DOOM server wouldn't be too hard to do.
I originally intended to just dump the code on the net quite some time ago, but Bernd Kreimeier offered to write a book to explain the way the game works. There have been a ton of issues holding it up, but that is still the plan. If things aren't worked out by the end of the year, I will just release things in a raw form, though.
My best case situation would be to release code that cleanly builds for win32 and linux. Bernd is doing some cleanup on the code, and some of the Ritual guys may lend a hand.
One of the big issues is that we used someone else's sound code in dos DOOM (ohmygod was that a big mistake!), so we can't just release the full code directory. We will probably build something off of the quake sound code for the release.
I think I am going to be able to get away with just making all the code public domain. No license, no copyleft, nothing. If you apreciate it, try to get a pirate or two to buy some of our stuff legit...
Er, I guess it's been a long time since I updated. I'm still alive and mostly dealing with the Hell of Integrating Code From People Not From Id. Irk. I'm also back to optimizing stuff. We did a new merge today that cleaned up quite a few things, something we're pretty happy about. Things are steadily coming together. I went ahead and switched to single precision divides for the Alias triangle setup routine and for the particle setup routine, giving us 10% better performance in the latter case.His second .plan update from the 16th was an open letter to Shiny, who are making the game Messiah and debating patenting their ways of doing stuff (which I personally don't think is a good idea):
Open Letter to Dave Perry of Shiny:He updated today also, as an added note regarding patenting software technology. Here it is quoted:
Dude, if you're seriously thinking about patenting the techniques you're doing in Messiah, GET OVER YOURSELF. Software patents are amazingly uncool, and generally indicate A.) an insecurity that your competition may be as smart as you, and B.) that you don't have the balls, the brains, or the dedication to compete by creating a product that is simply better than everyone else's.
id software tells everyone and anyone how we do things here. We don't care. More people have source code to GLQuake than I can keep track of. We share information because:
A.) spreading knowledge is a Good Thing
B.) we're not so insecure that we have to hold onto every tiny little morsel of information we come up with.
We can tell everyone what we're doing, how we're doing it, and why we're doing it because WE KNOW WE'RE BAD MOTHERFUCKERS. We're not going to bitch slap our competition because we have good PATENT FUCKING ATTORNEYS. We're gonna spank our competitors like they're little babies because we've got some of the best level designers, artists, modelers, biz dudes, and programmers this industry has to offer, and we're confident that TALENT AND DEDICATION are what it takes to kick the shit out of everyone else in the marketplace. Not some weak ass artificial legal barrier to competition.
So if you're really thinking about filing for a patent, ask yourself "Why am I doing this?" If it's for any reason that isn't lame, go ahead. But I'm pretty certain any reason you can come up with basically comes back to a fear that you won't be able to compete with the Big Boys without artificially introducing barriers to competition. If what you're doing is so damn studly that no one else could figure out, how about NOT patenting it and just shutting your damn mouth. That's what we like to call a "trade secret", which I have NO problem with.
You ain't that smart. You ain't that bad. You ain't All That. Right about the time you need lawyers to give yourself a competitive edge is about the time you shouldn't be writing games anymore.
PS Same goes to the punk losers at Novalogic.
From the latest PC Magazine:One intelligent Microsoft guy (<joke>Rare, aint they?</joke>) speaks out, I guess. I should be up to date on the important .plan-age right now. BTW, anyone who felt that the Microsoft joke up above was too low-brow, I apologize in advance.
"My personal position is that we'd be better-off without software patents. Thousands of software patents out there are probably bogus, but it's tough to know what to do about that. For now it behooves us to keep filing patents. On the hardware side it's easy for large organizations to cross-license with each other, but that doesn't work in software, because so many patents are held by individuals and you can't really cross-license on a small scale. We've paid hundreds of millions of dollars on claims that, in my opinion, are bogus."
- Nathan Myhrvold, Microsoft Corporation