Jump to content
  • Advertisement
Sign in to follow this  
EternityZA

OpenGL java - System.nanoTime() good enough for high resolution timing in opengl game?

This topic is 3818 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

im currently buidling a game engine. i decoupled the physics from the rendering putting both in their own threads. now when i put the physics steptime at 100 ms (10 steps per second) everything works fine, i interpolate between the previous state and the current state so everything is smooth as wel. on my pc the app runs at a constant framerate for 60 fps on my old pc it varies between 20-40 fps.. it works wel on both systems, the physics thread hapilty runs at full speed. but now when i put the steptime at 10 or 20ms (100 or 50 steps per second) i get wierd results on both my pc's, as if im not interpolating between the two states at all, now first i thought the physic thread cant keep up but thats not it. It still finishes its cycle with a lot of time to spare so i thought that maybe the java method System.nanoTime() isnt acurate enough my purpose. Or am i just screwing it up somewere else?

Share this post


Link to post
Share on other sites
Advertisement
AFAIK both timers are very implementation dependant and therefor a bit risky to use for framerate independent physics (however on a Windows JVM it seems to work reasonably well - e.g. enough for timing execution time). Have you checked you're not getting negative values from it and odd results when you subtract oldTime from newTime? I also think you should give System.currentTimeMillis() a try.

Share this post


Link to post
Share on other sites
I'd assume that on Windows the System.nanoTime() function is using the Win32 (C) function QueryPerformanceCounter() internally. There are well known problems with using that function on a multi-core system (I'm assuming here you're on multicore) and if so that could be the cause of your problem. Now I don't know about Java's internal implementation of timing, so that is just a speculation..

The problem with that function however is that you can get inconsistent and sometimes weird results when running on a multi-core system- such as time 'running backwards' etc.. Inconsistent timing on different cores is the cause of this and unfortunately Windows has a habit of switching threads between cores quite often- causing even more difficulties.

The solution is to either restrict your game to 1 core (bad idea!!) or to create a dedicated timing thread and have that thread run on a specific core. I'm not sure how to do this in Java since (it's been a while [smile]) but I'm sure there might be something in the libraries to do this.

Personally I'd go for millisecond timing if at all possible because as the previous poster rightly pointed out, high resolution timing can be a bit shaky at best and prone to platform specific problems.

Worth a shot anyhow!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!