PDA

View Full Version : Maximum Frames Per Second?



RPGillespie
04-14-2013, 07:16 PM
I am working on a tetris game in openGL. However, at the moment, the game is running at 1200 frames per second (yes you read that correctly). I've verified it with a timer - it takes 3 seconds for a 3d object on my screen to make a full rotation, and each frame adds .1 degree to the current rotation value.

Is this... normal? I don't even think my monitor pixels can change that fast. I feel like 60 fps is about as high as I want to go, but it feels like a sin to artificially slow down my program.

cireneikual
04-14-2013, 09:26 PM
That is normal. In all likelihood your monitor can only go to 60 fps, so anything above that is a waste (at least for graphics). You can limit the frame rate with vertical sync, this will also eliminated screen tearing and will make it look smoother.

mobeen
04-14-2013, 10:31 PM
Adding to what cireneikual said, probably vsync is disabled on your PC. For you application, you should enable vsync to make sure that you go in sync with the monitors refresh rate. That will limit the framerate to 60Hz.

Timppa
04-15-2013, 10:41 AM
You should indeed enable Vsync like mentioned above.

However on top of that it is also a good idea to use delta timing. Otherwise the game will run faster/slower on some systems even with vSync enabled. You don't want your game to play at double speed just because someone has a 120hz monitor. Some older systems might not also be able reach the framerate limit.

The solution is simple, all you need to do is have a timer which measures how fast the game is running, divide the desired update time by that and you know how much faster or slower the game is running. Then you can simply multiply framerate-depended variables like your rotation amount by that.

Dark Photon
04-16-2013, 05:30 AM
...it is also a good idea to use delta timing. ... have a timer which measures how fast the game is running, divide the desired update time by that and you know how much faster or slower the game is running. Then you can simply multiply framerate-depended variables like your rotation amount by that.
Even better is to not define your animations in terms of framerate, as it may vary and in fact be completely dynamic per frame when you're free running (running not synced to vblank, which can be useful for performance analysis). Define animations in terms of real-time (e.g. rate/second). Then when the frame comes along, you just use what time it is to compute the current elapsed time for the animation, and from that the current animation state.

Nowhere-01
04-16-2013, 06:56 AM
using v-sync as a frame limiter is downright retarded. what if v-sync is disabled in driver control panel? or it's not supported or user has 120Hz monitor and you designed it with 60Hz in mind? your application will go batshit fast and will be unusable if it does any transformation or logic in the same thread as render. not mentioning that using non-adaptive v-sync in other type of game, like first person shooter may lead to disastrous input lag.

there are threads for that. you render in one thread, limited to target FPS with timer. and you do logic in separate thread, which may have different update interval. if you don't want\can't implement threads - at least use Sleep(taking in account how much frame took to render) at the end of rendering function and design all logics in your game targeting FPS you limited your render to. but that's not a proper solution. but i guess it's acceptable for some simple casual puzzle.

Dark Photon
04-16-2013, 06:14 PM
...your application will go batshit fast and will be unusable if it does any transformation or logic in the same thread as render.

Agreed.

It is funny to watch the animations blast past at ludicrous speed.

...but not so much fun when you end up having to fix that behavior in someone else's code. So, just say no -- don't peg animations to frame rates. Peg them to realtime (wall clock time) or gametime (which is based on realtime).