Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 7 of 7

Thread: Maximum Frames Per Second?

  1. #1
    Junior Member Newbie
    Join Date
    Apr 2013
    Posts
    5

    Maximum Frames Per Second?

    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.

  2. #2
    Junior Member Regular Contributor
    Join Date
    Mar 2012
    Posts
    129
    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.

  3. #3
    Advanced Member Frequent Contributor
    Join Date
    Mar 2009
    Location
    Singapore
    Posts
    800
    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.
    Regards,
    Mobeen

  4. #4
    Junior Member Newbie
    Join Date
    Apr 2013
    Posts
    7
    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.

  5. #5
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,224
    Quote Originally Posted by Timppa View Post
    ...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.

  6. #6
    Member Regular Contributor Nowhere-01's Avatar
    Join Date
    Feb 2011
    Location
    Novosibirsk
    Posts
    251
    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.
    Last edited by Nowhere-01; 04-16-2013 at 06:03 AM.

  7. #7
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,224
    Quote Originally Posted by Nowhere-01 View Post
    ...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).
    Last edited by Dark Photon; 04-16-2013 at 05:25 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •