now DOOM3's frame rate is capped,why is that?
Author
We checked with John Carmack himself about why DOOM 3 will be hard-capped at 60fps in the renderer, and he had this to say:
"The game tic simulation, including player movement, runs at 60hz, so if it rendered any faster, it would just be rendering identical frames. A fixed tic rate removes issues like Quake 3 had, where some jumps could only be made at certain framerates. In Doom, the same player inputs will produce the same motions, no matter what the framerate is."
so does this mean the Q3A engine can draw more frames on faster machine than on slower machine with the same user input;while the Doom3 engine synchronizes the input and drawing part?
It sounds like an ugly hack - why would you tie the physics/movement/etc to the framerate? I thought we''d have gotten past this by now.
For those of you who haven''t played alot of q3, there were things players with higher framerates could do that people without them couldn''t. THe game was timed and all, and player movement wasn''t actually faster, but jumping was. Players with faster framerates could jump into places they weren''t supposed to be able to jump, where people with normal framerates couldn''t make the same jumps, and had to go about finding the correct way to get to certain spots. It was an unfair advantage.
thats dumb, why in the world would framerate determine how high somone could jump, the physical model should remain in a constant world of units reguardless of how fast the image is drawn or the physics is proccessed, maybe it has somthing to do with modyfying the physics based on varying framerates to give a constant idea of motion, but in that case why not just drop some frames *dont render but proccess the underlying physics*
seems strange to me.
Raymond Jacobs,
www.EDIGames.com
www.EtherealDarkness.com
Voice your discontent! help stop the flames!
seems strange to me.
Raymond Jacobs,
www.EDIGames.com
www.EtherealDarkness.com
Voice your discontent! help stop the flames!
I think John Carmack is saying that the simulator/physics maximum simulation speed is equivalent to a 60 fps update. In other words if you could draw 61 or greater fps, then at least one of your frames will be identical to a prior frame (and hence no need to redraw it).
[edited by - Cosmic314 on October 23, 2003 4:32:12 PM]
[edited by - Cosmic314 on October 23, 2003 4:32:12 PM]
Actually for a single player game tying physics to framerate is one of the best options together with Carmack's option AFAICS. Albeit one where you have to be really carefull of corner cases of physics simulation behaviour, which are hard to QA ... as Q3A prooved.
If you have fixed ticks for physics simulation, but want higher fps you have to use extrapolation or interpolation to determine how stuff moves in the extra frames. Extrapolation can be wrong, in which case you get jittery motion ... and interpolation forces you to delay rendering by 1 tick, causing extra latency in rendering. Neither of those are terribly attractive options.
Given Doom3's gameplay a 60 fps maximum seems a reasonable compromise.
For the multiplayer mode he can safely use extrapolation though AFAICS, the client side prediction used to correct for network latency usually tries to predict well beyond 1/60th of a second ... so if the extrapolation causes artifacts those will already be present anyway.
[edited by - PinkyAndThaBrain on October 23, 2003 4:41:36 PM]
If you have fixed ticks for physics simulation, but want higher fps you have to use extrapolation or interpolation to determine how stuff moves in the extra frames. Extrapolation can be wrong, in which case you get jittery motion ... and interpolation forces you to delay rendering by 1 tick, causing extra latency in rendering. Neither of those are terribly attractive options.
Given Doom3's gameplay a 60 fps maximum seems a reasonable compromise.
For the multiplayer mode he can safely use extrapolation though AFAICS, the client side prediction used to correct for network latency usually tries to predict well beyond 1/60th of a second ... so if the extrapolation causes artifacts those will already be present anyway.
[edited by - PinkyAndThaBrain on October 23, 2003 4:41:36 PM]
I''m having problems with my frameRate scaling too.
I use a Performance timer to get the frameTime at the end of every frame, but when the the frameRate is high, the timer is not high resolution enough and the frameTimes are too discrete, and the player starts running slightly faster. For some reason this didn''t happen on older versions of my game, but the engine code is unchanged. I assume it''s just the optimizations I''ve put in lately.
What could be happening?
I use a Performance timer to get the frameTime at the end of every frame, but when the the frameRate is high, the timer is not high resolution enough and the frameTimes are too discrete, and the player starts running slightly faster. For some reason this didn''t happen on older versions of my game, but the engine code is unchanged. I assume it''s just the optimizations I''ve put in lately.
What could be happening?
quote:Original post by EDI
thats dumb, why in the world would framerate determine how high somone could jump, the physical model should remain in a constant world of units reguardless of how fast the image is drawn or the physics is proccessed,
Rounding errors and floating point inaccuracies can easily creep in over many iterations (ie, the hundreds of frames that can be processed in a few seconds) meaning that even clock-time based simulation will suffer from slight variations at different update amounts.
While i''m not totally sure I agree with this, there must be a strong technical reason for this. I doubt Carmack would make such a decision lightly.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
