HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Thu, 04 Jun 2009 11:10:33 GMT Cluster-Server: WEB1 P3P: CP="NOI ADMa OUR STP" X-Powered-By: ASP.NET Connection: close Content-Type: text/html

404 Object Not Found

HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Thu, 04 Jun 2009 11:10:33 GMT Cluster-Server: WEB1 P3P: CP="NOI ADMa OUR STP" X-Powered-By: ASP.NET Connection: close Content-Type: text/html

404 Object Not Found

HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Thu, 04 Jun 2009 11:10:33 GMT Cluster-Server: WEB1 P3P: CP="NOI ADMa OUR STP" X-Powered-By: ASP.NET Connection: close Content-Type: text/html

404 Object Not Found

GameSpy:
14851 users in the last hour. HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Thu, 04 Jun 2009 11:10:33 GMT Cluster-Server: WEB1 P3P: CP="NOI ADMa OUR STP" X-Powered-By: ASP.NET Connection: close Content-Type: text/html

404 Object Not Found

PlanetQuakeHTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Thu, 04 Jun 2009 11:10:33 GMT Cluster-Server: WEB1 P3P: CP="NOI ADMa OUR STP" X-Powered-By: ASP.NET Connection: close Content-Type: text/html

404 Object Not Found

HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Thu, 04 Jun 2009 11:10:33 GMT Cluster-Server: WEB1 P3P: CP="NOI ADMa OUR STP" X-Powered-By: ASP.NET Connection: close Content-Type: text/html

404 Object Not Found

Editorial Index

Recent Editorials:

I WANT my CD key!
12/13 - id's decision to use a CD key is justified

Report Card to the NIMF
12/1 - A response to the NIMF's report on violence in video games

Violence and Gaming
11/16 - Quake responsible for youth violence?

A Purist's Rules for FPS Multi-Player Design
11/5 - Keeping FPS' clutter-free

Rebuttal to Essobie's Editorial
10/15 - Grapple Controversy-Part Deux
The Woes of Being a Multi-Gamer
10/12 - Game Loyalty?
CTF != The Grappling Hook
10/7 - Q3 Arena sans grappling hook?
Jailbreak and Free Lunches
10/4 - Do mod makers "owe" people anything?
Pixels and Texels
9/13 - A look at the future of video cards
Yes, Camping is Evil!
9/2 - A response to "The Evils of Camping"!
Give Me Cable or Give Me Death!
8/31 - Will we all be LPBs one day?
Does Age Equal Maturity?
8/25 - A look at the age factor in gaming.
HeadHunting
8/23 - Mods and intellectual property
To Smack or Not to Smack
8/12 - Trash talking and the FFF!
The Evils of Camping
8/9 - We love to complain!
Trends in the Gaming Industry
7/13 - A look at the shift to multiplayer only games
32-bit Graphics Shows 3dfx's True Colors
7/12 - A continuation about the Voodoo3...
Is She 7 or 17?
6/30 - About the Voodoo3...
Doom 2000 and Q3A
5/26 - Fragmaster speaks his mind
The L33T D00D Multiplayer Tutorial
5/11 - Addressing their needs
Sue 'em All...
4/15 - The id Software Lawsuit
(more)

HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Thu, 04 Jun 2009 11:10:33 GMT Cluster-Server: WEB1 P3P: CP="NOI ADMa OUR STP" X-Powered-By: ASP.NET Connection: close Content-Type: text/html

404 Object Not Found

Comments or ideas? Feedback?

32-bit Graphics Shows 3dfx's True Colors
A continuation of the previous editorial, "Is She 7 or 17?"
  — by
Roscoe Sincero

The actual performance hit of 32-bit color varies greatly from practically zero to nearly 50%. The magnitude of the performance hit depends on the hardware (e.g. TNT2 vs. ATI Rage 128GL), quality of the drivers, the game itself, the resolution, the CPU, and other factors. There are too many factors involved to flatly state with any sort of honesty that there is a "20% to 40% performance hit" with 32-bit color using today's technology. Such a claim would be a boldface lie.

Around the internet, you may see benchmark analyses showing a large performance hit with 32-bit color. In fact, there is an example of such an analysis right over at ShugaShack. What do you see with such an analysis? To be specific, what do you not see? You do not see any 32-bit performance analysis at the lower resolution. You only see an analysis for the high resolution only. I find such an omission to be quite significant.

