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.