Timers

OpenGL Development JOGL Development
#1

I’m trying to keep movement in my application steady even if the FPS doesn’t remain steady, and it turns out that I managed to create steady jerking instead… how does everyone here deal with timing issues caused by System.currentTimeMillis() having return values in increments of 50 or so (on windows). I’m hoping there is a standard way to handle this without requiring native code and with some level of reliability.

If no one has a good alternative I’ll probably try and use a seperate thread to control all the data changes that happen between frames using Thread.sleep to take short naps and update values, as I understand it Thread.sleep is accurate as low as 1 ms, and the only risk I run is the machine gets too busy and the thread doesn’t get to run (basically nothing would move and the same scene would display constantly). I would prefer to pass in the amount of time into any function that handles changes to my scene though.

#2

There are a few alternative high resolution timers around. There is a “hidden” one built into JDK1.4.2 which is meant to become standard in Java 1.5. However, since this is non-standard I wouldn’t get dependant on it.

The best alternative imho is the GAGE timer available from http://java.dnsalias.com . It uses the standard timer or UNIXs and a bit of JNI on windows to access their high res timer.

Kev

#3

The high resolution task will be part of Java 1.5 :slight_smile: However Key is right, currently with Java 1.4.2 its name isn’t official.

Being on that FPS-independent topic: Although I use a timer task to do my simulation (which animates the Jogl models, too) I see jerkyness in the movement of my Jogl objects, too, like DanK.

Is this because my used TimerTask’s resolution isn’t high enough (like in System.currentTimeMillis) ? For example, roughly I do:

timer = new Timer(); 
sim = new Sim();
timer.schedule(sim, 001, 1000/50);  // 50 times a second.
...
private class Sim extends TimerTask
{
  // animate all Jogl models.
}

If, in contrast, you would like to use that (yet inofficial) high resolution timer to animate/simulate 50 times a second, could you do this in the following way?

long oldtime;
void main_game_loop
{
  long newtime = perftimerInstance.highResCounter(); // in ms
  long deltatime = newtime - oldtime;
  oldtime = newtime;
  if (deltatime > 50) {
    mysimulation.doSim();
  }
  else {
    sleep(???)
  }
}

But how do you let “sleep” your game-loop and how long? (I mean: if you let it do, say ~50 ms, does the thread’s sleep timer have got a high enough resolution?)

Second chapter: I’ve read that by using the time measure way in contrast to timer tasks you could avoid multi-threading.
However, in the case of Jogl, the Jogl’s registered display method is always being called parallel to my main simulation - no matter if that simulation is being called by a timer task or a time measure method. Isn’t it?

Thanks for any clarification.

#4

But are you sure the TimerTask would work? The problem I currently have is that when I let the render thread run at full speed (~190fps) it starves all the other running threads.

(I haven’t tried lowering the priority of the render thread though, so it could be that doing that will solve my problem.)

[edit]
To answer my own question: yes, lowering the priority of the render thread works like a charm. I can now run full speed again without (noticably) affecting the other threads.

#5

[quote]But are you sure the TimerTask would work? The problem I currently have is that when I let the render thread run at full speed (~190fps) it starves all the other running threads.
(…)
To answer my own question: yes, lowering the priority of the render thread works like a charm. I can now run full speed again without (noticably) affecting the other threads.
[/quote]
So far I haven’t had to do this because I’ve not enough “load” on the display thread. :slight_smile:

In case you move/animate your Jogl models in a TimerTask thread: do your models run/animate smoothly?

If there aren’t many objects to simulate my TimerTask runs smoothly but with more objects the jerkyness begins.

#6

I still use System.currentTimeMillis() and my animation/movement is slightly jerky, but to be honest I haven’t spent much time on it yet because I’m first trying to setup the entire framework for my application. When I’m happy with it I’ll have to take a look at smoothness and such. (But so far it’s the multi-user network code that gives me the most headaches ;))

#7

The gage timer relies on native code which I’d prefer to avoid (I’m making an exception for JOGL of course but I’m hoping that eventually JOGL or some other OpenGL API becomes a part of the core java stuffs). I’ll try my alternate approach to it, though I’m going to guess for anything complex the approach I’m going to use wouldn’t be any better (anything with a lot of AI and rendering is going to have to deal with starvation and the amount of time spent on AI and updating movement could throw things off, since we can’t really measure how long it took to do the AI/movement/collission stuff, we can’t choose to sleep a little less time to keep things smooth).

I can’t use the 1.4.2 timers, it turns out the DDHELP crashes I was getting were caused by the 1.4.1+ JRE’s, it’s apparently a bug in the ATI drivers that only Java sets off, so basically what happens is I compile a program, run it, and then when I close it I crash, then I reboot and try again… maybe not such a big hang up for some people, but I’m the kinda guy who has to compile every 3 lines of code and see how things look (especially with OpenGL and 3D programming stuff which I’m very new at).

#8

I use the average frame time of the last ~50 frames, to update the animation. Has some drawbacks, but atleast the animation is smooth.

#9

[quote]The gage timer relies on native code which I’d prefer to avoid
[/quote]
You can use the timer from Java3D

#10

The timer from Java3D seem even more unlikely to ever become part of the JDK. Although its equally as good as GAGE if a little more bulky.

I think the point is aslong as you insulate yourself from the timer implementation that you’re using you won’t have a problem changing to a “supported” one later. Stick an interface between you and the library and you won’t have a problem in the future.

However, I’d still shy away from the 1.4.2 “hidden” timer since you don’t know what version of JRE the end user will be running with (unless of course you’re going to ship the JRE aswell)

Kev

#11

Can somebody tell me where to find this “hidden timer”? Because I haven’t been able to find it so far.

#12

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Tuning;action=display;num=1053157119

Kev