Slashdot Mirror
Doom 3 Programmer on OGG, Ultra, 60FPS Play
Cryect writes "Appears that Doom 3 is making use of Ogg Vorbis to reduce memory usage for sounds. This comes from id programmer Robert Duffy's latest plan update where he says: 'When we started on memory optimization, most levels used between 80 and 100 megabytes of sound data. We made the choice to move to .OGG for quite a few sounds which effectively removed the problem for us.'" Duffy also comments on texture usage in 'Ultra' mode ("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") and framerate ("The game is capped at 60fps for normal game play. For render demos, like what was used for the HardOCP stuff, we run those at full tilt which is why you will see 60fps.")
The Unreal Tournaments, I believe.
And how could Ogg possibly improve the size of their sounds? Ogg is a container format. I think they mean Vorbis, the compression codec.
I know I'm being anal retentive. I don't care.
-- mind over pixel
The Vorbis format really is a godsend for gamers, because in the game programming world, the roadblocks which otherwise hinder it are gone. For one, the no license fee argument becomes applicable - Vorbis doesn't help portable player makers much, because they have to support MP3 and WMA anyway. But since the consumer doesn't care what format game audio is in, programmers can go for a cheap (BSD licensed), easy (good APIs), and very good (high quality) solution without worrying about making the game less useful. Many games already use Ogg Vorbis, like UT2003/4 - here's a complete list. (Well, it would be there, if the Wiki was up.)
You would be correct.
From Vorbis website --
"You and your third dimension."
Yes, but not enough to be noticable. Compressing the various media files in games has been common for quite a while. In some cases it's actually faster to get a compressed file out of RAM and decompress it to work on it than it is to move the big, uncompressed file in and out of RAM, simply due to the relatively huge bottlenecks in RAM and hard disk transfer speeds. An extra couple million cycles is easier to come by than an extra 100 MBps.
You are correct. Shifting the burden from a resource that can't handle a load to a resource that can is a big part of optimization
With processors being as fast as they are now, it is actually more adventageous to do extra processing on the processor then to have to fetch stuff from RAM. I don't know about sound, but I know in graphics rendering sometimes you will go for an effect that requires more processing time if it will save you from having to access memory. At one time it was the other way around, you didn't care how large the data was in memory (within limit of course) so long as it was simpler and easier to process.
Reserved Word.
The best example is probably in the old Voodoo2 SLI setup, because it had partitioned memory. The texture memory had the same contents on both cards; what was duplicated was the frame buffer. Back then, the frame buffer was big. Since it's more textures now, SLI probably won't do much, if anything. It could conceivably make it worse, due to overhead. I doubt that last, though.
"The game is capped at 60fps for normal game play. For render demos, like what was used for the HardOCP stuff, we run those at full tilt which is why you will see 60fps."
This quote made no sense to me until I did RTFA, and realized that it was faulty. What really was written in the article was:
"...which is why you will see > 60fps."
I read a review in a magazine that listed an Alienware with a P4 3.0GHz, 1GB RAM DDR400 and a Geforce 6800GT, which ran the game at 1600x1200 with high details (that's one notch below ultra, only difference being the usage of compressed textures, so it's full settings if you don't count texture compression) at 40-60FPS. They didn't say anything about AA or AF settings.
Justice is the sheep getting arrested while an impartial judge declares the vote void.
MOV is a container. It "contains" the metadata for the codecs (in addition to other information) and also contains the audio and video streams. It's possible to have a MOV file with only audio. Ogg is also a container. The audio in the Ogg file is called Vorbis. OGG containers can include video as well, which will most commonly be Theora based (off of the VP3 format) in addition to the Vorbis audio. OGM files are also containers, that typically have Divx video and Vorbis for audio (instead of the norm of MP3 for the audio portion).
WAV should not be classified as the same sort of thing. It is not a container. it is not compressed. It's essentially a (slightly modified) raw PCM bitstream.