The FPS counter appears to be incorrect. It's showing very high FPS in the hundreds during periods of low real FPS . I'm running an FPS counter that came with the ATI Tray Tools on the Omega driver set for my Radeon 9600XT and its slowing the real FPS. I apologise if this is a known issue but I'm new and haven't been able to find my way about the site completely yet and couldn't find anything on the search about this.
I'm using an implementation of SimpleGame to display a sphere. That's all.
How can you have a "low real FPS" on a 9600 with just a sphere? Would the other tool you use happen to be showing an FPS equal to your refresh rate? In that case it's due to V-sync being enabled. That's the problem of that tool then, not jME.
What I mean is that I deliberately racked the number of triangles in the sphere up until the FPS dropped significantly below my refresh rate and the program was displaying FPS in the 300-500 range.
I what program do you see this FPS counter? I had a wrong FPS once and finally found out that I was using SimpleGame and in simpleUpdate() there was a call to timer.getTimePerFrame() so that it effectively was called twice per frame. That led to wrong calculated FPS.
Galun said:
I what program do you see this FPS counter? I had a wrong FPS once and finally found out that I was using SimpleGame and in simpleUpdate() there was a call to timer.getTimePerFrame() so that it effectively was called twice per frame. That led to wrong calculated FPS.
I'm actually running the HelloNode tutorial from here: http://www.jmonkeyengine.com/wiki/doku.php?id=starter:hello_node
I changed the triangle to have a bucketload of triangles to slow the card down to a crawl. And of course, to make me look like a madman, it's now displaying the correct FPS ^^. I did just upgrade the JRE to the latest version, however, so it could be a problem with the version I was using.
Well, there may be something to this.
I just downloaded FRAPS and am seeing a much lower framerate in FRAPS than is being displayed in jME.
TestTerrainPage is showing 80-90 FPS in FRAPS and 250-300 in jME.
When the framerate reaches ~50 in jME it reports ~50 is FRAPS. So lower framerates are accurate, but we have inaccuracies at higher rates? It's a possibility.
We'll look into it to see where the discrepancy is.
At high framerates jME can be inaccurate since the timer resolution is only 1000 ticks per second right now. I'll take a look at better FPS calculation while fixing the timer issues. However a program that reports low fps for just a sphere…
llama said:
At high framerates jME can be inaccurate since the timer resolution is only 1000 ticks per second right now. I'll take a look at better FPS calculation while fixing the timer issues. However a program that reports low fps for just a sphere..
Well it was a sphere made of over 100,000 triangles :p. Was just seeing how many triangles I could render at once and still get decent FPS.
I have had some difficulties getting fraps and java -gl to play nicely together in the past, so I'd suggest we use 2-3 different testing apps to make any conclusions.
Little test that I ran:
I've noticed that my home PC would run Lesson 7 of the FlagRush tutorials much differently (the vehicle would accelerate slower, drive slower, turn slower, etc). This PC is much faster than the PC I work the tutorial on. After doing a little ad-hoc investigation, I found that the time per frame in fact is too small (i.e. higher frame rate reported than what is actually occuring). This means, that jME thinks the computer is running faster than it truely is, sending the lower values to update and causing the vehicle to drive like a slug. My unscientific experientment, involving the second hand of my watch involved me adding up the time per frames until 10 seconds were reached. At the same time, watching my second hand. The values were off by a couple seconds.
I believe jME is reporting a much higher frame rate than what is reality.
Ok, I believe I have solved this by converting from a store and average of fps to tpf. This brings our tpf in line with that of fraps and seems to smooth out other issues described. On top of that, I added a few optimizations which shaved off a little extra cpu time noticable if getTimePerFrame or getFrameRate is ever called by your own program more than once (or ever, in the case of things extending SimpleGame.) It also allows the fps display to go above 1000 again. 
I believe the difference (at least what I was going for when I made the change) is in rounding and floating point calcs. I'm now storing longs instead of floats and perhaps more importantly it does not have an issue now if the time between the last update and the current one is 0. (In the old timer it fudged and said it was 1 instead.)
Anyhow, the proof is in the pudding as they say, so please check it out and see how it works locally.
That seemed to take care of it. FRAPS values and the FPS display match.
There was/is an issue for this, and I had some similar code written to fix this but decided to work on a better solution later. While that fixed most of the problem at high framerates it didn't do that at lower framerates. In fact in my test espc. with unstable framerates it even became more inaccurate. Renanse solution is a bit different than what I had though, and seems to be more accurate.
Running TestTimerAccuracy still shows it's off by a few percent on lower framerates now, however not more so than the old system. I think this solution is enough for people most people now, however I'll try and integrate my fixes with those of renanse to have a timer system that's completly accurate for animation and input in the future.
Hmm, I guess it varies by machine. Fraps shows 49 on my machine on that test when slowed and our counter is showing 48 fps. Could easily be different rounding methods there. In any case, I've heard rumors that lwjgl is working on new timer code so we may want to wait and see what that ends up being all about.
Great job Renanse!
darkfrog