Slashdot Mirror
DOOM III to be capped at 60 fps
StupidKatz writes "The Inquirer reports that DOOM III will be capped at 60fps, primarily to prevent certain exploitations of the game engine (reminiscent of Quakers that could jump higher, etc.). Although the game's graphics challenges most cards to keep up with the 60fps figure, what might this do to ATi and Nvidia sales figures, considering that the next DOOM incarnation is set to be the next heavyweight graphics upgrade reason? More importantly, might this possibly keep the anticipated price drop for the previous vid card generation at bay? The horror... On a more positive note, it is good to see designers anticipating problem exploits - no one likes a mutiplayer cheater." H : Sorry; it's a dupe. My fault.
For the life of me I can't figure out the connection between a client's FPS and his ability to perform unreasonable jumps in the game world as generated on the server. But what the hell, the devs pro'lly know what they're talking about.
It has to do with dynamically calculating the height of the jump and the rounding of floating point numbers during movement (which is calculated per frame). It's not that the jumps are unreasonable, in fact either everyone should be able to perform the jumps or no one should, it's a matter of 1 unit (whether the floating point number is rounded up or down determines whether or not you make it).
More to the point though (on FPS limiting) - can someone with GPU/DirectX internals knowledge explain why doesn't a game (or a GPU) that realizes its churning more than the 30fps that the human eye can discern dynamically (and automatically) enable FSAA (AntiAliasing) and/or AF and use the spare GPU power to enhance picture quality, then dynamically stop doing so once you need the power to keep up with a playable 30 FPS?
30 fps is far below what a human eye can discern, it's simply close to the lowest level that the human eye can see as fluid motion. Besides that, dynamically enabling FSAA at some cutoff point and then disabling it when it falls below another cutoff point would just mean a lot of switching. FSAA can have a drastic effect on framerates, and can cause framerates to drop much more quickly than they normally would in intensive scenes. The numbers wouldn't be consistent on everyone's machine (ie if I cut to FSAA at 60 fps, the framerate may drop to 20 fps or 40 fps depending on how well my system can handle it), anyway.
Other than that, FSAA isn't a feature that is universally liked, especially by those that prefer gaming at high resolution. FSAA at TV resolution is almost an unquestionable benefit, but FSAA at 1280x1024 or 1600x1200 is probably unwanted, since it tends to look like someone whiped Vasoline all over your monitor rather than cleaning up the lines in the game.
Seems like a MUCH more efficient way to use your GPU. At LP's I'd always switch off FSAA&AF even when most of the time I'm pumping 70fps, just to keep above 30 on those few tight&insane spots.
The real question is, what kind of framerates do you have consistently (like averages) with FSAA enabled? If it's hovering at 30, you're not going to have a good time going back and forth between FSAA enabled and disabled.
The things that are most likely to be worked on are extending the viewing distance and model complexity while maintaining a decent (60fps or so) framerate, regardless of what features are enabled. Rather than messing with the features enabled (since features should stay on or off), they'll change the detail of what's drawn on the screen. This has already been done to a minor level on the Unreal engine, and has been done on a handful of other titles to an even greater extent (first game that comes to mind is Dark Reign 2, though it would seem very few people played that). Half-Life 2 has promised a lot of these types of features, but since it's been delayed we'll have to wait and see.
-PainKilleR-[CE]
Pretty sure he said game tic, not frame rate?
The difference is the ai/physics/game rules will be updated at 60hz, whilst the rest(sound video) could be updated at a different rate.
The benefits for the fixed rate are a few. It is almost very similar to having your elapsed time calculations between frames being fixed.
The biggest advantage of it is in terms of game play. You can be garaunteed that most players will see a very similar game world each time they play. For example imagine there is a slide which the character has to run down. Then there is a big hole in the ground which the character has to jump over onto a platform past this hole. With a fixed tic rate you can place the platform at such a place that the jump must be timed just right. That is the player will not make the jump unless they jump right from the end. But with a variable tic rate you can not be sure that the player will be able to be at that exact position. Time may move too fast and they may miss the perfect jump location.
Another important reason to have a fixed tic rate is so that motion looks smooth. There is no point in having all animations being updated 300 times a second in one room, then pause for a quater of a second. It would look jerky.
It can simplify calculations. Allthough this doesn't really matter too much for someone writing a fairly complex physics simulation like they are. But making sure every thing is done within 1/60th of a second is simplified if you know that rate is fixed. If there is time left over you can do some preprocessing for the next frame if you want.
Having a slower than maximum tic rate can also allow you more time to render a purty scene, calculate nice interactions with the world etc.
Have fun!
http://www.holepit.com/
http://ucguides.savagehelp.com/Quake3/FAQFPSJumps. html
No, that's pretty much the problem.