Archived

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

Jenison

Caping FPS...why do it

Recommended Posts

you cap the framerate for consistency and predictability. people with higher framerates will get more updates per second, and in a game like quake, this would result in people with higher framerates being more accurate.

--michael

Share this post


Link to post
Share on other sites
Yeah, and for a simple physics system, consistency is the key. For example, lets say you are moving with a velocity of V. And you are undergoing a constant acceleration in the opposite direction. If your frame time is large, you''ll follow the V vector for a longer period of time before the acceleration will affect it. The shorter your frame time, the more times your V vector will undergo a transformation by the acceleration. Like the previous poster said, it''s more consistent and predictable.

Share this post


Link to post
Share on other sites
In a simple game, the FPS-variations will cause faster computations, which means everything might go freaking fast! But in most games, there are some kind of transformation so that the speed of all computations are fixed. But fixing the FPS rate and use it as a "global timer" in the game is a lot easier, and the visuality won''t be worse because of that.

This is a topic to be experimented around. Perhaps you need as high FPS rate as possible, dunno why...

Share this post


Link to post
Share on other sites
People notice fluctuations in frame rate more than they notice slower frame rates. It is better to run your game at 40fps solid that having it vary around 50-60fps.

Trying is the first step towards failure.

Share this post


Link to post
Share on other sites
one reason to cap the fps is human eyes and brains cannot handle more than 120 different images a second. having a framerate higher than this (as i''ve seen in some games) is just a waste of processor.

as mentioned before, another important reason to limit the fps is to free up resources for other things. i think anything over 50 fps is excessive, and really, what is the difference between 60 and 70 fps, or 95 and 115? could you really tell the difference? i think that if a person really can tell, and furthermore really cares about such differences your game is fundamentally flawed; the player is so bored they are worried not about exploring and experiencing the game, but about how many pictures are displayed per second.

i agree that too low a framerate can hinder a game, but that is not the topic here. i don''t see much of a problem with an upper bound, as long as it''s reasonable. just think, if you cut your framerate in half you might be able to push 25-50% more polygons per second, if you are efficient.

<(o)>

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
According to "The Desktop Multimedia Bible"

"The average viewer perceives animation as more than a series of individual frames at around 15 frames per second."

Here are a few familiar fps reference points to consider:

Motion pictures operate at 24 fps.

NTSC television (North America/Japan) 30 fps b/w - 29.97 fps color

PAL television (Europe/Brazil) 25 fps

So if you''re churning out 50-60 fps you''re doing pretty good...

Share this post


Link to post
Share on other sites
If you want a reason try playing an old dos game. Chances are you die in less than a second and wont be able to tell why. No matter what you use for accuracy, eventually your game will be unplayable if you do not cap the FPS. (and some people might want to still play it years down the road. Sort of like my original copies of space quest, police quest, kings quest, black cauldren, etc. Can''t play them anymore without something like moslo.)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The frame rate of the display (how fast teh screen updates) should not be related to the frame rate of the game loop (how fast physics, characters, & bullets move).

Share this post


Link to post
Share on other sites
You want let your game loop update as fast as it can and keep track of elapsed time since the last
frame to determine how much your objects should move. If an object has an xvelocity of 30 pixels/sec
and only 20msec have elapsed since the last game loop execution, the object x position would change
by 30 * 0.020 = 0.6 pixels. The same code running on a slower machine that only executes the loop
every 80msec would move the object 2.4 pixels.

There are articles on this site about this topic. The general consensus is to not lock the frame rate.

Also, the reason movies & TV can get by with 24 and 30fps is because of motion blur. Thats why
early stop-motion animation running at 24fps doesn''t look smooth no matter how small the movements.
The individual frames aren''t blurred.

I had a wrestling game on the PS1 that let you switch between 30 and 60 fps. It was noticeably
smoother at 60.

Share this post


Link to post
Share on other sites
When I first started programming I thought that capping the FPS would be a not too bad idea. Now I am using time based movement, and its soo much better! Its not that hard to do, and it looks soo much better! Trust me, don''t cap your framerate!

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Motion pictures operate at 24 fps.

NTSC television (North America/Japan) 30 fps b/w - 29.97 fps color

PAL television (Europe/Brazil) 25 fps



TVs rely on motion blur to give a smooth motion effect, as do cinema screens. Computer monitors dont rely on this, as computer users want a clear crisp image on their screen that doesnt blur when something changes.

Share this post


Link to post
Share on other sites
Use v-sync-ing to cap your FPS at the monitor''s refresh rate to avoid tearing. Use the extra CPU time to improve image quality if you''re using any kind of LOD rendering, or to give the AI more time to "think," etc.

Share this post


