^/\^ PeaK /\^/\

• 1.1 Background
• 1.2 OpenGL Politics
• 1.3 OpengGL and Games
• 1.4 Better Effects/Modeling in OpenGL
• 1.4.1 Installing ATI Beta or MCD OpenGL driver
• 1.5 Speed vs Quality in OpenGL
• 1.6 ATI's Alpha/Beta ICD OpenGL for Quake/Quake2
• 1.6.1 GLQuake Results
• 1.6.2 OpenGL Quake2 Results

1.1 Background
The evolution of 3D from a highly specialized niche research market funded in the early days by military based research in flight simulators to common hardware found in today's AGP graphics cards and motherboards demonstrates the technology trickled effect that is common to a lot of high technology areas. 3D is a current buzzword and if you happened to have found this link, I would suggest that you read the following 3D primer first. I wish to discuss the issue of device drivers or what is known as the marriage of hardware and the gaming industry's new darling: OpenGL (about a week after I wrote this page, I came across another page that does OpenGL more justice for newbies and non-newbies alike...please check it out

1.2 OpenGL Politics
John Carmack has stirred the pot and should make things interesting for 3D by porting Quake to a OpenGL. This API is broken down into three sections like DirectX (see ATI OpenGL FAQ and ICD/MCD FAQ):

1. transfromation(CPU)
2. lighting(CPU)
3. rasterization(Video Chip)

SGI had long ago licensed Microsoft to use OpenGL and the most logical way to divide the work efficiently was to have a common transformation and lighting layers implemented in software (i.e. setup) while having the hardware vendors marry rasterization aspects in their drivers. Thus the mini-client driver (MCD) was born. It may seem curious to you that OpenGL MCD exists on WinNT first and not on Win95. I think Microsoft figured that they attack the Workstation market by having an OpenGL interface to encourage the porting of Various OpenGL application packages. OpenGL MCD is perceived to be a threat to DirectX. Simple enough.

Like DirectX, the major benefit was the marriage of the last "rasterization" leg of this process with hardware to attempt to provide a real-time gaming interface. The setup and transformation aspects have taken Microsoft years to perfect (and they are good at this stuff) and now they are withdrawing it from Win95. Why ? It will take Hardware Vendors (IHV) much effort to implement the ICD (Installable Client Driver) as each of them must do the transformation and lighting aspects for each piece of hardware. Microsoft should do the right thing and invent the MCD (remember it exists) once and prevent countless hours of toil by having graphics hardware companies . The only good I see is that some of "setup" capabilities will not only be done in software but will take advantage of some of hardware setup capabilities. Microsoft should take a leaf from Richard Stallman of GNU fame said " I was extremely impressed by the sharing spirit that we had. We were doing something that we hoped was useful and were happy if people could use it." There are too many real problems in the world to solve.

1.3 OpenGL and Games

OpenGL has been the workhorse standard in the Workstation world for years. It is robust and and yes...it runs on Linux...albeit only in software form at the moment. John Carmack's offering of a OpenGL version of Quake and his view of a 3D programming has caused a clarification about an API's ease of use versus speed within the industry with regards to APIs. Card vendors I think will need to support both Direct3D and OpenGL.

There are many variants of Quake. The one of most interest would be the version taking advantage of Direct3D. The overall question is visual quality/physics traded off against "fps" speed. The best solution is to engineer the bottleneck to happen simultaneously everywhere in the rendering pipe. In DOS quake and WinQuake, the CPU handles transformation/lighting and rasterization. The amount of data tends to explode at the end of the pipe(i.e. rasterization) , so scaling down the effetcs upstream (i.e. fricition modeling), lighting complexity (i.e. shadows, mirrored images, lens effects in water) has a big impact on the required CPU bandwidth/processing power budget to achieve a certain framerate.

The net effect is that we have blocky textures and 320x200 windows(doublescanned). All the new 3D hardware indirectly gives more options to the game developer or applications person by alotting him the CPU savings gotten from the rasterization stage.

1.4 Better Modeling/Effects in OpengGL Quake

When John Carmack and ID began a program to have their games take advantage of 3D hardware, they targetted OpenGL due to its support of high level abstraction. In the process the better/easier game development allowed for ID to implement and experiment with new features to be cleanly and efficiently coded. The following is taken from Zanshin and highlights the architectural differences between OpenGL version of Quake and DOS/ported DOS-Windows version of Quake.

GLQuake is a version of Quake written for the OpenGL rendering library and compiled for win32. It provides real-time texture mapped surfaces, bilinear filtering and 16-bit color as compared to regular Quake's 256 colors. The complete lack of pixellation is stunning in GLQuake. Textures that previously appeared grainy are sharp and clear both up close and in the distance. GLQuake also provides new visual effects not found in regular Quake, such as shadows, reflective and partially reflective surfaces, luminous weapons fire and water transparency.

ID software gives us a glimpse of how much a image can look by taking advantage of the hardware via OpenGL. Porting to Direct-3D would have been much harder....although possible...but also ID to bypass some of the archiectural pipeline inefficiencies in Direct-3D that 3Dfx solved via their GLIDE interface. The overall penalty for Intel CPUs is estimated to be a 25% speed hit. Gee, no wonder John carmack and the principals from 3Dfx/game companies love the proprietary Interface. To get commentary and a great overview on the entire OpenGL controversy where I first learned of this Direct-3D issue see Paul's page.

Some of the new "way cool" 3D effects implemented that are not found in non-OpengGL versions of Quake are:

1. Reflections:You can see yourself in the stain glass window on the left hallway before you enter select the easy level
   R_MIRRORALPHA 0 ( Default is 1 for speed but no mirrors)
   
2. Water lens effects: modeling of transparency of water
   R_WATERALPHA 0.3 ( Default is 1 for speed and no transparency)
   R_NOVIS 1 (Default is 0 for speed. It must be set to 1 at same time a above for transparency)
3. Better shadowing: generate more reaslistic shadowing effects
   R_SHADOW 1 (Default for speed is 0)
   
4. Less Blocky Textures: OpenGL takes advantage of alphablending in D3D or uses CPU cycles for to blend edges hiding staircase effects. Best see when close to a texture surface of object. Below is a list of setting from fastest/blockiest to most detailed/slow
   
• GL_TEXTUREMODE GL_NEAREST (fastest but blocky like all other Quakes)
  
• GL_TEXTUREMODE GL_NEAREST_MIPMAP_NEAREST
  
• GL_TEXTUREMODE GL_LINEAR
  
• GL_TEXTUREMODE GL_LINEAR_MIPMAP_NEAREST (Default)
  
• GL_TEXTUREMODE GL_LINEAR_MIPMAP_LINEAR
5. Multi-texture Support:OpenGL support single pass processing of textures for hardware with this feature to speed up processing framerate. To get an idea of the increase in framerate, set:
   R_FULLBRIGHT 1 (Default is "0" so that lighting of textures is properly done.

When they then decided to make money by porting to the Win95 D3D platform they found an ill-birthed coding interface that inflicted pain and discouraged experimentation. They did something with integrity for the gaming industry, by ballking at following the Microsoft game worshipppers eyeing the Win95 game market/$$$, and did not release a version of Quake supporting 3D hardware features via Direct3D. Cool. Because WinNT had already released an MCD to woo users of the mature workstation-based OpenGL market, ID had a very weirdly targetted audience for GLQuake. The good thing about it was that they could use this platform to gauge tradeoffs in deciding which Quake/OpenGL features/instructions to support on a popular platform. Micosoft did an about face and did not release the promised Win95 MCD.

1.4.1 Installing ATI Beta or MCD OpenGL driver

Some clever individuals have GLQuake to be run on advanced 3D hardware by writing a translation layer between the subset OpenGL code emitted by GLQuake to Direct3D. One version is GateGL that somehow manages the above plus the transfomation/lighting portions that are supposed to so difficult to achieve in an ICD/MCD. (Somebody fill me in). The rasterization is taking care of by emitting Direct3D code. Because Direct3D is written at the same or lower level than OpenGL so that the idea of an "OpenGL to DIrect3D translator" or "D3D Wrapper" was born. Microsoft's original vision was to have divide up the work between the game developers and video hardware manufacturers by having the games target D3D and "D3D to hardware" driver portion implemented by the manufacturers for each piece video card.

To Run GLQuake under Win95:

1. Grab GLQuake (270K) from ID software
2. Grab one of the following driver files (opengl32.dll)
   

a) ATI's Beta3 OpenGL driver
b) original D3D Wrapper zip file
c) relevant wrapper from this collection




