Thread: Whats a good frame rate?

  1. #1
    Registered User compjinx's Avatar
    Join Date
    Aug 2001
    Posts
    214

    Whats a good frame rate?

    What is a good frame rate for a game?
    I looked at t few game and they get frame rates up to 52. I am using allegro and I can only get about 35.
    "The most overlooked advantage of owning a computer is that if they foul up there's no law against whacking them around a bit."
    Eric Porterfield.

  2. #2
    Fingerstyle Guitarist taylorguitarman's Avatar
    Join Date
    Aug 2001
    Posts
    564
    You need about 30 frames per sec to appear smooth.
    So try for 30 or more.
    If a tree falls in the forest, and no one is around to see it, do the other trees make fun of it?

  3. #3
    Registered User compjinx's Avatar
    Join Date
    Aug 2001
    Posts
    214
    but my program is only getting 35 when I am not even making it do hardly anything, shouldn't a be able to get it better?

    doesn't the speed just have to be 16FPS to look like an animation to the human eye?
    "The most overlooked advantage of owning a computer is that if they foul up there's no law against whacking them around a bit."
    Eric Porterfield.

  4. #4
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    What are you doing in the blt loop? Are you holding on to DC's too long? I only know GDI and DX (never tried Allegro) but a common cause of low frame rates (especially when there's not much being blitted) is grabbing the DC too early and releasing it too late. Try to do all your RECT, etc. calculations before you get the DC and then release it as soon as your blit operations are done.

    Are you redrawing everything in each iteration of your loop or just what needs to be changed when it needs to be changed? That's another one to look for. Try setting a boolean flag to signal when the screen needs to be redrawn and reset it to false when you finish blitting each time.

    Example:
    bool RePaint;

    //program initialization
    RePaint=true;

    //program loop
    if(RePaint)
    {
    set all variables here first
    HDC hdc=GetDC(hwnd);
    blit stuff
    ReleaseDC(hwnd, hdc);
    RePaint=false;
    }

    When the user hits the arrow key/clicks the mouse/or whatever you set as the input, set RePaint to true. That way the app won't waste time repainting the screen when it doesn't need to.

    You also might try using and update RECT to identify what has changed since the last blit and only repaint those areas.

    ::edit:: Oh, yeah, I agree with taylorgm. I'd never settle for anything less than 30 FPS. ::edit::

  5. #5
    Fingerstyle Guitarist taylorguitarman's Avatar
    Join Date
    Aug 2001
    Posts
    564
    I found this article about frame speeds.
    http://www.penstarsys.com/editor/30v60/30v60p1.htm
    If a tree falls in the forest, and no one is around to see it, do the other trees make fun of it?

  6. #6
    Registered User dirkduck's Avatar
    Join Date
    Aug 2001
    Posts
    428
    In my game making experiences, I would say try to keep it above 25, or else it will start to seem choppy, although youd probably be better off with 30.

  7. #7
    Registered User
    Join Date
    Apr 2002
    Posts
    1,571
    Yeah, < 30 FPS is no good no matter how you cut it. I get about 45fps on the 2d qauntlet - esque game I wrote and am pleased with it. Do you do a lot of multiplications in the paint code? If it is a power of 2 you should really be bit shifting vice multiplying. example:

    var1 = var2 * 2; // Standard

    var1 = ( var2 << 1 ); // Bitshift 2^1 = 2

    The other bitshift operator >> is for powers of 2 division. Also, do you have many for loops? See if you can take some formulas and such outside of the loop so you don't have to evaluate the expression for every iteration. This can be especially slow for bigger formulas. Hope that helped some.

    Edit
    Also if you use a lot of blts in your code, you can try and switch to BltFast if you don't use the effects that blt offers. MSDN claims up to 10% increase in speed.
    Last edited by MrWizard; 04-04-2002 at 11:16 PM.

  8. #8
    Registered User compjinx's Avatar
    Join Date
    Aug 2001
    Posts
    214
    jdinger, this is the only real "screen drawing" done in the game loop:

    vsync(); // waits for a vertical synchronize (or something like that, sopposed to prevent ripping or something), I took this out but it didn't improve the framerate.
    showBuffer (); // all drawing is done on an offscreen bitmap, then blitted to the screen using this function.
    "The most overlooked advantage of owning a computer is that if they foul up there's no law against whacking them around a bit."
    Eric Porterfield.

  9. #9
    Registered User xds4lx's Avatar
    Join Date
    Nov 2001
    Posts
    630
    If you are passing lots of arrays or other containers such as lists or vectors or strings or other complex (as in a class or struct) pass them by constant refference when possible, this will remove some copy operations and it should be the first optimization you should look for in your code since its probally the easiest to find.
    "only two things are infinite, the universe and human stupidity, and im not sure about the former." - albert einstein

  10. #10
    Linguistic Engineer... doubleanti's Avatar
    Join Date
    Aug 2001
    Location
    CA
    Posts
    2,459
    another thing that i found fixed a lot after know about it was using a dirty rectangles updating routine. much of your time, believe it or not, is spent in the blitting calls of static imagery... so if you cut back on that, you get a lot of extra time... [other optimizations of course, but this one was the first major hurdle for me, and for everyone i think...]
    hasafraggin shizigishin oppashigger...

  11. #11
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    In DOS, you need to shoot for 35-45 FPS. But if you have re-programmed the refresh to higher than 60, then you should shoot for higher numbers. These numbers are only possible through tight efficient C and the use of assembly. Even then, sometimes you will not get good frame rates if you are doing stuff like anti-aliasing, bilinear filtering, etc. Without the use of the accelerated hardware, high framerates using these techniques is very hard, albeit nearly impossible to achieve.

    In DirectX, I would say you should shoot for 55-60 FPS. Other video modes with higher refreshes should even be higher. Most people run their monitors at or above 75Hz. If you can get your FPS close to that, then you will have no problems.

    The problem with shooting low is that if the lowest rate is your fastest, you can guarantee your game will be choppy somewhere. When your engine encounters a complex scene and you are only shooting for 25-30 FPS, you can bet it might dip as low as 15 FPS, well below the desired frame rate for the human eye. Anything below 30 begins to look choppy. So, aim for a high number on easy scenes, and the complex scenes should not dip below the 25-30 FPS mark. If they do, then either your scene is too complex for the hardware, or your engine is too slow.

    An easy scene would be a scene that contained less objects or did not have a large z. Looking off into the horizon would not be considered an easy quick scene due to the distance involved. Being indoors looking at a wall or room with no windows would be considered an easier scene and should hit high framerates. The distances involved would be shorter (for a small room, not ball-room type areas mind you) and so you could really tell how your engine was performing on these scenes.

    We have all seen the result of game companies either shooting too low or simply not caring about the framerate. Over at gamedev I listened to Peter Molyneux (of Black and White fame) talk about frame rate. He said that in modern games, framerate is really someone else's problem. Programmers just shoot for the sky on complexity and as for framerate, I guess the computers and hardware take care of that.

    It really is a shame to see ID pump out nice 270's and 230's on benchmarks and then see another engine barely pump out 70's. The 70's engine obviously has something seriously wrong with it.
    Granted those numbers are not framerates, but the speeds should not be that far apart.

  12. #12
    Registered User Dual-Catfish's Avatar
    Join Date
    Sep 2001
    Posts
    802
    Actually, I'm pretty sure it has to be 24 or above to appear like smooth motion. I know this because cartoons are 24 frames a second... and they appear smooth.

    Anything above ~75 is a waste, as your refresh rate is delimited by your monitors refresh rate.

  13. #13
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    Originally posted by compjinx
    jdinger, this is the only real "screen drawing" done in the game loop:

    vsync(); // waits for a vertical synchronize (or something like that, sopposed to prevent ripping or something), I took this out but it didn't improve the framerate.
    showBuffer (); // all drawing is done on an offscreen bitmap, then blitted to the screen using this function.
    compjinx, are you drawing this during every iteration of the loop, though? Also, check out my and doubleanti's suggestion of using update RECTs (ie: dirty rectangles).

    "screen drawing"
    Any operation involving the DC is going to slow it down, whether it's to the backbuffer or the screen itself.

    The biggest things are to minimize the area to be redrawn each time (using update RECTs) and to eliminate the excess unneccessary drawing (by only drawing when something has changed).

  14. #14
    Registered User Coder's Avatar
    Join Date
    Aug 2001
    Location
    Cairo, Egypt
    Posts
    128
    The frame rates really depend on the card. Using hardware acceleration ( rasterization with/without T&L ) boosts frame rates incredibly.

    QuakeIII runs at around 120 FPS on 1+ GHZ processors with some T&L card ( Geforce/Radeon ). I've even read that it got 200 fps on some GeForce ( most probably 3, with some options turned off )

    30 FPS is some standard, if you're getting more FPS then you should try to add some more eye-candy and features to your engine.

    John carmack, Id software lead programmer, announced that his new DOOM III is going to run around 30 FPS on a GeForce3. Ofcourse that was before the GeForce4.
    What I'm saying here, is that he found 30 FPS to be a suitable max frame rate ( the GeForce3 was the most powerful card, then )

    It really is a shame to see ID pump out nice 270's and 230's on benchmarks and then see another engine barely pump out 70's. The 70's engine obviously has something seriously wrong with it.
    Granted those numbers are not framerates, but the speeds should not be that far apart.
    Why not framerates? I've seen 3D Card reviews in PC Magazine that got framerates up to 200 on QuakeIII, although Quake is generally a special case.

    These numbers, sometimes are framerates, sometimes aren't.
    Muhammad Haggag

  15. #15
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Anything above ~75 is a waste, as your refresh rate is delimited by your monitors refresh rate.

    Only if VSync is on.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Frame buffer not working
    By Noise in forum Game Programming
    Replies: 1
    Last Post: 02-15-2009, 12:05 PM
  2. Good resources for maths and electronics
    By nickname_changed in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 12-22-2004, 04:23 PM
  3. Lock Frame Rate??
    By Unregistered in forum Game Programming
    Replies: 1
    Last Post: 06-06-2002, 11:03 PM
  4. first excitement...then the let down...
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 05-25-2002, 01:47 PM
  5. i need links to good windows tuts...
    By Jackmar in forum Windows Programming
    Replies: 3
    Last Post: 05-18-2002, 11:16 PM