Limiting FPS

OpenGL Development JOGL Development
#1

How do you limit Frames per second to a limit with JOGL?

I notice GL.setSwapInterval(1); to enable vertical sync. Does this just go off the vertical refresh set by the OS? Is it possible to set custom FPS rate using swap interval?

#2

Look at FPSAnimator, it’s pretty simple.

#3

Okay I think this is a bug. Using 1.1.1-rc7 of JOGL.


public void display(GLAutoDrawable gLDrawable) {
		long delta = System.nanoTime() - lastLoopTime;
		lastLoopTime = System.nanoTime();
		lastFpsTime += delta;
		fps++;
		
		// update our FPS counter if a second has passed
		if (lastFpsTime >= 1000000000L) {
			frame.setTitle(TITLE + " (FPS: " + fps + ")");
			lastFpsTime = 0;
			fps = 0;
		}
		
		logic(delta);	// Perform game logic
		
		final GL gl = gLDrawable.getGL();
		gl.glClear(GL.GL_COLOR_BUFFER_BIT);

               render(gl);
		
		// flush the graphics commands to the card
		gl.glFlush();		
	}

Using animator = new FPSAnimator(glCanvas, FRAMERATE, true); I get fps of FRAMERATE.

Using animator = new FPSAnimator(glCanvas, FRAMERATE); its about 20fps lower then FRAMERATE.

#4

The examples I have seen suggested adding a sleep help reduce the frame rate. Something like the following, if you are using a GLCanvas with a main loop:




public void run() {
  while ( this.run ) {
    repaint(0);
    try {
       // you can add some logic to adjust the sleep, to compensate for the machine capability
       Thread.sleep(30);
    } catch ( InteruptedException ex ) {
    }
  }

}
#5

Yes can use Thread.sleep. I just thought it was weird that FPSAnimator does run at the FPS you specify unless pass in true for schedule at fix rate.

FPSAnimator is using java.util.Timer to schedule the calls to display. Taking a look at the code for Timer I notice

  1. It uses System.currentTimeMillis() which found to be inaccurate on windows
  2. If not using fix rate. It actually schedules the next display to be called after delay of 1000.0f / (float) fps. So FPSAnimator is not accounting for the time it actually took to run the display method when not using fixed schedule. So why is not using fix rate the default?
#6

It depends on the algorithm used for determining how much time to sleep for after rendering a frame. I would read the documentation for the different timing algorithms. If it’s not in FPSAnimator or Animator, look at the java.util.Timer (I can’t remember where I read it). Bottom line I think is that if you have a too slow computer for the frame and you’re not doing fixed rate, it slows down because it can’t keep up. Don’t quote me on that, though, this is all from memory.

#7

Don’t use Thread.sleep()!! It might break a synchronization somewhere else and decrease hugely your performance! My game was twice slower (I use VBO) when I used it even to perform a very short sleep. FPSAnimator is maybe a better way to do it.

#8

sleep() isn’t bad, but you have to remember that when you call sleep(), you’re doing a whole lot more than just pausing that thread’s execution.

#9

does anyone know how difficult it would be to implement an FPSanimator that works with nanoTime ?

if i am not mistaken the current one uses a timertask which has only millisecond accuracy. but i might be wrong.