3. unzip it into the C:\quake directory and rename the the driver to opengl32.dll if it is not already called so.
4. Make sure you have you WAD (pak0.pak) file save under c:\quake\id1. You can grab this from the shareware version of Quake 1.08
5. Open Win95 Display settings under "control panel" and change to 16 bit mode
6. Set your Display Resolution to 800x600 (not 640x480...don't ask me why?) and 16 bit and create a Shortcut starting in C:/quake with the command
   glquake -window -width 640 -height 480 -nolan -nocdaudio

1.5 Speed vs Quality tradeoffs on OpenGL

Microsoft surely could have released something similar, as performance is OK but nothing to write home about. The original wrapper has texture blending implemented but runs a bit slower than the S3 wrapper which does not implement this feature. Bottom line is that GLQuake/Wrapper does not seem to improve upon the WinQuake speed much...the only consolation is that the textures are blended (except S3 wrapper) for better reallism. Reflections are also supported as well water lens effects. For those speed junkies that still do not get it:

1. GLQuake/3D card/MCD = microsoft dropped the ball
2. GLQuake/3D harware/wrapper = what MCD might have been or a bit less
3. GLQuake/3D hardware/ICD = >20-25 fps + more detail/effects

In case [1], gamers expected FPS advantage due to D3D. This might not be true if OpenGL code emitted was low level and volumous and numerous low level floating point transformation/CPU calls were requiired to support D3D calls. [2] sufffers from the above but at least we can commnent about the image quality and framerate in a wrapper worth 50K...how did they do all that in such a small space ??? Even in the best scenario [3], GLQuake's promise is not more framerate but suffcient framerate. The VooDoo has the bandwidth today to turn up the features and still maintain framerate but it has excessive framerate that could/should be traded off for lower price/performance ratios. Even so it is not adequate when more of the OpenGL knobs are turned on (it is sad but there is life after GLQuake called OpenGL apps) with some of the heavier duty workstation OpenGL applications.

Read the primer following on OpenGL/3D hardware by Zanshin and if what he says is true then there are some gaps in the puzzle as to what the above two wrappers have accomplished in a file about the size of 50K.

• OpenGL is based upon a concept of display lists . The best a hardware vendor can do is a direct port to the metal...but if the metal design does not lend itself easily to supporting this feature for real-time rendering, then the best port in the world will be hampered by the hardware implementation...but there is a catch.
• Microsoft provides a low cost stategy called a Mini Client Driver (MCD) so that functional operation of OpenGL applications can be assured. The applications they had in mind for this were for applications like 3D viewing etc. Graphics hardware companies implement the MCD layer by marrying the hardware with the reuqired rasterization routines. Zanshin's point is that there are some in-efficiencies in doing this. This being the lack of hardware acceleration for the common software layers provided by Microsoft in the lighting and transfromation alogorithims.
• OpenGL as implemented on Windows NT MCD provides a software emulation layer written to provide a software rasterization routine if not implemented by the hardware vendor. This as you can imagine is really slow. What we are seeing are the same steps the industry saw with early 1st generation 3D hardware.

• The best performance and most work is to create their own Optimized OpenGL interface replacing the setup aspects provided by Microsofts MCD. GLQuake only uses a subset of the OpenGL interface so that a an simplified ICD may be possible.
  

1.6 ATI's ICD OpenGL for Quake/Quake2

Rage Pro users have recently tested out the ATI's first OpenGL driver running Quake and Quake2. Here are performance numbers based upon framerate for the demo version of Quake running Demo2 via the TIMEDEMO facility:

ATI has released three Beta drivers to date.

1. Accidentally released Alpha: OpenGL driver with major z-buffering problems released to gauge baseline performance. File glqvxxxx.exe file eleased March 9, 1998.
2. Beta1: 50% better peformance than pre-release ALPHA driver. AGP cards shown to be performing below that of PCI. Z-buffering problems still reduced by still present. 460K beta1.zip file released March 23, 1998. Used by Anandtech in his CPU/accelerated chipset comparisons.
3. Beta2: Most z-buffering problems eliminated. AGP framerate on par with PCI cards, now. Released March 30, 1998.
4. Beta3: Similar to Beta2 driver but Hexen II used to flush out more problems. Final release until full ICD. File releaased on April 16, 1998.

The new Beta[123] OpenGL drivers seem to give roughly a 50% increase in framerate when combined with the new Turbo 2312 Driver on a PCI system. Numbers for AGP system were below those of PCI for the Beta1 release.

Table 1: Quake 0.97 TIMEDEMO DEMO2 Results

Table 2: Quake 2 Demo1 Results

1. GLQuake 0.97: the framerate is pretty good. Second(Alpha) only to the Riva for cards that can display in a window. The Beta drivers show a 50% improvement over the Alpha drivers for Quake2 but I could not find any quotable sources for framerate under GLQuake. The Riva cards are acknowledged to have display artifacts associated with textures blending. The Rage Pro visual quality is reputed to be better or equal to the VooDoo. I could not find a firm framerate quote while running under a P2-300 for the alpha or beta drivers.
   
   Quake2 DEMO1 runs at about 75% of the framerate of Quake DEMO2. So tell Tom to not bother with running all the 2000+ experiments using different processors and video chips :)
   
   On a highend P2-300 machine, the Alpha numbers are about 10% worse than Riva and Permedia but equal to the VooDoo Rush. The Beta drivers added 50% boost punt the RagePro into second place behind the VooDoo. It seems that the VooDoo Rush window mode puts everyone on the same playing field as other chips and the framerate is about the same as the Rage Pro. Is it that multitexture support, that allows texture processing in a single pass (vs two), can only be done full screen ?
   
