I was using JME3_2011-10-18.zip and FPS was great.
I downloaded the jME3_2011-10-20.zip from the nightly builds to update my game to the newer build.
FPS went as low as 3fps. I do not know why it is so slow. I am running SimpleApplication with no objects added to the rootnode.
Graphics card: Nvidia GeForce 7600
CPU: Intel Core 2 Duo 2.6ghz
What was FPS before?
And you must be rendering something for FPS to go down. There is information we are missing, I think.
Looks like the calculation of fps was changed in revision 8454, so the displayed frame rate dropped for me too.
Downloaded the newest jME3_2011-10-21.zip and FPS is smooth. Thanks for the quick fix!
My game worked fine, I updated to nightly a few days ago, now my game pauses every so often. Its not just my game, it happens with all the jme-tests as well. Also occurs using the Beta update as well. Windows 7 32 bit, NVIDIA GeForce 9300M GS
How often is “every so often”? If it’s consistently about once every two or three seconds then it may be GC. There is a command line option you can put that will make Java log GC information. It’s the full GC that will cause a JVM wide pause… and if it’s a case of never catching up it will pause every few seconds.
Otherwise, we all may need more information about when it pauses. The unfortunate thing about running nightlies from the update center instead of building from SVN is that it’s hard to roll back in these cases. 
1 Like
ok thx. It’s quite a wierd phenomena, similar to this guys problem, http://hub.jmonkeyengine.org/groups/general-2/forum/topic/default-flycam-gets-stuck-since-last-update/ and a lot of the time not noticeable. If you can try this, try the TestBrickWall in the bullet test folder. I can fire everything fine, looks smooth, but when i go nearly level with the floor, and go from 1 side to another, i’m getting brief stuttering every so often (I get about 14 in total). Just feels so unnatural. The game im making is a kind of side scroller, so it’s a lot more noticeable. This is the first time i’ve really done anything from the commandline, took me a while lol. Also my JVM crashes quite a lot now.
Whats the best way for example to revert back to hmm 17th October for instance? just download the zip and wack it in somewhere? :P, hope its that easy. thx for the help
Heres the GC thingy u wanted:
http://i.imgur.com/RbI4L.png
Is it the game pausing or just the camera movement? Do moving objects seem to stay smooth? Is vsynch on?
It could be that with the new timer and high FPS that time is losing precision or something. Since some people claim the other time issues are fixed for them and I don’t remember seeing a fix go into SVN then I’m not sure. Depending on your answers to the above questions, I can look into it.
1 Like
Oh, and I have no idea how to revert to an earlier nightly. Since way before Alpha 4, I build from SVN and just reference that jars directly in my project. It makes it easier to roll forward and back in time at the loss of “push button simplicity”.
pspeed said:
Is it the game pausing or just the camera movement? Do moving objects seem to stay smooth? Is vsynch on?
It could be that with the new timer and high FPS that time is losing precision or something. Since some people claim the other time issues are fixed for them and I don't remember seeing a fix go into SVN then I'm not sure. Depending on your answers to the above questions, I can look into it.
for me objects and camera rotation stays smooth, only moving (translating) the freefly cam feels stuck. I notices less stuck when i enable anti aliasing. (vsync is of). But the occurence for me seems to happen at random time. Sometimes it works some seconds it won't
After carefully looking at my game found out a few things:
- Frame rate used to be around 59-60 all the time with vysnc and sometimes fluctuate. But now sometimes it’s going crazy and going up to 270 (rare) and fluctuates quite rapidly around 45-70.
- The animation of my character stays fine the whole time
- The sky (mine rotates with tpf) and particles which the camera pans across stutters every so often of varying degrees.
For brief moments everything looks fine.
the update which did its was 4-5 days ago, but i hadn’t updated for maybe 4-5 days again prior, so the culprit is somewhere inside the 5-10 days ago region :P.
You can easily use the nightly jars to test this. Remember however that the timer was changed lately, so different fps values might be calculated, maybe thats the issue?
The default timer that JME uses used to do smoothing and now it doesn’t. And I’m not convinced it’s resolution is good enough to be doing the job and so may result in stutters that were previously smoothed out.
The smoothing was a bit ugly too since if you had frame drops then you suddenly saw everything move really fast for a second while it tried to catch up.
There are alternate timers that can be used (including going back to the old smoothing) and I believe that the NanoTimer will work better (if the default hasn’t already been switched to that, I haven’t looked).
Supposedly you can just do:
timer = new NanoTimer();
In simpleInit() but I haven’t tried it yet.
1 Like
Note: I looked in the code and it turns out that setting it in simpleInit() is not early enough to change it for everything.
There is currently no way to override the timer for everything but doing as I put above will at least let the update() loop use the new timer… even if shaders, etc. still use the old one.
unfortunately that didn’t work (at least for my game), haven’t tried it for other tests, I tried the nightly, 17/10/2011 (haven’t tried any others yet), and that was much better. Dunno if that helps
Like I said, I know that the timer implementation has changed but it’s still strange that the frame counter can drop from a maximum of 999fps to 9fps although animations seem to stay fluent. Also before the change the fps would max out at 3999fps in an empty scene just to mention it.
Yeah, if you don’t switch to the NanoTimer then the timer resolution is only milliseconds so you’ll never see more than 1000 FPS measured. Also since there is no smoothing it will bounce around a lot more than it did… especially at high frame rates.
I personally think that NanoTimer should be the default timer if we’re not smoothing anymore… but it’s still under discussion. At the very least, I plan to add a way to set a new timer because the approach mentioned above is only a partial solution.
2 Likes
Ah ok I understand now partially, thank you for the explanation.
pspeed said:
I personally think that NanoTimer should be the default timer if we're not smoothing anymore... but it's still under discussion. At the very least, I plan to add a way to set a new timer because the approach mentioned above is only a partial solution.
I second that, in the end i found this new timer worst than the previous one.