On DOOM 3 Settings [Jul 26, 2004, 4:07 pm ET] – Share – Viewing Comments
Robert Duffy, id Software programmer,
updated his .plan about DOOM 3 settings and how they will work, discussing
specifics about the "ultra" quality setting as well as differences in how
certain data are handled differently by ATI and NVIDIA hardware. He also
mentions that the game is capped at 60 FPS (except when running demos as a
benchmark), discusses the software used during development, as well as a bit on
a hard drive nightmare encountered along the way. Here's a bit:
Image fidelity is dependent on what quality level we load the textures at.
In Ultra quality, we load each texture; diffuse, specular, normal map at full resolution with no compression. In a typical DOOM 3 level, this can hover around a whopping 500MB of texture data. This will run on current hardware but obviously we cannot fit 500MB of texture data onto a 256MB card and the amount of texture data referenced in a give scene per frame ( 60 times a second ) can easily be 50MB+. This can cause some choppiness as a lot of memory bandwidth is being consumed. It does however look fantastic :-) and it is certainly playable on high end systems but due to the hitching that can occur we chose to require a 512MB Video card before setting this automatically.
High quality uses compression ( DXT1,3,5 ) for specular and diffuse and no compression for normal maps. This looks very very close to Ultra quality but the compression does cause some loss. This is the quality that for instance the PC Gamer review was played in.
Medium quality uses compression for specular, diffuse, and normal maps. This still looks really really good but compressing the normal maps can produce a few artifacts especially on hard angled or round edges. This level gets us comfortably onto 128MB video cards.
Low quality does everything medium quality does but it also downsizes textures over 512x512 and we downsize specular maps to 64x64 in this mode as well. This fits us onto a 64MB video card.
To clear things up for anyone still confused as to why you would want 512MB of RAM on your video card:
The AGP (and even PCI-E) bus is only so fast. If you don't have all the textures in video memory you need to render a scene you have to wait for it to be loaded from RAM over the BUS. If you have two textures that are constantly being exchanged for one another and say they're 512x512x32bit == 1mb each. Each one needs to be copied out of memory (at least) once per frame. at 60 fps that's 60mb/sec per texture. Usually it'll be more than just one or two textures, frequently it's 5 or 6.
AGP bus is 32bits wide and runs at 66mhz and (assuming 8X AGP) has 8 transfer per clock. So that's 2.112gb/sec (I might be wrong on some of the numbers for current hardware, but that's ballpark).
So let's say you have to displace 10 512x512x32 textures each frame and you're running (or trying to) at 60 fps. That's 1mb/sec x 10 (10mb/sec) * 60 fps for 600mb/sec. But you still need to render those textures too and there's no guarantee of what order you'll need them (sort of) so they need to be loaded back in to the video memory for that frame too. So we're up to 1.2gb/sec transfer over the bus JUST to swap out a handful of textures. We have to transfer model data and level architecture as well. Keep in mind that while the transfer is taking place the video card might not be able to do anything, depending on how the rendering algorithm is written (you probably could do some sort of look-ahead code to see what you'll need and displace something that's already been used and won't be used again this frame to keep the GPU from idling out). So you see, if you don't have to swap it out from RAM it saves you a hell of a lot of bandwidth for other things.
If you don't have enough system RAM to cache the textures the game needs to copy to the video card you'll take a *massive* hit when reading the texture from the disk.
If you ever have any chunkiness in a game at the start of a level or when you enter a new area, likely the game just had to grab something from the disk that had either been displaced from memory or had not been cached in the first place.
The AGP (and even PCI-E) bus is only so fast. If you don't have all the textures in video memory you need to render a scene you have to wait for it to be loaded from RAM over the BUS. If you have two textures that are constantly being exchanged for one another and say they're 512x512x32bit == 1mb each. Each one needs to be copied out of memory (at least) once per frame. at 60 fps that's 60mb/sec per texture. Usually it'll be more than just one or two textures, frequently it's 5 or 6.
AGP bus is 32bits wide and runs at 66mhz and (assuming 8X AGP) has 8 transfer per clock. So that's 2.112gb/sec (I might be wrong on some of the numbers for current hardware, but that's ballpark).
So let's say you have to displace 10 512x512x32 textures each frame and you're running (or trying to) at 60 fps. That's 1mb/sec x 10 (10mb/sec) * 60 fps for 600mb/sec. But you still need to render those textures too and there's no guarantee of what order you'll need them (sort of) so they need to be loaded back in to the video memory for that frame too. So we're up to 1.2gb/sec transfer over the bus JUST to swap out a handful of textures. We have to transfer model data and level architecture as well. Keep in mind that while the transfer is taking place the video card might not be able to do anything, depending on how the rendering algorithm is written (you probably could do some sort of look-ahead code to see what you'll need and displace something that's already been used and won't be used again this frame to keep the GPU from idling out). So you see, if you don't have to swap it out from RAM it saves you a hell of a lot of bandwidth for other things.
If you don't have enough system RAM to cache the textures the game needs to copy to the video card you'll take a *massive* hit when reading the texture from the disk.
If you ever have any chunkiness in a game at the start of a level or when you enter a new area, likely the game just had to grab something from the disk that had either been displaced from memory or had not been cached in the first place.
Date
Subject
Author
Copyright © 1996-2025 Stephen Heaslip. All rights reserved.
All trademarks are properties of their respective owners.
Privacy Policy. Manage Cookie Settings.
News CGI copyright © 1999-2025 James "furn" Furness & Blue's News. All rights reserved.
Chatbear v1.5.0/blue++: Page generated 24 June 2025, 16:07.