Maximus,
I see my mistake now. I should really have said that if the target framerate is X FPS then you only have 1/Xth of a second to update the game''s state without diverging from that framerate. A steady framerate is better than an unsteady framerate. It''s harder to maintain a steady 120 FPS than it is to maintain a steady 30 FPS.
Caping FPS...why do it
If you want your physics and AI to run the same on all systems, feel free to run those only 30 times a second or so. Leave the framerate itself uncapped.
If all people wanted from games was 30fps, we''d still all be using TNT1 or lesser video cards. A TNT1 can run Quake3 on highest detail with a resolution of 1024x768 under 32bit colour and still go around 50fps.
If all people wanted from games was 30fps, we''d still all be using TNT1 or lesser video cards. A TNT1 can run Quake3 on highest detail with a resolution of 1024x768 under 32bit colour and still go around 50fps.
In my opinion, I don''t think its wise to update the state of the physics model after every graphics frame... you may ask why... the answer is the rounding errors at high framerates, as pointed out by Terran Fury et al.
I think its much better to conduct this based purely on time. This way you can have the simulation effectively running at 30fps (just a number I pulled out of my @rse for the sake of example), and the graphics system is free to pump out whatever it can manage.
That said, this scenario does work better when multithreaded, as it removes the need to test for the time passed before updating the physics model... you can do the update, then sleep the thread for X amount of time. For accuracy''s sake, you should sample the actual amount of time between updates, as the sleep time is very likely not to be exact.
I find this has a nice neat structure (everything in its own atomic loop), and can be tweaked around for better render speed, or better physics accuracy, or more time for AI (everyone seems to love that idea for some reason
), or whatever.
Plus those all freaky people out there with SMP systems get the nice performance boost that they payed an arm and a leg for
I think its much better to conduct this based purely on time. This way you can have the simulation effectively running at 30fps (just a number I pulled out of my @rse for the sake of example), and the graphics system is free to pump out whatever it can manage.
That said, this scenario does work better when multithreaded, as it removes the need to test for the time passed before updating the physics model... you can do the update, then sleep the thread for X amount of time. For accuracy''s sake, you should sample the actual amount of time between updates, as the sleep time is very likely not to be exact.
I find this has a nice neat structure (everything in its own atomic loop), and can be tweaked around for better render speed, or better physics accuracy, or more time for AI (everyone seems to love that idea for some reason
), or whatever.Plus those all freaky people out there with SMP systems get the nice performance boost that they payed an arm and a leg for
I don''t agree with the people who don''t max their framerate here. I always do, even if it is a rather high limit (10ms per frame for instance). And even if I don''t have anything else to do : just Sleep() until the next frame.
The reason is, particularly in windowed mode, YOU ARE NOT ALONE ! There are other apps running on the computer and if you try using all the resources available, there will be none left for the other programs.
You must use as much as you need, but not MORE.
Sure, Windows is a preemptive multitasking system, so other apps won''t slow to a halt even if you don''t cap your framerate, because they run in other processes. But there are other applications that do things when the machine is idle. None of these will run if you don''t cap your framerate, using valuable resources for absolutely nothing, since most frames won''t get displayed. A good program must be a good multitasking citizen.
And by the way, it''s easy to retrieve the screen refresh rate and to cap the display based on this value.
--
New feature - Windows users, press ALT-F4 to launch the IQ test.
The reason is, particularly in windowed mode, YOU ARE NOT ALONE ! There are other apps running on the computer and if you try using all the resources available, there will be none left for the other programs.
You must use as much as you need, but not MORE.
Sure, Windows is a preemptive multitasking system, so other apps won''t slow to a halt even if you don''t cap your framerate, because they run in other processes. But there are other applications that do things when the machine is idle. None of these will run if you don''t cap your framerate, using valuable resources for absolutely nothing, since most frames won''t get displayed. A good program must be a good multitasking citizen.
And by the way, it''s easy to retrieve the screen refresh rate and to cap the display based on this value.
--
New feature - Windows users, press ALT-F4 to launch the IQ test.
quote:Original post by Fox Mc Cloud
And by the way, it''s easy to retrieve the screen refresh rate and to cap the display based on this value.
No need to even retrieve it... SwapBuffers wont return until it has actually swapped the front and back buffer, and you can set it to swap on the vertical refresh, or immediately.
By the way, the target framerate doesn''t have to be a fixed number. You pick the highest framerate that still produces steady motion.
AP - reasons for doing it vary - often to do with avoiding large rounding errors associated with updateing physical variable more times than neccessary - or sometimes to ensure equality in multiplayer games.
What you can do (and is often done) is to predict what the next state will be, then interpolate a frame based on that information - visually this will give the appearence of a smoother movement, whilst allowing the physical simulation to run at it''s own pace for whatever reason.
What you can do (and is often done) is to predict what the next state will be, then interpolate a frame based on that information - visually this will give the appearence of a smoother movement, whilst allowing the physical simulation to run at it''s own pace for whatever reason.
NickB,
So you update the world at fixed intervals to avoid rounding errors and interpolate in-between frames to get smooth animation. This is only necessary if your variables'' values depend on the values obtained at previous frames. Why is integrating values better than calculating them directly?
So you update the world at fixed intervals to avoid rounding errors and interpolate in-between frames to get smooth animation. This is only necessary if your variables'' values depend on the values obtained at previous frames. Why is integrating values better than calculating them directly?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
