30/60 fps? why?

simple question:

why do games lock at 60 or 30 fps, why not inbetwen? 40fps? 50fps? is there something am overlooking? maybe with displays nd so on?

some info please ...

personally i know 60 feels alot smoother though but 30 can be rather sluggish sometimes ...

In fullscreen mode, the frame rate is kept in sync with your monitor's refresh rate. This is usually 60. If it can't manage 60, it jumps to an integer division of the refresh rate (60/2 = 30, 60/3 = 20, and so on).

Jibb

so you'd consider coding a game at say 40 or 50 fps to being a bad idea ? or would it just force it to 30 ?

On a 60hz monitor in full-screen it'd definitely drop to 30.

So yeah, that's probably not a good idea. Out of curiosity, why do you want to do less than 60? Do you not use time_step to make your game fairly framerate-independent?

Jibb

well i guess it has to do with my developer pc, the game makes heavy use of shaders so it almost always drops frames, not many GS games have given me a stable fps when using alot of shaders, though i do run other games, farcry2 and so on considerably well...

understanding this point i guess it makes no sense to code for 30fps though, also regarding time_step:

Hmmm... I'm not sure I understand what MrGuest is saying, but I would definitely use time_step for things like speed. It does, unfortunately, get a lot more complicated when it comes to acceleration, especially when acceleration depends on current velocity -- these are more difficult to make framerate independent, but it can be made close enough.

As an example, the friction (and thus acceleration) of the cars' wheels in KarBOOM depend on the surface type, a graph, and the speed of the wheels relative to the surface beneath them. At a high framerate this gets re-calculated much more regularly, resulting in slight differences in how long a car can be turning at full speed before spinning out. This kind of issue could be removed completely by targeting a specific framerate and just having the whole game slow down if it gets lower than that (by not using time_step), but that'd be bad for players like Redeemer whose framerate drops below 20fps quite regularly because his computer is very slow (and because of that he'll get an early version of the next update which will include graphics options so he can tell me what kind of framerates he gets ).

Do you have a link to the thread you quoted from? Found it. "mouse_force" automatically accounts for framerate.

Jibb

but maybe its best to not use time_step for stuff that isnt important such as visual effects? sprits? exlposions?

at a low fps i assume you'll just see less of the effect right ? but is that necessarily a bad thing?

http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Main=44154&Number=365799#Post365799

I agree that effects that don't affect the actual game logic won't necessarily need to be framerate independent. Something like interpolating between two camera positions, for example, may not need it. But consider this example:

An explosion happens right in front of the player, filling the screen with large particles. Even though they're simple, there's a lot of overdraw, and older machines can be quite significantly affected by such circumstances, even though the explosion might have no effect on the framerate when viewed from far away. The explosion might normally only last a second, but if framerate drops to a third of what it normally is the explosion will last for 3 seconds if it doesn't take advantage of time_step, when the player really just wants the explosion out of their face ASAP.

That's kind of an exaggerated example, I admit. And here's a counterexample: I recently changed the rate at which particles are created during a drift/burnout to be framerate dependent, because if someone's framerate is dropping below 60, it's probably a good thing if less particles are being created. So I guess it depends on exactly what you're dealing with. But with good use of time_step, you should have no problems with settting your fps_max higher than what you normally achieve on your own PC.

And perhaps you need to look into some optimisation, but I imagine that's a much bigger task in your project than in mine

Jibb

hmm, still a little confused on the topic, okay, so this example:

i have a sprite that removes when its alpha hits 0, and i say:

alpha -= 10 * time_step

with low fps this allows the sprite to be removed in the same amount of time it would take on normal fps ? right ? but to be honest, wouldnt it make more sense to just let the effect remove faster and thus stabilize the framerate quicker ? such as using time_frame ?

or am i looking at it all wrong ?

ok after some tests am getting the basic concept, its a bit tricky to know what scenarios its best used with but now i get it, so i'll lock the game at 60 fps then =]

I believe in most game, there is an option to "sync with monitor refresh rate" or something like that, it's only purpose is actually just to avoid screen tearing. If you disable the option, the game will run as fast as it can and the fps will vary. And it's enabled, the game fps will be locked on to 30 or 60 fps(which one is closer to the game's actual fps.

To be quite fair, this is something you should've opted at the START of your project.
Trying to iron everything out for 60 fps, while it wont ever run that, or the other way around is just incredibly time consuming, time better spend on gameplay

I'm writing this not to kick your shins, but so anyone reading through this will take it into account straight away, saving them from unneeded work.

oh dont worry, it didnt take too long but yes i agree

I think the only reason for frame rates of 30 or 60 fps is the american analog television system NTSC (approximately 29.97 FPS).
Perhaps most game developers thought that if 30 FPS is fast enough for television, it also must be fast enough for video games. Later when the graphic cards became faster they doubled the frame rate to 60 FPS.

Because your graphics card will live longer and consumes less energy when you lock your framerate. Why do you want to torture your graphics card with for example 120 FPS, even though 40 FPS is fast enough for your game?!
The framerate you use for your game depends on the type of your game. Only if you use very fast movements in your game (for example in racing games) you should use high frame rates.

i dont think he was saying it needed to run above 60, he was saying why have it less, based on the amounts of detail you want in your game, sometimes achieving a stable 60 fps will be problematic, normally 60fps games boast some pretty crude effects, or maybe thats just my opinion?

but has said, if i lock it to 40, the fps would definately drop to 30 on most monitors? i think 30fps is too slow, i'll do what i can to keep a stable 60 without ruining detail ..

No, my first reply has the answer, and Bart elaborated with screen-tearing.If you aim for less than 60 fps you'll get 30 fps or lower in fullscreen. The fact that 60 fps is a problem implies that the game isn't framerate independent, which I was just confirming with him.

Jibb

No. Only the MAXIMUM framerate cannot be higher than the monitor's refresh rate.
But you can lock the framerate of your game at any fps value between 1 and 60!
In my game I have locked the framerate at 50 fps (fps_min = 49; fps_max = 50;).
So I always have a framerate of 50 fps in fullscreen mode.



When I lock the framerate at 70 fps, and my monitor can only manage 60 fps, then the framerate of my game is reduzed to 60 fps.

fps_min don`t set the framerate, it locks only time_step if the framerate < fps_min (from the manual).
And if the monitor can manage 60 fps, it is not possible to becomes 50 fps in FULLSCREEN. Only in window mode are all fps possible without lock. Use a window without a border and with screensize and you have a "fake" fullscreen with any fps possibility.

Sorry, I don't understand. You say that 50 fps in fullscreen mode is not possible!? But when you look at my screenshot above, you can see that FRAPS shows a constant framerate of 50 fps in FULLSCREEN MODE!!!

That's a pretty low screen resolution!

It'd documented in the manual if you search for "framerate":

Here's the deal: A lot of games let you use an option called "vsync" -- or "vertical sync", where the next frame doesn't begin to be drawn until the last frame has finished being drawn. When this is not enabled, you often get something called "screen tearing", where part-way through drawing a frame to the screen the next frame is calculated and begins drawing. Mirror's Edge had very obvious screen tearing, probably due to the graphical style.

In A7/A8 this isn't an option: v-sync is always enabled in full-screen mode.

Jibb

That is not right as far as I know. You should be able to control the vertical sync with the d3d_triplebuffer variable.

Oh wow, I didn't realise that was an option. The "framerate" article should probably include that information.

Cheers,

Jibb