[java] High-resolution timers

Started by
15 comments, last by Kanzetsu 22 years, 3 months ago
Snowmoon has done an autoadjusting thread timer class. I''ve added it to GameFrame for Java (GF4J) version 0.9.6-RC1. You can download the whole thing from http://www.gamedev.net/hosted/javanerd and see the sources of gameframe.implementations.ThreadSleepClock




-

Pasi Keränen

javanerd@geocities.com
-Pasi Keranen
Advertisement
OK, I had a looked the class and apart from the adjustment part (which is the key to the functionality) it looked pretty similar to mine. However, I had some issues I wouldn't mind getting some comments on:

- Time polling. At first I had a

while(timer.getTime - startTime < minFrameTime)

at the end of each game loop iteration. This turned out to put the applet stutter, probably because hammering a synchronized method isn't that good. So, I implemented a waitForUpdate() method in the timer to wait for the notifyAll() called by the timer after each tick. At least things ran smooth now, but I still couldn't get higher timer resolutions. So I had a look at...

- Sleep time calibration. Every 50th tick? That doesn't do me any good, since I'm syncing *each* frame by the timer. So I took it down to every 2nd tick, which made things run smoothly and pretty close to the requested frame rates (30 fps could become 28-29, no biggie). HOWEVER - moving the mouse anywhere in the browser window would make the whole applet slow down considerably, and often freeze and not resume. This one is my big problem right now... got any clues?

// Kanzetsu

Edited by - Kanzetsu on December 13, 2001 6:54:32 PM
// Kanzetsu
>HOWEVER - moving the mouse anywhere in the browser window would >make the whole applet slow down considerably, and often freeze >and not resume. This one is my big problem right now... got any >clues?
>
>// Kanzetsu


did you really set up a render thread?

post your code on the board so we all can check your source

heinrich

If you are having probs Rendering stuff, don''t use the paint method in your applet (just override it with an empty paint method, & update to)

Then grab the graphics var (I use Graphics gm, standing for graphics main) in the applet init as a reference to use for drawing, by gm = this.getGraphics();

This is good for real time stuff as run concurrently to paint is slower as your main loop and paint (& what ever else) will try to run at the same time.

:-)

ujhkfkfk
Yup, I read your post about this earlier, and it''s already there =). There still seems to be some slowdown but only by a couple of frames. I can live with that for now, I''ll go back to fine-tuning timers etc later.

// Kanzetsu
// Kanzetsu
What speed is your dev plat?

I would be careful with getting to carried aournd with fine tuning timing as it may be a little inconsistant on different specked machines and other JVMS....

:-)
ujhkfkfk
Hmm..

Whell I chose even X ticks becase the ammount time must be high enough for the getCurrentTimeMills to to be more than junk. I tried doing a loop or modifiing it every time and every attempt to do so was a disaster with it ending up speeding up and slowing down untill it faulted for going to a 0 ms delay.

I have gone back over the code and I believe I might be able to make it a little more stable with a simple fix. I''ll give it another shot and report back.

Snowmoon

This topic is closed to new replies.

Advertisement