Archived

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

Framerate question

This topic is 5310 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

In my game I''m using a discrete fixed amount of time for updating my game''s physics. I now have a choice of limiting my game''s graphical framerate to this value, or allowing it to run faster (independent of the physics). Is there any advantage to allowing it to do this? I mean, what''s the point of displaying a frame twice if *nothing* changed between the two frames? I''m leaning towards locking the screen updates to the physics timestep unless someone can provide an example of how it would be beneficial not to. Note: Please no suggestions on unlocking the physics timestep. There''s too many good reasons NOT to do this.

Share this post


Link to post
Share on other sites
You are right, it doesn''t make sense to update the screen twice if nothing has changed. On the other hand, it doesn''t hurt (except in some cases).

The drawbacks of of locking the framerate are these: on a very slow computer (the framerate is lower than the physics rate), the game will run in slow motion. On a very fast computer, a limit on the frame rate would cause nothing but disappointment.

Perhaps the best thing to do is to run a benchmark that figures out the optimum timestep/framerate for the target computer and lock everything to that value.

Share this post


Link to post
Share on other sites
quote:
Original post by Jambolo
Perhaps the best thing to do is to run a benchmark that figures out the optimum timestep/framerate for the target computer and lock everything to that value.


I thought of this, however for what I'm trying to do that won't work. I'm trying to keep it entirely deterministic. If I use a scripted event that relied only on recorded input I couldn't guarantee it being played back identically on every machine. (Yes, you can get quite good approximations for simple behavior like a ballistic projectile, but the more complex the script, the more likely it will fail at some point on some machine due to variations in the time step causing discrepancies in physics calculations. You'd literally have to test every script under every possible time step value. Yuck.


quote:
Original post by Jambolo
The drawbacks of locking the framerate are these: on a very slow computer (the framerate is lower than the physics rate), the game will run in slow motion. On a very fast computer, a limit on the frame rate would cause nothing but disappointment.



I think the best solution is to let the graphical framerate run slower than the physics if necessary but not faster. This would allow slower PC's a fighting chance. Of course this only helps if the PC is choking on the graphics and not the physics.

Why would a framerate limit cause disappointment on a fast PC? I think it would be better limiting it because it guarantees a level of consistency no matter what machine you play it on. A game that updates the world 60 times per second running at 120fps on a fast machine wouldn't play any better or look better than the same game updating the world AND screen at 60 times per second, would it? If you mean people would be disappointed because they're checking benchmark figures and saying "Hey, my 85Ghz Dual Pentium 8 overclocked to 115Ghzwith liquid nitrogen cooling only runs this game at 60fps, the same as your Celeron 500, What gives?!!!" then I can live with that. Those people should not be playing games anyway. They should be putting black lights under their cars or lifting weights or some other self absorbed competitive activity.

Edit: How does refresh rate play into this? Is it better to try and sync your game's graphics to the screen's refresh rate, or just ignore it?


[edited by - SpaceRogue on June 3, 2003 10:19:53 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by SpaceRogue
Why would a framerate limit cause disappointment on a fast PC? ... A game that updates the world 60 times per second running at 120fps on a fast machine wouldn''t play any better or look better than the same game updating the world AND screen at 60 times per second, would it?



Let''s get real, 60 fps on a low-end machine is not going to happen if you want reasonable graphics, gameplay and physics.

The problem is that your frame rate is determined by the slowest acceptable machine. Let''s say that you want people with 500 MHz Celerons to play your game and the best that machine can do is 20 fps. Now, 20 fps is a playable framerate, but anyone with a decent machine is going to say "this game sucks -- it only runs at 20 fps".

Another option is to cut way back on features for a slow machine. Then you could run the game at 60 fps on a slow machine at the expense of graphics and whatever else you can turn off. Just start turning off features until the frame rate is up to 60 fps or there is nothing left to turn off.

Share this post


Link to post
Share on other sites
Refresh rate is important, if i turn vsync off and let an application refresh at >60hz then a sort of jerky effect occurs, it sounds odd, maybe its just my monitor... ah well theres always vsync... yes... hrm... /me toddels off deleriously

Share this post


Link to post
Share on other sites
I would advice against unlocking displayrate and physicsrate. The examples discussed upto now are relying on integer factors for physics:display, like physics at 60, display at 120.

With a coupled system you get a constant rate of 60 fps as the physics don''t run faster or slower.

Unlock it and the fractions the display is faster or slower add up so you get an extra frame, displaying the same content every now and then, or drop a frame, jumping ahead.

Now with 60 fps this is not that critical but why accept the evitable and go for the worse scenario

Share this post


Link to post
Share on other sites
I think the best solution would be to run the renderer asynchronous from the physics engine and then use interpolation to "fill in the blanks" between the frames generated by the physics engine. (You could use prediction as part of the interpolation process, but I don''t think the lag of 1-2 extra frames it gonna be that noticable and not worth the extra work.)

This is actually very similar how many multiplayer games work where the data is refreshed at a lower rate, but since you won''t need prediction it will be much easier to implement.

Share this post


Link to post
Share on other sites