[SOLVED] FPS too low or just normal?

[co_Opernicus]

Hi all!

  I've added some debug messages on my "little creature" to test FPS. I don't know if this is normal, but when I comment the "thread.sleep" part in my main loop I get about 8200 fps which I guess is not a bad signal... But, when I toggle Thread.sleep (10ms per iteration), it goes down to an average of 105-110 fps.

This is the code of the game main loop (thanks ra4king for your good advices!!):

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52

public abstract class Game {    ...blah blah blah...    public final void run() {             //debug:      int currFPS = 0;       int avgFPS = 0;       double currTime = HiresTimer.getTime();       graphics.setDrawColor(Color.white);                     while ( gameRunning ) {                    deltaMsecs = HiresTimer.getTime() - lastLoopMsecs; //don't mind this.. it's used elsewhere         lastLoopMsecs = HiresTimer.getTime();          update();                    do {                         do {                                Graphics2D g = (Graphics2D) strategy.getDrawGraphics();                render();                                //debug: show fps               graphics.drawText("FPS: " + avgFPS, 10, 10);                                g.dispose();                             } while ( strategy.contentsRestored() );             strategy.show();                         try {                //Take exactly (hopefully) 10ms per loop               Thread.sleep( (long) lastLoopMsecs + 10 - (long) HiresTimer.getTime() );             } catch (Exception e) {}                                  } while ( strategy.contentsLost() );                    //debug:         currFPS++;          if ( HiresTimer.getTime() - currTime >= 1000 ) {             avgFPS = currFPS;             currFPS = 0;             currTime = HiresTimer.getTime();          }       }          }

Right now I'm only drawing an animated sprite that moves and jumps depending on keyboard input and showing the fps message...

To me it looks that it should be more than just 110 FPS, but maybe that's normal... or maybe it's just a wrong FPS calculation method???

Thanks in advance for your comments!

[Regenuluz]

Well there's only so many 10ms pr second, so if you think about it then it makes perfect sense. You're doing nothing for ~10ms every loop. ^^

[co_Opernicus]

Well, yes, but I was wondering if maybe as I get more and more logic into the game will that mean that those 110 FPS will remain?

In the sleep I'm calculating the remaining msecs to get to those 10ms per loop, so with more update/drawing operations it'll just sleep for the rest of the msecs needed...

Games published by our own members! Check 'em out!

[Geemili]

I think 110 is a lot. I used to make games with game maker, and I put the default at 30 FPS. Only when I began development in java did I learn that 60 FPS is default now. Your'e probably fine with what you have right now. (And, if for some reason you need to know, I didn't look at the code at all. Although, if you don't sleep, you'll overheat your CPU I think)

[sproingie]

In the sleep I'm calculating the remaining msecs to get to those 10ms per loop, so with more update/drawing operations it'll just sleep for the rest of the msecs needed...

That's basically how you reach a target FPS, yes.  As you do more work, your sleeps will get shorter.  There's a long thread here about Sync.sync() in LWJGL, which you should be able to copy and use in your code (it's not specific to opengl).  

You should consider a target framerate no higher than 60 or so.  Maybe 120, but only if your game is ridiculously fast-moving and you want to cater to the bleeding edge.  People on laptops and phones will be happier with lower framerates if it preserves their battery.

If there's a sticky FAQ around here somewhere, "How do I keep a game loop at a target framerate?" should definitely be part of it.

[Rorkien]

Nah, its pretty normal
But if your loop sleeps for 10ms after every iteration, and you are getting 105-110 frames per second, it's just a signal that something is innacurate: The loop itself or maybe the FPS counter is taking more than a second to count frames 

[Danny02]

why does nobody here enable/use vsync?

[gimbal]

why does nobody here enable/use vsync?

Who says they aren't? but vsync is to reduce tearing, its not to reduce framerate even though that is a byproduct. Its unreliable at best too; it can be disabled through the driver and there is no standard vsync rate; it is totally dependent on the refresh rate of the display device.

On top of that, even if you use vsync to lock a framerate, you may still want to have a different "update rate". I like to sample input device state more often than I update world state / rendering frame for example.

(I use 50fps btw; it was good enough for Amiga games, its good enough for me )

[co_Opernicus]

On top of that, even if you use vsync to lock a framerate, you may still want to have a different "update rate". I like to sample input device state more often than I update world state / rendering frame for example.

  That sounds interesting... what do you do that for? So you get more accurate response to your input? I've always been concerned about creating a "smooth flow" between your brain ordering your fingers to press a key and getting an immediate reaction in the game, I think it's one of the keys of making a good game... at least that's what I want games to feel like

[gimbal]

On top of that, even if you use vsync to lock a framerate, you may still want to have a different "update rate". I like to sample input device state more often than I update world state / rendering frame for example.

  That sounds interesting... what do you do that for? So you get more accurate response to your input?

Exactly that. Its a bit pricky to be honest as it basically means having the chance to have updated input state "on time" for the current frame more often, but on the other hand precision is something you don't want to take away from a gamer