unfortunately it’s not that easy: i double checked, and I do not have vsync enabled
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”.
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?
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…
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.
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.
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.