2. The use of Glide to bypass D3d's vertex arrays may give it up about a 25% performance advantage over other equivalent hardware running OpenGL but emitting D3d calls. An ICD will afford the opportunity to bypass this potentially. See 25%
   
   The RagePro and Riva are hurt equally with weak processors. The Rendition and VooDoo Rush chips do better here and this may be in part a result of ID Software.developing on these platforms and tweaking their engines to perform under weaker CPUs.
   
3. Bugs:
   
   GLQuake: Clipping problems exist due to negative Z-buffer issues: try R_MIRRORALPHA 0.3 on the console. I cannot comment about Quake2 with this turned on. Timedemo of demo1 gets hung on my machine with the sound card going into an endless loop. Workaround is to start a game prior to this recorded sequence gets a chance to load.
   
   
4. Quake2 seems to run a lot smoother than the indicated framerate: I think this may have to be due to the slow down in wide open areas where many triangles exists. I would suggest using a watch to calculate the actual time and number of frames to be sure.
   
   
5. Framerate for the DEMOs seems to be highly variable from one run to another but bimodal in distribution: Could the people seeing these type of variations put a clock on the demo ? The DEMOS generate a fix number of frames and the framerate is generated by dividing this number by the time.
   
   
6. Multi-texture support could provide a speedup for future OpenGL drivers for the RagePro due to the capability of the hardware. Set R_FULLBRIGHT 1 to get an idea of the framerate increase.

Comment:The PC hardware industry has always been driven by constant and unrelenting "whining". It used to be the Editors of major PC hardwre magazines who assumed the helm. It led to breakthrough concepts such as the accelerated 2D windows interface that is today synonymous with a PC. This torch has now been picked up by niche gaming magazines making up a small but well practiced group ignored previously until now. Distributed reviewing has been a gold mine for other geeks, like me, for sharing opinions and developing a consensus but there is quite a lot of I publish ...therefore I am ... Most of the junky stuff just never gets read . It only upsets me when someone with a mostly good web page (hence influence) presents a mostly one sided view for effect only ...excuse me as I vent/tangent onto another page.