FPS low though using simple examples


I’m new to JME and currently trying the basic tutorials from the wiki. All of them work, but my stats say that I only have about 60 frames per second.

I could imagine that it should be much more since the example sceneries (a (one (1))) simple cube isn’t a very complex scene, isn’t it?

Maybe you enabled vsync?

What hardware are you running? Console output should give you some stats on that side of things. And what @normen said, just double check that.

You probably had enabled the option vsync as normen said, it is in the start screen of the app when you chose the resolution.

Hi and thanks for your answers,

unfortunately it’s not that easy: i double checked, and I do not have vsync enabled :frowning:

My hardware is quite old. A standard PC about 6 years old. “Normal” games like minecraft run with good performance, so I thought that it should be better with easy scenes (one cube in the scene graph).

Also it seems, that the framerate is somehow “limited”. There’s no evidence for that, but I tried to increase the number of cube to draw in the scene graph. A long time there’s happening nothing. When I reach about 5000 cubes arranged in a flat array, the framerate drops. I can understand this. But before I do not have more than 2000 cubes in my scene there’s happening nothng with the framerate. It stays constant at 59-60 FPS.

If vsync is on then you will get the behavior you have… so perhaps it is being forced in the driver settings or something.

If the single blue test cube is only running at a fixed 60 FPS then that is very suspicious. It means the rendering is locked to the refresh rate as in “vsynch enabled”.

So it certainly seems like vsynch is enabled.

To avoid misunderstandings: when you talking about “vsync enabled” you mean that “vsync checkbox” in the configuration window of jMonkeyEngine that appears when I’m starting the application?

Well, that checkbox is really DISabled :frowning:

Check your driver settings… maybe you are forcing it for all apps.

Something seems to be locking refresh rate to 60 FPS. And making the HUGE assumption that you haven’t made any mods to the JME sample app then it must be external to JME.

Also…60 fps is plenty enough…As long as you witnessed that you still have 60 with 2000 cubes (which is not bad at all), I guess that’s not really an issue.
It’s healhtier for your card also…

Some hardware and drivers do this limit, since 60 fps is the maximum fps that an human can see.

That’s not really true.

But if your refresh rate on your monitor is only 60 FPS then there is no reason (other than seeing how big your stick is) to run faster.

Are you using linux with opensource drivers maybe?
Because if I am not mistaken mesa drivers force vsync by default.

Touché. I’m using open source drivers. Maybe that’s the problem.

If that is the cause, it means, that I do not have to worry about the power of my computer and can spend the money in some books instead of a new computer.

Thanks to you all for your answers.

JME 3.1 has a frame profiler built in the shows a graph of where time is spent. You’d have to build from source to use 3.1 but it would give you a little graphical pop-up.

…would be interesting to see where the drivers swallow the time and if it makes the display invalid for some reason.

I have a laptop on linux with bumblebee (nvidia optimus) and if I want to force disable vsync on Intel card I type “vblank_mode=0 java -jar Game.jar” :grinning:

vblank_mode=0 works for me, too. Though there is no felt difference while moving around in the scene, but the framerate is not limited to 60 FPS. :slight_smile:

Wow! I had this problem and didn’t noticed! I’m using linux also.

For me it worked by setting vblank_mode=0 on /etc/environment.

Even if vSync is good for saving resources, I need to disable it to check if my FPS decreases alot after some change on game :yum:


The frame profiling popup that is included in 3.1 taps into some new profiling interface that is also new in 3.1. It hooks in a listener that collects the different frame steps for building the graphic but one could just as easily catch them to put frame timing in the HUD. So for example, instead of tracking FPS you could track how many nanos/millis it takes to render the frame.

Depending on how the drivers are swallowing the extra frame time, this should tell you the same thing (did my game get laggier than I want) but even when frame rate locked. It’s a theory anyway.

1 Like