|
hotrodx
Squire
43 Posts |
 Posted - Jan 06 2005 : 12:41:16 AM
|
Time-based movement computations without any form of VSync or framecapping leads to excessive framerates that are best left to benchmarking. Even without VSync, Quake still tries to sync it's framerate to the monitor's refresh rate. It won't go to gazillion FPS unless you are benchmarking.
"a game that runs at 60 FPS for 80 percent of the time but sometimes drops to 15 FPS during certain situations is worse than a game that runs at 20 FPS for 80 percent of the time"
A lot of 3D games are actually like the former, Quake included. When you get to places where there are more detail or more enemies, the framerate drops. The high-profile game I've seen that forces framecapping would be HALO for the PC. If you turn off the framecap, it'll behave like the latter.
But say, HALO has framecaps still ON at 30FPS, but there is still too much detail in a particular scene (or you really have a crappy vidcard) that it still drops at 15FPS, it is unecessary to force the whole game to run at 15FPS just so you can have a *consistent* framerate when certain other scenes can run relatively faster.
|
 |
|
|
2dcoder
Knave
83 Posts |
Posted - Jan 06 2005 : 12:51:16 PM
|
"#5. You can implement frameskipping without resorting to time movement calculations. Playstation (and other consoles) emulators do this. The emulators do not mess up with the movement values by factoring time delta (it's the emulated processor's thing), yet they can skip frames if your PC cannot handle the frame."
One of the options I've learned to implement in my code is timebased movement combined with fps limiting. This way if a game is running on an older cpu or crappy card, the user can configure it run at a constant 15,20,30,60 fps, or refresh rate, while the internal calculations are still timebased. For 3D games, it's ok to jump around the frame rate because the object/world movements are usually based on a real world clock running 1000 times per second. For 2D apps a stutter or hiccup is very noticeable and your characters can seem to jump/move a very far distance if using time based movement. That's why even with a locked frame rate & time based movement, you still want to make sure the distance to update per frame never gets too far, that's where limiting comes into play. When limiting is in effect the movement will not get any greater, the frame rate will slow down.
I use time base movement for everything, but in pixel terms and capped frame rates, this is my general approach to limiting:
Game loop is running at 60fps so time_delta=1.
Loop drops to 30fps so time_delta=2.
Loop drops to 15fps so time_delta=4.
Loop drops <15fps but keep time_delta=4 because we don't want the objects to move too great a distance per loop. Otherwise objects could miss collisions, go through tiles, etc. The end result is slow motion for a while until the frame rate speeds up. :) I'm fairly sure this is how alot of 2d games on consoles are coded. Remember all those shooters a while back that had the dreaded "slowdown"? :) LOL... |
|
|
|
|
Arcade style shooter
