Timing question

[Levendis]

I have a game that I've made using a java.util.Timer to deal with animations, performing the work of each frame in an actionPerformed method and just updating it about 30 times a second.  The result is pretty clean, but obviously all movements are based per frame as opposed to per timeslice.  I was wondering if there's anything especially wrong with this approach or if anyone had comments on tradeoffs between this and other approaches?
Also has sun fixed the high resolution timer yet?

^Thanks.

[Herkules]

I have a game that I've made using a java.util.Timer to deal with animations, performing the work of each frame in an actionPerformed method and just updating it about 30 times a second.  The result is pretty clean, but obviously all movements are based per frame as opposed to per timeslice.  I was wondering if there's anything especially wrong with this approach or if anyone had comments on tradeoffs between this and other approaches?

All depends on your needs. If the result looks ok, the approach is ok. It won't use more CPU than effectivly needed, is multithreading-friendly, lets the GC live - in this sense it even can be called 'advanced' compared to 'render-as-fast-as-you-can' things.

If time itself is an important term in you program (as it would be for a true simulation), you could measure the current time when called back by the Timer. There, again depending on your needs, the lowres clock System.currentTimeMillis() or the hires one com.sun.j3d.utils.timer.J3DTimer may be used.

At the bottom line I feel that's basically the Java way to design a gameloop.

Also has sun fixed the high resolution timer yet?

Fixed? It never has been broken (except for a short period in one beta).

[princec]

I'm keeping me mouth shut this time :x

Cas

Games published by our own members! Check 'em out!

[Herkules]

... although I think Levendis could be interested in what you have to say.

[princec]

... ok then.  

The other side of the coin is you do everything in a single thread - your main thread, in fact - read input, calculate, render, page flip, repeat.

This gives you the advantage of deterministic behaviour on all platforms, and actually makes your code a lot simpler to understand. It then depends on the style of game you are writing as to whether you tune for a specific framerate and use tick counting, or tune for a specific animation frequency and use hires timers. My personal recommendation is ticking for 2D and time for 3D.

If the page flip is a well behaved piece of code - like it is on my Nvidia cards for example - then other threads have their chance to run whilst the page flip occurs.

(And if you're really cunning and using OpenGL you'll also find that a lot of the drawing can happen asynchronously on the card at this point too - effectively giving you another processor to do all the pixel pushing work)

Cas

[Levendis]

I appreciate the responses, thank you.  What I'm doing is 2d, and the only threads not synched with the main timer thread is the input and going to be the networking; main thread just notifies all objects to move to their next step each iteration.  Specifically one thing i've noticed with the timer method is that as characters move faster the responses are twitchy because they move a certain number of pixels per frame, conversely I've noticed on consoles in 2d games that characters sometimes appear to be skating as opposed to walking because of the timeslice based animations.
Based on what you both have said i'm going to finish this using the timer and once i'm done i'll do a 3d project with time slicing.

When I started this I did it this way because it was a method of animation that made sense to me and the entire project was for my education's sake.  In the meantime I haven't seen any other examples that used this technique so I thought that maybe there lurked some hidden evil I hadn't thought of.

Thanks again very much for your insights.