Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualVerik

Posted 12 September 2012 - 04:50 PM

There is a great article that discusses how operating system clocks interact with Java methods, specifically System.currentTimeMillis(), Thread.sleep() and System.nanoTime(). The article claims that the Windows system clock (of modern Windows version) can trigger threads at 15 (16?) ms intervals, but can also be forced to work in 1ms intervals. I have not verified this, but I have seen System.currentTimeMillis() report jumps of 15 ms, instead of the expected 1 ms.

My personal experience is with the JGame library which uses an advanced version of the one that EpicWally suggests. (You can look up the main game loop is located in the JGEngine class in the JRE platformversion). One of the things they do is add a Thread.yield() in case there is no time left to sleep away with a Thread.sleep(). The demo games run very smoothly, but I guess you can hardly call them taxing.

Hogging the CPU with your main thread seems like an odd idea, since you will most likely be running at least a GUI thread next to your main game thread. You really do want the GUI thread to be able to paint your frame, and grab some input events while it's at it. Even worse: your OS can always interrupt your thread regardless of whether you call Thread.sleep() or Thread.yield(). Although I have not tested this, I would expect to have a smoother frame rate if you actively give up the cycle's you don't need to other processes. Rather than waiting for the OS to decide when it time for other processes to get a share of the pie (while you were in the middle of rendering a complex frame). In the presence of multiple cores this might play out differently, but I would not know of a way to have the GUI thread hog a core ;)

Edit: minor erata

#1Verik

Posted 12 September 2012 - 04:48 PM

There is a great article that discusses how operating system clocks interact with Java methods, specifically System.currentTimeMillis(), Thread.sleep() and System.nanoTime(). The article claims that the Windows system clock (of modern Windows version) can trigger threads at 15 (16?) ms intervals, but can also be forced to work in 1ms intervals. I have not verified this, but I have seen System.currentTimeMillis() report jumps of 15 ms, instead of the expected 1 ms.

My personal experience is with the JGame library which uses an advanced version of the one that EpicWally suggests. (You can look up the main game loop is located in the JGEngine class in the JRE platformversion). Basically they add a Thread.yield() in case there is no time left to sleep away with a Thread.sleep(). The demo games run very smoothly, but I guess you can hardly call them taxing.

Hogging the CPU with your main thread seems like an odd idea, since you will most likely be running at least a GUI thread next to your main game thread. You really do want the GUI thread to be able to paint your frame, and grab some input events while it's at it. Even worse: your OS can always interrupt your thread regardless of whether you call Thread.sleep() or Thread.yield(). Although I have not tested this, I would expect to have a smoother frame rate if you actively give up the cycle's you don't need to other processes. Rather than waiting for the OS to decide when it time for other processes to get a share of the pie (while you were in the middle of rendering a complex frame). In the presence of multiple cores this might play out differently, but I would not know of a way to have the GUI thread hog a core ;)

PARTNERS