Performance/FPS cap -- the Glass Ceiling!

[anarchotron]

Howdy.

I'm working on a 3d engine based on LWJGL.

I'm having trouble getting super-high framerates.  It seems like no matter what I do, I can't quite break ~64 FPS.

I don't think it's really an LWJGL specific problem.  If I just spin my app's main loop as fast as possible I still only get about ~64 FPS.  Just rendering a little geometry has no effect on the framerate, (1368 tris, 2 textures).  I would expect to be able to rip through this geometry (not to mention my empty game loop) much much faster.

(Athlon XP 3200, Radeon 9800).

Is there some kind of common problem with getting a java app or LWJGL java app running at multi-hundreds of FPS?  Or am I just on crack?

Thanks!
JW

[numberR]

http://doc.lwjgl.org/javadoc/org/lwjgl/opengl/Display.html#setVSyncEnabled(boolean)
have you tried to set setVSyncEnabled to be false?
it could be a reason, but not sure because 64fps is kinda off from most of monitor refresh rate...

[Matzon]

or just disable vsync in your drivers...
I get 4000+ FPS in the gears demo, so it IS possible

[anarchotron]

Heh, I just found that my Thread.sleep() call is sleeping for way longer than expected.  I have it in there once a frame basically to free up some time for other systems such as input and whatnot.  However it seems pretty course.  

Attempted sleeps from 1 through 19 all drop my framerate from 1000 FPS to 64 FPS, so my Thread.sleep() seems to be sleeping a minimum of 14.6 ms per sleep, regardless of what I tell it to sleep.  

It seems like Thread.yield() is the function to call, although I don't like not having more precise control over how long it will yield.

Now to optimize my rendering code when its pushing large amounts of data!  I guess it's time to look at converting to VBOs.

Thanks!

[Orangy Tang]

It seems like Thread.yield() is the function to call, although I don't like not having more precise control over how long it will yield.

Thread.yield() is usually equivilent to Thread.sleep(0), in that it will just give other threads a chance to grab a timeslice rather than waiting for a specific time interval.

[anarchotron]

Aye.  The only downside to all this is that with only a Thread.yield() and not a nonzero sleep (15 ms), my debugger app (Eclipse) is getting pretty starved out while my game is running.  Ugh.

If anybody knows of a way to do precise sleeps in Java, please let me know.  I really just need to be able to pause between 5-10 ms per frame.  There's no point in running a framerate over 100 FPS as far as I'm concerned.

[princec]

Use Display.sync(frameRate).

Cas

[kramer]

Or try something conditional like:

if (fps > 100)
  Thread.sleep(1);

[oNyx]

Or try something conditional like:

if (fps > 100)
  Thread.sleep(1);

Erm... no

That would mean for... say... 0.2sec it runs uncapped... and then with a slight cap. That would look pretty unsmooth.

As Cas said there is sync(100) over in Display, exactly for this purpose. Those sync methods (there are 3 iirc) do some clever things for getting a pretty steady framerate. Feel free to take a look at the source.

[anarchotron]

I found that Display.sync(frameRate) doesn't work well when the cap framerate is higher than 300 or so... It ends up capping it in the 150 range.

The reason I want such high framerates is so I can see changes in framerate which result during my development.

However, one thing I found is that the game runs fine (at least at this stage) with an unlimited framerate...  The problem occurs in other apps, like Eclipse where I need to modify & recompile the code on the fly.

So what I did was just something like this

if (!Display.isActive())
{
   Display.sync(10);
}

To clamp it down when the app is not focused.

If I ever finish a game for public consumption (ha! not likely based on past experience), then I can maybe cap the framerate at 100 or so for general use.

[princec]

60fps will be perfect for any game. If you're doing fixed framerate anims then cap it at 60fps, change the display mode to 60Hz and use vsync; otherwise set the cap at whatever the current display mode is (or set it to 60 if it returns 0).

Cas