Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

digitalfreak

now DOOM3's frame rate is capped,why is that?

This topic is 5448 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
He''s right, rounding errors are no joke..

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!