How to make my objects do something after a period of time elapses?

I can't use System.getCurrentMillis, theads aren't acurate. What do I use?ANd when should I use threads? I normally have one that other than main that does the rendering and makes calls to object methods. Is that all I need?Thanks
[253 byte] By [Virum] at [2007-9-27 16:09:05]
# 1

do you mean in a game?

how is your game loop constructed?

For its timing is it using Thread.sleep() or Object.wait()/Object.notify() or System.currentTimeMillis().

Each has its only advantages/disadvantages

Thread.sleep() is wasteful (the CPU isn't 100% utilised)

Object.wait()/Object.notify() involves alot of task switching (which is expensive)

System.currentTimeMillis() is inaccurate for low resolution timing (if your update interval is around 100 times a second, animation will be stutterey - though why you'd want to be updating at 100Hz is beyond me - 50Hz is more than adequate for most java games)

rob,

p.s. I can give an example of all 3 mechanisms if it will help.

Abuse at 2007-7-6 0:27:48 > top of Java-index,Other Topics,Java Game Development...
# 2

Try java.util.Timer. Works like a charm for UI-scale times, but may not be able to keep up with a Java3D app.

You'll want at least two threads, maybe more. Try one to keep the UI live, one to run the game logic, and perhaps one to talk to other (slower than memory) things like the network or disk.

Dave

dfw at 2007-7-6 0:27:48 > top of Java-index,Other Topics,Java Game Development...
# 3

Yes, thsi is for a game.

Abuse,

What yould you use? You are a commercial (I think) game developer, even if you do it in C++. What would you most likely use in a java:

1. Arcade?

2. Animated Board game?

3. RTS?

Timers use threads, so I don't think that that is a good solution either.

What is UI?

Virum at 2007-7-6 0:27:48 > top of Java-index,Other Topics,Java Game Development...
# 4
> What is UI?User Interface.
mlk at 2007-7-6 0:27:48 > top of Java-index,Other Topics,Java Game Development...
# 5

> Yes, thsi is for a game.

>

> Abuse,

>

> What yould you use? You are a commercial (I think)

> game developer, even if you do it in C++. What would

> you most likely use in a java:

I develop for java enabled mobile phones at the moment - so performance is the priority concern for my work.

An important issue to note, is that at present all HCI (Human Computer Interaction) is managed through the event scheduler, which executes in a seperate Thread.

This is not ideal - and many ppl would prefer a mechanism where by the states of each key can be polled each game loop (as the state of the key only needs to be known during the update cycle)

>

> 1. Arcade?

as in arcade game? (SWIV type game?)

well, it being 2d sprite based, you dont need a massive update rate on the game i'd say an update rate between 20-30HZ would be sufficient (thats an update every 50-33ms)

at those sorts of values, the inaccuracy of System.currentTimeMillis() shouldn't be a major factor. So a loop similar to this would be sufficient.

int currentTime, period = 50;

boolean paintNeeded=false;

public abstract void gameUpdate();

public abstract void paintUpdate();

public void run()

{

currentTime = System.currentimeMillis();

while(running)

{

if(nextCycle())

{

gameUpdate();

paintNeeded=true;

}

else if(paintNeeded)

{

paintUpdate();

paintNeeded=false;

}

}

}

public boolean update()

{

if(System.currentTimeMillis() - currentTime > period)

{

currentTime += period;

return true;

}

return false;

}

> 2. Animated Board game?

Well a standard board game (that contained no animation) could have its entire painting system linked to each User input event (similar to the way the AWT/Swing refreshes itself)

but if you need animation, then your gonna need a Thread, to execute the animation repaints (in a similar way to 1.

> 3. RTS?

2D or 3D?

2D, the animation/game loop update system would work just as well as in 1.

3D, your probably going to run into trouble with the accuracy of currentTimeMillis() (when dealing with 3D, the eye is more aware of frame rate anomalies [*spelling])

there are ways around it - you could use a native function to access the more accurate system clock. Alternativly, you could try checking out other timers that are implemented in several J2SE extensions (supposedly the Timer in the JMF has nanosecond precision...) this solution is not particularly useful if you want other ppl to play your game however :P

>

> Timers use threads, so I don't think that that is a

> good solution either.

No, Timers are not good - they perform an identical task - but there is alot of bloat code in there that slows them down,

But, you are going to have to have a Thread somewhere - animation cannot happen simply by magic ;]

>

> What is UI?

As stated above... User Interface

You never wondered what GUI stood for? (Graphical UI :)

rob,

p.s. there is another solution to the issue of timing, I posted some code that implemented it a few weeks ago.... let me find a link...

http://forum.java.sun.com/thread.jsp?forum=406&thread=285522&start=15&range=15

Abuse at 2007-7-6 0:27:48 > top of Java-index,Other Topics,Java Game Development...
# 6

> > Yes, thsi is for a game.

> >

> > Abuse,

> >

> > What yould you use? You are a commercial (I

> think)

> > game developer, even if you do it in C++. What

> would

> > you most likely use in a java:

>

> I develop for java enabled mobile phones at the moment

> - so performance is the priority concern for my work.

>

> An important issue to note, is that at present all HCI

> (Human Computer Interaction) is managed through the

> event scheduler, which executes in a seperate Thread.

> This is not ideal - and many ppl would prefer a

> mechanism where by the states of each key can be

> polled each game loop (as the state of the key only

> needs to be known during the update cycle)

>

> >

> > 1. Arcade?

>

> as in arcade game? (SWIV type game?)

>

> well, it being 2d sprite based, you dont need a

> massive update rate on the game i'd say an update rate

> between 20-30HZ would be sufficient (thats an update

> every 50-33ms)

>

> at those sorts of values, the inaccuracy of

> System.currentTimeMillis() shouldn't be a major

> factor. So a loop similar to this would be

> sufficient.

> >

> int currentTime, period = 50;

> boolean paintNeeded=false;

>

> public abstract void gameUpdate();

> public abstract void paintUpdate();

>

> public void run()

> {

> currentTime = System.currentimeMillis();

> while(running)

> {

>if(nextCycle())

>{

>gameUpdate();

>paintNeeded=true;

>}

>else if(paintNeeded)

>{

>paintUpdate();

>paintNeeded=false;

>}

> }

> }

>

> public boolean update()

> {

> if(System.currentTimeMillis() - currentTime >

> e > period)

>{

>currentTime += period;

>return true;

>}

>return false;

> }

>

>

>

> > 2. Animated Board game?

>

> Well a standard board game (that contained no

> animation) could have its entire painting system

> linked to each User input event (similar to the way

> the AWT/Swing refreshes itself)

>

> but if you need animation, then your gonna need a

> Thread, to execute the animation repaints (in a

> similar way to 1.

>

> > 3. RTS?

>

> 2D or 3D?

>

> 2D, the animation/game loop update system would work

> just as well as in 1.

>

> 3D, your probably going to run into trouble with the

> accuracy of currentTimeMillis() (when dealing with 3D,

> the eye is more aware of frame rate anomalies

> [*spelling])

>

> there are ways around it - you could use a native

> function to access the more accurate system clock.

> Alternativly, you could try checking out other timers

> that are implemented in several J2SE extensions

> (supposedly the Timer in the JMF has nanosecond

> precision...) this solution is not particularly useful

> if you want other ppl to play your game however :P

>

> >

> > Timers use threads, so I don't think that that is a

> > good solution either.

>

> No, Timers are not good - they perform an identical

> task - but there is alot of bloat code in there that

> slows them down,

>

> But, you are going to have to have a Thread somewhere

> - animation cannot happen simply by magic ;]

I know I need thread for animation. Right now we are talking about timeing. I was just saying I can't tell it to wait or sleep for a short time, because that won't always work, the thread might sleep for that time, but not start running again after the sleep period, another thread might be running during that period. I think this is a problem when the CPU are handles threads in the tims-sliced manner. You get what I mean by not wanting to use threads to determine if it is time to make the next step in the animation?

> > What is UI?

>

> As stated above... User Interface

>

> You never wondered what GUI stood for? (Graphical UI

> :)

Heck, I always new what that was. I've never seen it without the G though. I just wanted to know for sure it wasn't something different.

> rob,

>

> p.s. there is another solution to the issue of timing,

> I posted some code that implemented it a few weeks

> ago.... let me find a link...

Thanks, I will look at that later. :)

>http://forum.java.sun.com/thread.jsp?forum=406&thread=2

> 5522&start=15&range=15

Virum at 2007-7-6 0:27:48 > top of Java-index,Other Topics,Java Game Development...
# 7
Thank you for the example to, I have already used that though. All I wanted to know it is acurate enough for a arcade and small RTS game.ANybody else have any opinions?
Virum at 2007-7-6 0:27:48 > top of Java-index,Other Topics,Java Game Development...
# 8

I haven't heard too much of threads not being accurate, but problems do start to occur with multithreading applications as it's OS dependent and the number of threads that can be created vary. I try to stay away from creating many threads. Sometimes you can get away with a single thread. This is just my suggestion, but for creating an RTS, I would use threads, but that's just me. Abuse has experience with this kind of thing, so listen to him :P

Ceranith at 2007-7-6 0:27:48 > top of Java-index,Other Topics,Java Game Development...