 |
Author |
Topic: setTimeout (Read 1007 times) |
|
benelek
 
 
|
setTimeout
« on: Sep 18th, 2003, 10:28am » |
|
i'd love something equivalent to javascript's setTimeout(whatToDo,howLongToWait)
for the many things that in my sketches do not occur every turn of the loop(), i tend to have to put in framework like time-storage and time-checking to achieve this result, or some kind of custom threading as an alternative.
~jacob
|
|
|
|
|
arielm
|
Re: setTimeout
« Reply #1 on: Sep 18th, 2003, 11:53am » |
|
bonjour j,
for certain cases, it's definitely possible to achieve such behaviors without the need for threading stuff (this is the way it is done in the old video games, from space invaders to arkanoid...)
first (unlike in these old games) the idea is to work with objects, so in your loop(), you call run() for all of the active instances.
each Object is holding a kind of time counter, which gets updated at each frame.
based on this counter and other "state" information, the Object is responsible for deciding which task it will execute, at each call.
finally, your Object's class could look like:
Code:
Class Process
{
int time = 0;
void run()
{
if (time == 23) step_1();
else if (time == 39) step_2();
// etc...
time++;
}
void step_1() {}
void step_2() {}
}
|
|
the simple way to implement it is by using a lot of if/else or switch/case.
the more elegant/flexible/powerfull way is to use something called "reflection" in java, which enable to invoke methods by their (string based) name.
if "reflection" is used, it's possible to build a real "process machine", aware of it's current executing task, and with the option of dynamically switching between tasks.
hth
|
Ariel Malka | www.chronotext.org
|
|
|
mKoser
|
Re: setTimeout
« Reply #2 on: Sep 20th, 2003, 3:22am » |
|
ahh... yes, this indeed would be a nice feature, i use the equivalent of this in lingo (timer-objects) ALOT, and really miss (i seem to end up doing a bunch of counters, which seems to be a bit overkill!)
|
mikkel crone koser | www.beyondthree.com | http://processing.beyondthree.com
|
|
|
fjen
|
Re: setTimeout
« Reply #3 on: Jul 14th, 2004, 10:43am » |
|
easy ... use timer task and timer:
long timeWaiting;
Timer qtschedule;
boolean tryPlayingQT;
void setup () {
timeWaiting = 60 * 1000; // call in 60 seconds, this is NOT exact //
qtschedule = new Timer();
qtschedule.schedule(new qtTimerTask(this), timeWaiting);
}
void loop ()
{
if (tryPlayingQT) {;} // play external QT .. //
else {;} // do smthng else
}
public class qtTimerTask
extends TimerTask
{
<yoursketchnamehere> parent;
qtTimerTask (<yoursketchnamehere> _parent)
{
parent = _parent;
parent.println("New qtTimerTask started.");
}
public void run () { parent.tryPlayingQT = true; }
}
|
|
|
|
|
TomC
|
Re: setTimeout
« Reply #4 on: Jul 14th, 2004, 11:05am » |
|
Nice. I think you can tidy up the inner class though - it doesn't need to know about _parent explicitly.
I confess that I haven't tried it, but this should work in the same way:
Code:
long timeWaiting = 60 * 1000; // milliseconds
boolean tryPlayingQT = false;
Timer qtschedule;
void setup() {
qtschedule = new Timer();
qtschedule.schedule(new QTTimerTask(), timeWaiting);
}
void loop()
{
if (tryPlayingQT) {;} // play external QT .. //
else {;} // do smthng else
}
public class QTTimerTask extends TimerTask {
QTTimerTask() {
println("New QTTimerTask started.");
}
public void run() {
tryPlayingQT = true;
}
}
|
|
(Update: tried it now... it works).
|
| « Last Edit: Jul 14th, 2004, 12:33pm by TomC » |
|
|
|
|
arielm
|
Re: setTimeout
« Reply #5 on: Jul 14th, 2004, 3:35pm » |
|
just a small note:
you need the whole QuickTime for Java library installed in order to use this, which is a bit overkill and won't work on the web (applets don't like QT4Java, and anyway, it's probably installed only on ~1% of the machines out there...)
btw, java has a built-in mechanism (TimerTask I think)... i guess it's less accurate on windows because it use the standard low-resolution timer.
all in all, for most of the applications I can think of (except those with, say, a lot of network io): using a "schedulled tasks" pattern is a bad habit (e.g. if you want 100 sprites on screen doing different & complex things together, you're not going to use 100 timer-tasks, but a single-threaded / serialized approach...)
|
Ariel Malka | www.chronotext.org
|
|
|
TomC
|
Re: setTimeout
« Reply #6 on: Jul 14th, 2004, 4:44pm » |
|
on Jul 14th, 2004, 3:35pm, arielm wrote:just a small note:
you need the whole QuickTime for Java library installed in order to use this
|
|
Are you sure I think Timer and TimerTask are in the regular Java API (from 1.3 onwards at any rate). I assume the above TimerTask implementation is only called QTTimerTask because of where fjen used it originally. It could be called anything.
I agree with the rest of what you said, by the way. The single-thread approach is going to be far friendlier - but the TimerTask method can be handy, and for one or two things, so long as you don't do real work in the run method, it can be neat.
|
| « Last Edit: Jul 14th, 2004, 4:45pm by TomC » |
|
|
|
|
arielm
|
Re: setTimeout
« Reply #7 on: Jul 14th, 2004, 5:58pm » |
|
lol!
you're right tom: i was a bit misleaded by fjen's naming conventions!
|
Ariel Malka | www.chronotext.org
|
|
|
fry
|
Re: setTimeout
« Reply #8 on: Jul 14th, 2004, 7:35pm » |
|
there are two timers, one is java.util.Timer (and TimerTask) which are available in 1.3 and forward. swing also has its own Timer, so that's available in 1.1 but only if swing is also available (hrm).
as for a setTimeout.. it could be a useful thing, though i'll have to run it by casey, who heads up the syntax police. we've been bloating the api over here over the last week or two, so it could be trouble.
a simple timer could prolly also be done by making a thread that sleeps for the number of millis and then wakes up to perform a task. could prolly be done in a very small amount of code using an inner class.
|
|
|
|
|
fry
|
Re: setTimeout
« Reply #9 on: Jul 14th, 2004, 7:38pm » |
|
fwiw, i've also started surveying 1.1 versus 1.3+ java vms (nobody seems to be using 1.2, and for good reason), and things are still 60-40 in favor of 1.1 on pc.
(this is based on a few hundred people a day who visit http://acg.media.mit.edu/people/fry/zipdecode)
|
|
|
|
|
|