Link to post
Share on other sites
If you''re just limiting the framerate, then it will sit doing nothing until it is allowed to continue onto the next frame. If you''re using threads and want to limit the fps and give more time to a thread that handles AI or whatever, you prolly wont get any speed increase out of it without having the 2nd thread handled by a 2nd cpu, and even then it would be better to leave the framerate uncapped, as the other cpu would just be sitting idle for no reason.


Just max out the framerate with your program. Id much rather an fps that jumps between 60fps and 200fps than one that is locked at 30fps.

Share this post


Link to post
Share on other sites
Maximus: I don''t quite understand your reasoning. I don''t think anyone is suggesting that games be capped at anything as low as 30 fps, but if a user''s monitor refreshes at a maximum of 75 or 80 mhz and their graphics card/cpu are moving the 3d engine at some ridiculous number like 200fps that''s over 100fps of wasted cpu time. The truth is, as long as you''re not making a fast twitch game like Quake, you should be able to get along just fine with 40 - 50 fps. Like someone said earlier in the thread, a _stable_ frame rate is much more important than the max fps you can get out of the engine. Max fps is something that should only ever be important to people like hardware reviewers, manufacturers, and hardware aficionados because they have a reason to be benchmarking the hardware.

Also, your understanding of how multithreading works on a single processor system seems to be a little off. When one thread waits for a while with no work to do, the system scheduler gives the remaining CPU cycles to any other threads available. For example, even on a single processor system, people that are compiling the Linux kernel with gcc are told to use the compiler switch that tells gcc to use multiple threads. This results in, very often, _over_ a 2x speed increase. Whenever one thread has to wait, for any reason, the other threads are given that threads share of the CPU time.

There are plenty of thing that those extra CPU cycles can be used for. Adding more detail or complexity to the scenes; performing more AI calculations; streaming media, that will soon be needed, from your harddrive (or the net) into your game engine; text-to-speech; speech recognition; etc. There is no end to the number of things that you can add to a game, or improve in a game, if you have spare CPU cycles to use.

Of course, the trick would be to design your system so that you could regulate the fps of the engine without wasting more CPU cycles than you gain. I''m not saying that''d be easy.

-Daedalus

Share this post


Link to post
Share on other sites
I''ve been lead to understand that the best approach is to run your physics (physical model, including collisiong detection) engine at a constant speed (I''ve heard of several games...not sure which ones precisly...that run their physics at 15fps [possibly some driving and/or flying sims maybe even a FPS]), whilst updating their screens as often as possible based on interpolated values from the physics engine. Apparently this can help solve some instability issues in the physics as well - constant time steps in transient (time dependant) physical simulation usually help (certainly for Finite Element Analysis).

Share this post


Link to post
Share on other sites
Slightly off topic, but still interesting (I think ):

When you see a movie at the cinema, every frame is displayed twice. This makes the image appear more solid than if each frame was displayed for twice as long.

The reason they can get away with that is because of motion blur so don''t skip frames

One problem of a non capped fps is that sometimes another part of the computer might be doing something processor intensive every now and again. I remember playing Quake, and every half hour or so, the game would suddenly slow to a screeching halt and once it came back, I was on the other side of the map

Also, to people saying that you can''t notice above 30fps (which is about what the eye sees at), then make yourself a program which runs in full screen, clears the back buffer, fills the primary buffer with white and then set it to flip at 60hz. Tell me if you see black and white or grey.

Having physics running at 15fps and independant to the graphics is a good idea, if it is done properly. Just you have to be careful that it doesn''t break down if something happens and the physics is forced to slow to 10fps.

Trying is the first step towards failure.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It all comes down to taking the FPS into account. If you run in a loop and do your calculations and display you will depend on the CPU and your game will run att he speed of the frame rate. If, however, you do all your calculations taking in account how much time has passed since the last calculation you will do just fine. And if the computer can give you 10000 fps so be it. As long as you got time do do all those calculations.
I think aperfect solution is to do your calculations. Then draw. Just use time elapsed in the calculations.
Then fast systems will run at high FPS. Slow at low. But they will have the same thing on the screen at any given time.

Share this post


Link to post
Share on other sites
It all comes down to taking the FPS into account. If you run in a loop and do your calculations and display you will depend on the CPU and your game will run att he speed of the frame rate. If, however, you do all your calculations taking in account how much time has passed since the last calculation you will do just fine. And if the computer can give you 10000 fps so be it. As long as you got time do do all those calculations.
I think aperfect solution is to do your calculations. Then draw. Just use time elapsed in the calculations.
Then fast systems will run at high FPS. Slow at low. But they will have the same thing on the screen at any given time.

Share this post


Link to post
Share on other sites