What is so different about high resolutions that make these resolutions so special? We know that 32-bit color requires roughly twice the amount of data for the 3D card to analyze than 16-bit. It would require twice the amount of information that needs to be communicated to the card's on-board memory. But this is true for all resolutions, not just the high ones. So then, what is so special about the high resolutions? At high resolutions, you will reach the fill-rate limit of the card.

Fill-rate is simply how fast your card can "fill" the pixels of your screen. Here's the definition lifted directly from VoodooExtreme:

A measure of how many pixels a graphics accelerator can render or draw in one second. A good 3D accelerator such as a voodoo2 in SLI mode with a Pentium II 300 can obtain fill rates in the range of 130 -150 Million pixels per second (Mpps). Pixel pushing demons these are !
VE's glossary list looks a little plain. If you wish, you can also try out Dave's Tech Page. Both pages seem to have nearly identical definitions. That is the definition of fill-rate that is being used for this editorial. A more detailed definition is also available here. It should be noted that for the purpose of this editorial, it is assumed that every pixel that is sent to screen memory is also sent to your monitor. This is, of course, not true 99.999 percent of the time for polygon-based 3D accelerators like TNT2 and Voodoo3. There are more pixels that are being sent to memory than what you actually see on your screen. This is due to overdraw. For tile-based 3D accelerators such as PCX2, there is essentially no overdraw. You can read more about that in fill rate and memory bandwidth. If you want to calculate the "actual" fill-rate, you will have to take into consideration overdraw ("depth complexity"). In that case, you will multiple the fill-rate by some number greater than 1 (usually three or four). For this editorial, taking into account depth complexity would not change the conclusion any. I assume that people's math skills have gone beyond the fifth grade level.

You can calculate your card's fill-rate at any resolution easily. Best way to show you is by example. Suppose your benchmarks indicate that your card was able to provide an average frame rate of about 30 FPS at 640x480. The fill-rate is simply 640x480x30 = 9,216,000 pixels per second. There is a limit to how fast your card can "fill" these pixels. That limit is conveniently called fill-rate limit. Fill-rate limit is your card's maximum speed. At lower resolutions, the card is way below your card's maximum speed--the fill-rate limit (or as some people like to call it, peak fill-rate). At the lower resolutions, other factors play a large role in the performance of your card that prevents the card from performing at or near its fill-rate limit. These other factors include such things as how much CPU cycles the card's driver is using up. The games themselves can also use up a lot of CPU power and therefore becoming a dominating factor in performance. An example of such a game is called Half-life. Hardware people often like to call this "CPU-limited" because the CPU is the one that is slowing the performance, not the card itself. At these resolutions and with certain games, the card is performing way below the fill-rate limit. At higher resolutions, the card is performing closer and closer to the fill-rate limit because you are now forcing the card to deliver more pixels.

Keep in mind that CPU usage and the card's raw power in delivering pixels influences the card's fill-rate at all resolutions. However, one is more dominant than the other at certain resolutions. At high resolutions, the card's ability to deliver pixels becomes the more dominant factor. This concept is important. If people are only looking at high resolutions to make their analysis, then they are not simply looking at fill-rate. They are looking at the fill-rate limit.

When they claim a 40% performance hit, they are not actually measuring the performance. They are not measuring the impact of 32-bit color on fill-rate itself or frame rate. They are actually measuring the impact of 32-bit color on the fill-rate limit, not performance. The fill-rate limit actually goes down with 32-bit color and you will only see the effect of this when you reach that fill-rate limit. That is why their claims are not consistent at all with the benchmarks.

Beyond3D has a perfect example of what I have been talking about. They were reviewing the Guillemot Maxi Gamer Xentor 32. It is a TNT2 Ultra. The example is that of the demo1.dm2 benchmarks on his Celeron 450MHz machine. The drivers he used were the ones that came with the card and not the latest drivers released in July. You can easily see from the graphs that the reviewer, Dave Barron, provided that the fill-rate begins to stop rising as you get to higher and higher resolutions. This is what I have been calling fill-rate limit. Some people like to call it peak fill-rate. That is the maximum speed of the card on that machine using that benchmark with those drivers. That maximum speed appears to be around 60 million pixels per second. With 32-bit color support, that maximum speed actually drops. The maximum speed for 32-bit color seems to be around 45 million pixels per second. The graph shows essentially two parallel lines at the high resolutions. At the low resolutions, the lines essentially overlap which means they have essentially the same fill-rate and, of course, same frame rate.


HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Thu, 04 Jun 2009 11:10:33 GMT Cluster-Server: WEB1 P3P: CP="NOI ADMa OUR STP" X-Powered-By: ASP.NET Connection: close Content-Type: text/html

404 Object Not Found