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.
From the repost-from-Thursday-dept.
Don't worry, it was only the single biggest-interest Games story in weeks. Noone will have noticed.
erroneous: look me up in a dictionary
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.
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?
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.
ATI? nVidia? Microsoft? Anyone?
-
Sweet!!!!! Thank you Hemos!
Can't slashdot cap dupes? ;)
-K
Redundant for pointing out a redundancy... aww.
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.
while (true)
update_player_position()
render_frame()
done
This calculates the details and spits out the frames as fast as the graphics-card can draw them. The problem is in update_player_positions() - Computers are of course finite precision. Consequently round-off errors occur as soon as you approximate real world physics. Since numerical errors are cumlative, updating the position every frame can produce different results depending on frame-rate when you are close to a round-off boundary. To clarify this a bit - consider the following example - a player starts falling from rest at 300 units/s^2. We use the following formulaes (assuming accelaration constant):
- v_cur=v_prev+a*delta_t
- d_cur=d_prev + v_prev*delta_t+
(v_cur-v_prev)*delta_t/2
(classical newtonian physics, etc). We use integers to store v and d and round rather than truncate.If we calulcate his speed five times over the first second, we get the following list of speeds and distances moved:
time (s): 0 0.2 0.4 0.6 0.8 1
speed (units/s): 0 60 120 180 240 300
distance (units): 0 6 24 54 96 150
and at 6Hz
time: 0 0.167 0.333 0.5 0.667 0.833 1
speed: 0 50 100 150 200 250 300
dist: 0 4 17 38 67 105 151
The cumulative round-off error creates a difference of 1 unit in the final position. This is because, even though we use the real clock, when we sample it and thus the fractions in the calculationa re influenced by the frame rate.
One possible solution is to do the calculation at a constant. This ensures consistent if not nessecarily correct results (150 is the correct distance in the above example, but lokcing the caluclation to 6 HZ would give and incorrect result). Note that to do this properly you need to completely seperate calucaltion from display, i.e. regardless of frame-rate, calculate position 60 times a second, i.e.
Thread 1:
while (true)
update_player_position()
wait (1/60 s)
done
Thread 2:
while (true)
get_data()
render_frame()
done
Exercise 1: Add suitable locking to deal with race consdition between get_data and update_player_position
Exercise 2: Rewrite as non-threaded.
Exercises to submitted in Logo
The decision to limit display rate to at most 60 fps is to prevent jerky display artifiacts. Since they are only calculating stuff at 60Hz, displaying at some higher number involves duplicating a percentage of the frames - which is not visually smooth. Other solutions to the display problem are possible, but not all are suitable for games. In simulations, for instance, it is possible to lag the display cycle a few steps behind the calculation loop and use interpolation techniques to approximate the inter-frame motion.
about the only way you're going to get 100fps in most modern games is to shut off all graphical detail and play in about 800X600. if you're playing with that level of detail, there's no real reason to play any of the new games. quake II, halflife and all the mods for them will give you everything you need.
The World's Worst Webcomic!