well i’m greasing with the 17th Oct build atm, tell me when this gets fixed plz <33333 
Adding Application.setTimer() now and will test with NanoTimer before switching to it for the default. Will advise when complete.
2 Likes
In SVN, Application now has a setTimer() method that properly resets the timer. I have verified that using NanoTimer gives me back >999 FPS readings and what look to be more accurate readings. My tpf based animations seem to operate ok but my critical stuff already does its own timing. So in my case it’s just the ocean and waving grass that would have been affected and they seem fine.
I have not switched the default to NanoTimer as I’m still on the fence about the best place to do it. I’m 99% sure that Application is the most appropriate place.
2 Likes
cool :), will try it tomorrow, and tell you the results, thanks <33
the timer needs to be changed in the JmeContext.
nehon said:
the timer needs to be changed in the JmeContext.
Not so sure about that, Application simply grabs it from there and then continues to give it out to the other parts of the engine.. If it simply gives out another timer, the context timer will just sit there..
@normen,
Yeah, and if you had a platform specific timer then it would only be available through the current JmeContext… which is why I felt like Application should be the thing selecting NanoTimer. Then if the user wants to go back to the “default hardware timer” then they can set it to JmeContext.getTimer().
NanoTimer works really well for me. Also frame rate is much more consistent without vsync.
Btw. TestHoveringTank throws an exception but still works…
[java]com.jme3.asset.AssetNotFoundException: Models/HoverTank/Tank2.material[/java]