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.")
Does anyone know of any other high profile games using Ogg?
If I'm not mistaken, doesn't this just shift the burden to the processor by adding more decoding time to it in exchange for memory savings?
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
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.)
Here's the question: Why don't game developers take care to run the game on a certain number of de-optimized systems and then release demos with those configurations as well?
I mean, I think it would be nice to see exactly what the game looks like on the Min specs, and if recent games have proven anything, it ought to look incredible.
I ran the UT2004 demo at what must have been hovering near the recommended mark (practically all the special spiffies were turned off), and the graphics still blew me away.
If anything, this might convince me to buy the game or to upgrade hardware to "release" level, and it would also give people a *real* taste of what the game will look like.
By asking for specs, you imply that there is some sort of limit to the lengths you are willing to go to obtain 60 fps at full settings. This is simply unacceptable!
Frame Rate before food!
"But I trust in the people's capacity for reflection, rage and rebellion." -Oscar Olivera
Would SLI of (2)256MB GPUs be sufficient to meet the 512MB requirement?
I'm no graphics programmer, but I'd suspect that no, it wouldn't, because both GPUs would be rendering the same scene, and thus both would need the same textures (and whatever other kinds of maps).
Well, if one GPU renders the top half of the frame and the other the bottom, you might be able to buy a little bit of savings (think floor vs ceiling textures). But I don't expect that to have too much effect.
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.
I ran the UT2004 demo at what must have been hovering near the recommended mark (practically all the special spiffies were turned off), and the graphics still blew me away.
;)
This is completley true for me as well. I almost felt like I was getting something for free.
Questions...
Is it just me or are the developers of UT2004 not getting enough critical and community thanks for making a game that runs so well on crappy systems? I could be totally wrong, but it doesn't seem like they are. Methinks it's just easier for some folks to complain when it *doesn't* work
Next-gen games that run well (or in the case of UT2k4, excellent) on low to mid-range systems would be a welcome paradigm shift and would go a long way to extend the lifespan and relevance of PC gaming. Was that a specific goal of UT2K4's desiginers? If so, how hard is it to implement?
It *seems* like programming for next gen games would be harder for the bleeding edge systems because alot of assumptions about the hardware and drivers have to be made at the very beginning....wheras the crappy hardware in my computer is available for your perusal RIGHT NOW!
Someone enlighten me?
"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.