Timer alternatives in Applets?

Hi there!

Thanx for a great forum and (so far) great answers. I 'm developing Applet games and have (finally!) begun to see how things should be done!

I’m currently running in windowmode @ 150 fps which makes my games quite fast since they were designed in the “old fashioned way” where you move as many times / sec as you repaint (that is like 25 fps…) Therefore I need to seperate the rendering frmo the animation and I found Markus Persson’s grate piece on discrete stepping but I can’t make it work properly since I don’t have a HQ timer in Applets…

So - The actual question would be:
How can I control the velocity in my applet games WITHOUT a discrete stepping algorithm whcih require a timer that I don’t have access to;

How can I make use of the discrete stepping algorithm from my Applet without a HQ timer?

/Suggestions plz?
Markus

In my applets I assumed that the frame time was almost constant. Then I took the average of the last 25 frame times and used that as my current. This smoothed out the inaccuracy of the crappy System.currentTimeMillis(). The downside is that it can give you speed up/downs, if you do not have constant fps.

So, you still use System.currentTimeMillis() but filter the worst inaccuracy away by averaging the last 25 frames…

I guess there’s only one way to check if it might work :wink: Test!

Thanx, Markus

With System.currentTimeMillis

on Win98 you get max 10FPS

why because intervall min is 100ms ( because timer has 50ms ), thats a physical law twice the res is min sample. U learn this at university

DO NOT USE System.currentTimeMillis OR YOU ARE DOOMED.

IF U DO NOT FOLLOW THESE GUIDELINES DONT ASK ME

Sell your game for 50 bucks with 10FPS and your customer will haunt u forever.

I disagree.

So long as your render cycle takes less than 50ms, you won’t miss any clock ticks, and you will achieve the maximum 19-20fps.

If you were sampling the time at random intervals, (hence you don’t know when the current clock tick began) then yes, the maximum accuracy will be 10fps.
But, because you are performing a tight spin on system.currentTimeMillis() (waiting for it to change) you can be sure you sampled the timer almost immediately after it changed.

I don’t dispute that 20fps is poo though :slight_smile:

I get the picture. I was just unsure of how currentTimeMillis was implemented…

BTW - Yes, MGodehardt I also recall the double frequency stuff from when I graduated a M.Sc in Computer Engineering, Mechatronical Systems and currently work / teach as a Ph.D student in sweden…

Some people study at university but still don’t know everything about Java…

You learn as long as you live, otherwise it would be kind’a boring :wink:

/Markus