5. Hexen 2 (5%)Obviously Quake2 won, who would be suprised. What would expect to be ultimately better than Quake, some other game, or it's sequal? Come on people, this is common knowledge. Oh well, these little polls are still damn fun! To me having Quake2 is just like having a new CD, I still listen to the old ones. Just because I have the newest Rage Against the Machine CD doesn't mean I won't listen to the old one. Ok, enough blabbing and plugging my favorite band for tonight.
4. Unreal (8%)
3. Jedi Knight
2. Duke Nukem Fourever (16%)
1. Quake 2 (38%)
September 2, 1997After that .plan update, he made this one later that day (this one's actually short :) ):
-----------------
While I'm waiting for all my source to rebuild, I thought I'd do another small update.
OTHER HARDWARE ACCELERATORS
- Number Nine Ticket To Ride Imagine 128
We don't have one, #9 doesn't return our e-mails, and from what we've heard it's nothing to get excited about. If I get one and test it, I'll let you know.
- Matrox Mystique, Millenium, and Millenium 2
Um, no.
- S3 Virge
Um, no.
- TriTech Pyramid3D
I can't comment on their hardware, however I can say that our attitude towards the Pyramid3D is one of apathy. We have a board with drivers, and we have chosen not to concentrate time supporting or testing with their board at this time. Draw your own conclusions.
- Oak
If they get us an OpenGL driver and board, we're willing to go with it.
PORTS
Several people asked about a BeOS port, and I wasn't going to worry too much about it. However today I got a message from someone at Be asking us if we were interested in a port, and John and I discussed this and decided it was something interesting.
While Be itself doesn't knock us dead technically, the fact that it supports OpenGL is a pretty big plus, so we're willing to support them. Just so there's no suspense, here are our list of implementations and their relative priorities:
- Win32 x86
Duh. This is what we're working on full-time.
- Win32 AXP
We've reached a good waypoint with the DEC Alpha port, and probably won't worry about it until Q2TEST's release is imminent. I'm responsible for this.
- Rhapsody
John is handling this one and doing it whenever he finds the time. It's about the same priority as the Win32 AXP port -- they're both important for different reasons. Rhapsody demonstrates our portability to a radically different OS; Win32 AXP demonstrates our portability to non-Intel CPUs.
- SGI
This will likely be the result of a collaboration between SGI and id, and will probably involve having an SGI engineer on-site for a week or so to get things up and running. This is important to us because SGI is the premiere OpenGL platform, and it's just damn cool to know that out there are SGI Onyx2 InfiniteReality platforms that are running GLQuake. We want the same thing for Quake2.
- Linux x86
Zoid is handling this, and this is his biggest porting priority. We have lots of Linux fans and we want to support them, and Linux also has a pretty solid OpenGL presence.
- BeOS
We'd like to see BeOS supported after Zoid gets done with the Linux x86 port, since BeOS is yet another radically different OS and also runs on multiple CPUs (PPC and x86). Also, BeOS supports OpenGL, and we give preference to platforms with good OpenGL support.
- Linux (other)
Just as an existence proof Zoid is going to port Quake2 to all the other Linux implementations out there and see how well that works.
- Unix (other)
HP, IBM, etc. are probably going to contact us or Zoid about Unix ports in the future, and we're not opposed to these, but we're not allocating time for them until they become an issue.
- OS/2
Only if IBM does all the work.
- misc others
Other ports are "to be determined". I can say right now that there is NO WAY we're going to do a DOS version! An Amiga version is probably out of the question (before you flood me with e-mails, I LIKE the Amiga), as are Atari ST versions and other oddball legacy computers.
September 2, 1997 (part 2)He updated today again, twice. Below is the first update he made today.
-----------------
Okay, I normally don't just go off and say "hey, buy this product", since we're not in the business of product endorsement, but there is one product in particular that has been SO good that I have to recommend to anyone doing Win32 development of any type: BoundsChecker. BoundsChecker by NuMega software (http://www.numega.com) is a debugging tool that tells you when you're dangling pointers, not freeing memory, trashing memory, reading uninitialized memory, passing incorrect args to Win32 API functions, etc. etc. It is AMAZINGLY useful, and has found at least three really really ugly bugs for us in the past couple of weeks. Some of these bugs have been so insidiously subtle that it would have taken a VERY long time to hunt them down.
BoundsChecker: buy it, use it, love it.
Anyone who sees that cheezy VRGQuake floating around -- uh, I know nothing about it. Don't ask me about it, it's not one of our products, and I wouldn't touch it with a ten foot pole.
September 3, 1997 (early AM)And finally, here's his most recent .plan update:
-----------------
Can you believe that with all these plan updates I still manage to get a normal day's work done? We did a merge, I fixed some bugs, I spent hours working on e-mail and talking on the phone about OpenGL extension issues, and started implementing some new tweaks in the GL code. Today was mostly a non-coding day, but I still got a lot done and learned a lot of interesting stuff. Tomorrow I should get a ton of real coding done.
NOTE: The RIVA128 cracking problems are NOT the same as what you see on 3Dfx. The problems with 3Dfx are not 3Dfx problems at all, they're Quake problems, specifically T-junction issues. The cracks we're seeing on RIVA are BIG GAPING GNARLY CRACKS BETWEEN POLYGONS. These problems do NOT manifest themselves on other graphics adapters.
Oh, saw natasha.stomped.com -- mother of God, people like that EXIST?
Damn, things with hardware just keep getting better and better. Rendition has sent me a new set of drivers that GREATLY increased their performance. Not only that, but according to them their driver also syncs to vertical retrace, which means that both the RIVA128 and V2200 sync to vertical retrace, thus making comparisons to 3Dfx's no-sync numbers not particularly meaningful anymore. Note that I remove "old driver" scores after another table reprint, so the old PCX2 numbers have been ditched.
The new table is:
Chipset P5/200MMX(32MB) P2/266(128MB)
3Dfx Voodoo, GL_ZTRICK=1, nosync 33.8 33.9
3Dfx Voodoo, GL_ZTRICK=0, nosync 30.2 30.3
NEC PowerVR PCX2, nosync 29.1 31.3
3Dfx Voodoo, GL_ZTRICK=1 27.2 27.3
Rendition V2200, GL_ZTRICK=1 26.3 27.0
3Dfx Voodoo, GL_ZTRICK=0 24.4 (forgot to run test)
NVidia RIVA128, GL_ZTRICK=1 24.0 32.2
NVidia RIVA128, GL_ZTRICK=0 23.9 32.1
NVidia RIVA128, GL_ZTRICK=1, 800x600 (didn't bother) 25.7
Rendition V2200, GL_ZTRICK=1 (old dvrs) 19.0 19.4
Rendition V2200, GL_ZTRICK=0 (old dvrs) 18.8 19.2
3DLabs Permedia2, GL_ZTRICK=1 18.6 19.2
3DLabs Permedia2, GL_ZTRICK=0 18.6 19.2
WinQuake (software only) 13.5 12.6
Commentary:
Rendition is the most full featured of all the boards, including possessing the ability to address up to 16MB of RAM. Their MCD looks pretty good, and it even ran the Quake level editor! There was some confusion on our part since we thought we had an 8MB board, and it turns out we only have a 4MB board.
The basic conclusion is that you won't be going wrong with the V2200, Voodoo, or RIVA128 (assuming the latter fixes the cracking-between-polygons problem we've seen -- if that isn't fixed, we simply can't recommend it to anyone since that really takes away from any game experience). As we become more sophisticated with what we're doing with geometry and textures our tolerance for sloppy rasterization rules diminishes greatly.
Right now we're extremely excited about Rendition's new hardware, and we can't wait to see what they do with a Win95 OpenGL driver. And both RIVA128 and V2200 have lots of room for performance improvements when they go to a full ICD driver model. And the RIVA is posting phenomenal numbers on a P2/266, even at 800x600.
The RIVA is CPU limited, and their performance will depend largely on the speed of the system CPU. The PCX2 and Voodoo are fill limited, and thus the choice of CPU (beyond a certain point) is largely irrelevant. The V2200 is, well, driver-limited -- their drivers effectively replace the microcode in their hardware, so they're sort of hardware limited, but their hardware limits can be removed by better drivers. I think the V2200 might get a bit faster with newer driver updates.
The PowerVR is still a good bargain, but we can't say it's the best, even with its impressive numbers, because they aren't syncing and there are visible artifacts as a result -- when we get a driver with triple-buffering enabled, then the situation with hardware may change radically yet again.
An important thing to keep in mind is that 3Dfx is still the safe bet -- good performance and Voodoo works on Win95 and WinNT. Unless you're running NT, the V2200 and RIVA128 numbers are largely irrelevant. And unless you're running Win95, the PCX2 numbers are largely irrelevant. And you lose colored lighting on PCX2 (but for the price...yowza!).
The Permedia2, while showing some pretty lackluster numbers right now, promises to get much faster after we implement support for paletted textures. Assuming that they support the new paletted texture extensions that SGI and other PC IHVs will be proposing soon. You still don't get colored lighting on the Permedia.
All in all, the next couple of months are going to make the world of 3D hardware accelerated games much more interesting.
Of course, I'll be mighty surprised if 3Dfx doesn't up the ante once again very soon.
September 3, 1997 (early AM part 2)Scarecrow's Quake 2 buttons - Slipgate
-----------------
The fun never stops!
As it turns out, according to someone at 3Dfx, Diamond Monster3D boards are run at 57MHz by default if you use their install tools. Since Diamond M3D boards account for the vast majority of 3Dfx boards, I allowed this one example of upclocking into the tests by doing a SET SST_GRXCLK=57 to see the effect on performance. In theory, performance should go up by about 14%, and in practice it went up by around 10%. Not bad. This does put yet another new spin on things.
Damn, where were these driver updates a week ago?
I've now removed the 3Dfx no-sync numbers, since everyone else is syncing to vertical retrace and there's no easy of disabling it on other hardware to get a feel for true performance. I've removed the GL_ZTRICK=0 numbers in order to make things clearer -- the only one that it was affect performance on was 3Dfx, and by and large people don't set GL_ZTRICK to 0 anyway.
We may have Quake2 benchmark numbers by next week.
So the NEW table follows. In the new compressed format, it simply shows that there is no clear winner, and that each board has its own merits. My previous summaries are still true, but in this format it's easy to see that RIVA128 is the best on a P2/266, 3Dfx is the best overall, and that Rendition V2200 is the best overall if you need 2D/3D. So none of those three outright suck, and they each have their strengths.
And I'm giddy about this. Man, the RIVA128 is so CPU limited that it runs faster at 800x600 on a P2/266 than at 640x480 on a P5/200. That's just weird.
Chipset P5/200MMX(32MB) P2/266(128MB)
3Dfx Voodoo, 57Mhz 30.0* 30.0
NEC PowerVR PCX2 29.1# 31.3#
3Dfx Voodoo, 50MHz 27.2 27.3
Rendition V2200 26.3 27.0
NVidia RIVA128 24.0 32.2*
NVidia RIVA128 @ 800x600 (didn't bother) 25.7
3DLabs Permedia2 18.6 19.2
WinQuake (software only) 13.5 12.6
* denotes fastest on that CPU
# denotes no syncing to retrace, so it's going to be ugly
>I know you're busy, so I'll make it quick:
>1) Will your radiosity lighting take into account reflection colors?
>IE would a white wall next to a red floor would cause the wall to be
>tinged red near the bottom?
Yes, it does do that, but it is a pretty subtle effect. You can tell if you shine really bright lights onto very color saturated surfaces near white floors, though.
>2) Your plan mentions dynamic lights can be colored and even
>negative...can they be both? (Negative red lights?)
Yes, but the calmping at 0 makes it a little weird.
John Carmack
September 1, 1997 (part 2)Here's a .plan update he did today, where, although reluctantly, he gives his suggestions on what card to buy (in different suggestions):
-----------------
Okay, yet another quick addendum to the performance figures.
1. As some of you noticed, the RIVA 128's performance scaled up quite a bit better from the P5/200 to the P2/266. This is pretty remarkable, actually, and we're not sure why. It's pretty obvious that the RIVA 128 is not fill limited, however this "scalability" actually indicates to me a very poorly optimized driver. So I guess this is good news in a way -- if they optimize their drivers more then they should get much faster even on the slower CPU.
2. Since it was apparent that the RIVA128 wasn't fill limited, I ran the benchmark at 800x600 to see what I could get, and what I got was pretty damn impressive: 25.7fps. I've updated the August 31 table to reflect this.
3. I was running outdated PowerVR drivers, and not only that, I was running them in "compatibility" mode. When I updated the drivers the performance went WAY up. I've updated the table also, but these new drivers put things in a whole new light. Unfortunately the new PowerVR drivers do front buffer rendering, so there's very visible tearing. I've been told that they'll be doing triple buffering fairly soon, which should give them the same performance we're seeing now but without the flashing/tearing artifacts we're seeing.
As you'll see with the new table, tweaking your drivers can really make a difference if you're not hardware limited. Right now I believe that we're seeing the maximum performance possible from Voodoo and PCX2 -- tests with the latter bear this out, as we tried going to 800x600 and performance dropped proportionally. The RIVA128 has a LOT of room for improvement.
Have I mentioned I'm still impressed as hell that the Voodoo is STILL the pimp?
For those of you without older .plan access, here is the new table:
Chipset P5/200MMX(32MB) P2/266(128MB)
3Dfx Voodoo, GL_ZTRICK=1, nosync 33.8 33.9
3Dfx Voodoo, GL_ZTRICK=0, nosync 30.2 30.3
NEC PowerVR PCX2 (new drivers) 29.1 31.3
3Dfx Voodoo, GL_ZTRICK=1 27.2 27.3
3Dfx Voodoo, GL_ZTRICK=0 24.4 (forgot to run test)
NVidia RIVA128, GL_ZTRICK=1 24.0 32.2
NVidia RIVA128, GL_ZTRICK=0 23.9 32.1
NVidia RIVA128, GL_ZTRICK=1, 800x600 (didn't bother) 25.7
NEC PowerVR PCX2 (old drivers) 23.1 24.5
Rendition V2200, GL_ZTRICK=1 19.0 19.4
Rendition V2200, GL_ZTRICK=0 18.8 19.2
3DLabs Permedia2, GL_ZTRICK=1 18.6 19.2
3DLabs Permedia2, GL_ZTRICK=0 18.6 19.2
WinQuake (software only) 13.5 12.6
September 2, 1997 (early AM)Disruptor .plan update - Slipgate
-----------------
Dammit all, I hate giving out "buying recommendations", but people INSIST on asking me over and over what board to get, even though I keep telling people to get a Voodoo-based board as the "safe bet". So, let me state this once and for all and hopefully people will get the message:
- the 3Dfx Voodoo currently has very good performance, very good features, and it coexists reasonably well with existing video cards. It supports the portion of OpenGL we need for GLQuake, GLQuakeWorld, and Quake2. It's blazingly fast, even if long in the tooth. It's not that expensive anymore. It works with NT and Win95. Canopus has a 4MB texture version. It's VERY difficult to go wrong with the 3Dfx Voodoo. So unless you meet the following criteria, I'd say go with the Voodoo (Righteous 3D, Obsidian, Flash 3D, Canopus, whatever). And no, I do NOT mean Voodoo Rush -- I haven't tested it yet so I can't offer an opinion on it one way or the other.
Okay, so when should you NOT get a Voodoo?
Get a PowerVR PCX2 board (Matrox has one) if
- you already have a 2D accelerator
- you don't care about WinNT support and plan on using Win95 exclusively
- you're willing to give up high quality colored lighting with Quake2
- a full OpenGL driver isn't that important to you
- you wanna save fifty or so bucks over a Voodoo based board
Get a RIVA128 board (STB, etc.) if
- you do NOT have a 2D accelerator and want a fast 2D/3D board
- you don't care about Win95 OpenGL support in the next few months
- you don't care about Win95 hardware accelerated Quake2 in the next few months
- a full OpenGL driver (under NT) is important to you today
- you can live with 4MB of framebuffer
Get a Permedia2 board if
- you do NOT have a 2D accelerator and want an okay 2D/3D board
- you need OpenGL support under both Win95 and WinNT TODAY
- you need 8MB of framebuffer
- you're willing to give up high quality colored lighting with Quake2
I'm withholding final opinions on V2200, ATI Rage Pro, and Intel i740 until I have production boards with good drivers in my hands.
That's it, that's all the advice I can dispense until I do more tests, which I swear to all my pagan gods I will not do until we have Quake2 test suite.
Then again, my pagan gods are used to me lying, so I figure I'll likely run a few more tests as I get better drivers and newer boards. Hopefully, though, a Quake2 TIMEDEMO will be available in another week or two.
Oh, before I forget to mention it, we're still working on OpenGL extensions with SGI and a bunch of hardware vendors. In order of priority to us:
- wglGet/SetDeviceGammaRamp for screen flashes. This will help level performance, especially during death matches. This will be an extension that only makes sense for some hardware. It should help a lot with anyone with a full GDI/Win32/3D accelerator, and it will also help with 3Dfx.
- glColorTableEXT revved up and/or extended to support a single global texture palette. This will allow us to use 8-bit paletted textures on hardware that supports paletted textures, including 3Dfx, Permedia2, and some others. This gives us faster texture download performance (good for deathmatch), and this may make a pretty significant difference in performance for Permedia2.
- wglSwapIntervalEXT so that we can control frame rate very tightly, although I still need to talk to John about this one. This should be trivial to add though.
- EXT_point_parameters for particle rendering. This will probably only make a big difference for deathmatch performance, but it should be a reasonable performance boost across the board.
- multitexture support. This will help out rendering in the world, but it's our lowest priority since not many hardware accelerators support it. Not only that, but it would require the most effort on our part and on the part of IHVs to implement.
All of these extensions will be optional -- if an IHV wants to support an extension, then they can just do it and we'll use it if it's there. The nice thing about this is that an IHV that spends the time to do the extensions and optimize for them will tangibly see their TIMEDEMO scores increase, and so there should be a positive feedback loop established. Given two relatively equal hardware accelerators, the one that implements our supported extensions should soundly kick the other accelerator's ass.
Jesus, and I thought this was going to be a short plan update....
I REALLY hate it when people rip off the GFX in my .planfiles and use it on their pages without asking first, much less not even giving id credit for creating the graphics...PC Gamer take off Labor day? - Slipgate
/me goes back to work
are registered trademarks of id Software, inc. I've had
that statement there for months now. In any case, Disruptor is right that
I should have asked first.
I would like to take a moment in order to let everyone know that a team with an UNDISCLOSED name is currently working on an exciting "project" (can't let you in on the secretive project unless you become a member). We need a few good people for the following jobs that still need to be filled:Nebula redesign - Slipgate
2 coders
1 mapper
And if you just so happen to extremely talented in some other creative field such as art, modeling, or music feel free to contact me as well.
The current members of this "project" include:
Slipgate AKA Ismail Saeed (of Quake2.com) as a coder
Nite AKA Darryl Ashton (of 3Dx.org) as a joe of all trades
Tatter_D AKA Michael Anzulovic (who made the first Quake grappling hook)
Orca3D AKA Peter Lewyllie (Excellent modeller)
Chris Pern (Excellent sketch and computer artist)
And myself (Jonathan Ruff, mapper, and man of all trades).
This is truly an incredible project, so don't miss the chance to join, that is if you're qualified to fill any of the needed positions.
Please, be advised this is a serious project that will require a lot of work and effort, but it'll be fun and worth it. If interested, e-mail me at jonathanruff@thenebula.com. Please include a sample of your work or a location where an example of your work can be found.
August 31, 1997
-----------------
As promised, I reran the benchmark numbers. To be perfectly clear, this is what I'm doing:
GLQUAKE 0.93
640x480, fullscreen, 16bpp
-lm_4 for the Permedia2
no status bar or console
TIMEDEMO DEMO1
WinNT 4 SP3 for all but PowerVR PCX2
Win95 OSR2 for PowerVR PCX2
-nosound on the P2/266
sound enabled on the P5/200
Now for the results:
Chipset P5/200MMX(32MB) P2/266(128MB)
3Dfx Voodoo, GL_ZTRICK=1, nosync 33.8 33.9
3Dfx Voodoo, GL_ZTRICK=0, nosync 30.2 30.3
3Dfx Voodoo, GL_ZTRICK=1 27.2 27.3
3Dfx Voodoo, GL_ZTRICK=0 24.4 (forgot to run test)
NVidia RIVA128, GL_ZTRICK=1 24.0 32.2
NVidia RIVA128, GL_ZTRICK=0 23.9 32.1
NEC PowerVR PCX2 23.1 24.5
Rendition V2200, GL_ZTRICK=1 19.0 19.4
Rendition V2200, GL_ZTRICK=0 18.8 19.2
3DLabs Permedia2, GL_ZTRICK=1 18.6 19.2
3DLabs Permedia2, GL_ZTRICK=0 18.6 19.2
WinQuake (software only) 13.5 12.6
As always, post-game commentary by moi.
- 3Dfx Voodoo -
The undisputed king for longer than I can remember, the Voodoo is still holding its own against the various contenders to the throne. The best indication of performance is with "nosync", since even though the Voodoo syncs to vblank by default, none of the MCD-based accelerators (RIVA128, V2200) do, so it would be unfair to compare the Voodoo w/ sync enabled against any MCD based board.
The main things going against the Voodoo are the typical -- lack of texture memory, a maximum texture size of 256x256, and the fact that it's a 3D-only accelerator. It's also a 16-bit board through and through, meaning we can only get a 16-bit framebuffer and 16-bit Z-buffer and 16-bit textures.
However, it has all the features we think are important, including support for colored lighting in Quake2 and per-pixel MIP mapping.
- 3Dfx Voodoo Rush -
Okay, just to address this once and for all -- we don't have a Voodoo Rush here, and from what we've heard it isn't something we'll miss. So no numbers for the Voodoo Rush. Sorry.
- NVidia RIVA128 -
Man, this is one studly board. It has some architectural limitations we're not fond of, however it's the first non-3Dfx accelerator that runs Quake2 (for the most part). It has some disturbing problems though. For starters, the max of 4MB really cramps your style when trying to do hi-res stuff. Also, we noticed some cracks between adjoining polygons, and that REALLY has us scared, since that may be a problem with their hardware (they do onboard triangle setup) that can't be fixed. That would be REALLY BAD for them.
However, they support our colored lighting model, which is cool and gives them an advantage over Permedia2 and PCX2. The RIVA128's driver is missing the implementation of glTexSubImage2D, which we need for dynamic lights.
The RIVA128 won't be able to run our level editor because of the lack of memory, which really really sucks.
This uses an MCD based driver therefore I assume when they get a full OpenGL driver (ICD) happening that their performance will go up considerably.
- NEC PowerVR PCX2 -
Good performance at a great price. Hard to beat if you can't afford a Voodoo and if you're willing to give up colored lighting in Quake2 then you can save fifty bucks and go with the PCX2. Also, no annoying pass-through cable. But you do lose WinNT support with the PCX2, so you NT-fans out there may need to go with the Voodoo. Other than the Voodoo this is the only board out of this pack that offers per-pixel MIP mapping.
Other nice things about the PowerVR PCX2 include optional support for 24bpp rendering and the ability to render at 800x600 or even 1024x768. And they don't really have a Z-buffer (that's why there were no numbers for GL_ZTRICK) but they essentially have a very high resolution virtual Z-buffer.
- Rendition V2200 -
This is a competent board, unfortunately the performance was quite a bit lower than we had hoped. We're assuming that this is a driver optimization issue, but we're not 100% sure at this point what the cause of the lackluster performance is. The V2200 also ran Quake2 completely and successfully, and they even implemented glTexSubImage2D so that dynamic lights were working.
Other things I like about the V2200 is that it supports LOTS of memory, like 16MB and stuff. A 16MB V2200 would be an AWESOME professional board and wouldn't cost that much compared to a "real" professional graphics accelerator.
This uses an MCD based driver therefore I assume when they get a full OpenGL driver (ICD) happening that their performance will go up considerably.
Currently their driver does not support MIP mapping, however they have plans to implement per-polygon MIP mapping soon which will improve both the appearance and performance with their driver.
- 3DLabs Permedia2 -
The Permedia2 didn't have the best performance, however it runs both the game and the editor successfully (albeit the former without colored lighting). It supports memory configurations up to 8MB, which is nice -- I wouldn't recommend that you purchase a 4MB Permedia2.
They are ICD based so they should have a lot of lee way when it comes to optimizing their driver. Also, at their request I ran with a "Sub-buffers" set to 8, but that didn't seem to make a difference with performance.
They have a glaring bug in their driver that will prevent people from running Quake2 in fullscreen mode, at least until they fix their drivers. The specific bug, for you techies, is that you cannot call ChangeDisplaySettings after you've done a wglCreateContext.
Lack of any form of MIP mapping is a killer with this chipset. They should at least implement per-polygon MIP mapping to both improve performance and make the really disgusting aliasing problems go away.
- ATI Rage Pro -
I opted not to publish results for the ATI Rage Pro since their driver was having, um, "issues". When I get drivers that are more stable I'll post results then. Right now the results are not really encouraging, however in their defense they did run both the game and the editor. As a matter of fact they support the colored lighting blending mode we need and glTexSubImage2D for dynamic lights.
- Conclusion -
This is a pretty good batch of boards, and it's obvious that things have improved a WHOLE lot in the past three months. By Christmas there should be at least three boards good enough to run Quake2 that support OpenGL under Win95: 3Dfx Voodoo, 3DLabs Permedia2, and PowerVR PCX2. Under NT we have support from Rendition and NVidia, and I expect both of these companies to release full OpenGL drivers for Win95 in the future (unless Microsoft descends on them like a pack of angry weasels, which I'm fairly certain will happen since Microsoft largely consists of angry weasels).
Correlating these results to Quake2 should be fairly straightforward. The major thing that may affect future performance is our support for 8-bit paletted textures. This will help 3Dfx a bit, and should definitely help Permedia2 and Rendition V2200 a LOT. I believe it's irrelevant for RIVA128 since I've heard they don't support paletted textures (which is fine by me).
Okay, no more performance updates until we have a performance test suite for Quake2 working, which will hopefully be in a couple of weeks. And at that time hopefully we'll have new drivers from everyone. Things should only be getting faster from here on out.
> I know there are ont any exact dates but do you think Quake II will beWeekly stuff - Slipgate
> out by November? The date is not important but the month, because I'm
> planning my trip to the US depending on the Quake ship date. And do
> you know which stores will be the ones to have first?
Like you said, no certain dates. We can't say for sure it'll be out by November.
Maybe November or December, that's as good as we know yet.
Stores like Sofware Etc. will likely have it first.
--
Slipgate - AKA Ismail Saeed
Webmaster, http://www.quake2.com
mailto:slipgate@quake2.com
<ZenTroN> tokay, ya guys going to improve the gore aspect in quake2? like add more gibs etc..?Hope that answers folks' questions about the gore in Quake 2.
<tokay> zen: yes, things are pretty bloody right now... they might get even more bloody
I've been thinking about the Quake 2 web and clan rings recently.Quake 2 FAQ news - Slipgate
Quake has so many different webrings for different topics (the CTF ring, the player's ring, the female player's ring, the clan ring, etc. etc.)
With Quake 2 we are plugging clans into the Quake 2 clanring and EVERYTHING else into the webring. I don't know if this is the best way to continue doing this. I mean, how useful would it be if all the Quake pages out there were in the "Quake web ring?" It wouldn't have the specific breakdown of topics the Quake webrings have. In the Quake 2 ring, you don't know what to expect next, a news page or screenshots or what. But in rings like the CTF ring, you have a general idea and your scoping out sites following that idea.
Because of this I've wondered if it might be better to scrap the Quake 2 webring and replace it with several webrings with more specific divisions.
I've been kicking around this idea for a while, I'd like any opinions anyone has to offer on this.
I am starting a page which will (hopefully) be a massive archive of ideas for TCs, mods, addons, etc. for any future 3D game, also including Quake. If you have any ideas floating around that you would like to see used in a TC/mod/whatever, please email me at nite@3dx.org and tell me so.Thanks to the Prophet of Quake news for letting me know (as well as Nite himself).
August 29, 1997 (part 2)Illuminati TC update - Slipgate
-----------------
DEC Alpha port was completed in record time. I made sure everything was working on the x86 side of things, closed down MSVC on my workstation, went over to the Alpha and brought up MSVC on it. I loaded up the projects, created new project configurations for them for DEC Alpha, recompiled, and by and large shit just worked.
Wow.
There was one place where I had changed the x86 asm and hadn't updated the C-only version, but that was fixed with a search-and-replace.
So Porting Stage 1 is complete. Hopefully John will be able to port the software renderer to Rhapsody this weekend, verifying that our ref architecture is valid.
At this point the renderer is largely feature complete. There's one more feature that Cash wants me to add that I'll probably do this weekend, then from this point on it's optimization, clean up, and bug fixes in the renderer.
I can't give performance numbers for the DEC Alpha yet since we don't really have a good benchmarking suite.
Once again folks, if I don't say it in my plan, then assume that I either don't want to say something or I can't because of NDA issues. Someone asked me what the "issues" were that I was facing with the Rage Pro and Rendition V2200, and as anyone who has read my .plans for more than a day will know, if I CAN say something then I WILL. Terse plans are NOT something that I am notorious for! :-)
Send me e-mail if you want clarification, but don't expect special treatment with an "inside scoop" just because you e-mail me privately. I've had people ask me for the beta OpenGL drivers for RIVA, etc. and that's just uncool.
are
registered trademarks of id Software, Inc.