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.
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?
-
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.