I created a class that implements runnable and in my run() method is where I do my animation loop. I start the thread from my class constructor after everything is initialized. 2 questions…
Is this ok to do or will I run into thread problems later and how can I add a window listener so that I can be notified when the Xith container is closing so I can stop the thread first?
Thanks.
I didn’t got any problems when I start the thread (and the rendering) from the constructor.
For the shutdown I do the following:
…
windowClosing(WindowEvent ev) {
try {
myThread.interrupt();
myThread.join();
} catch (InterruptedException ex) {
}
dispose();
}
void windowClosed(WindowEvent ev) {
System.exit(0);
}
…
void run() {
try {
while(!Thread.interrupted()) {
…
}
} catch (InterruptedException ex) {
}
}
…
This will reult in a smooth shutdown without any GL exceptions because the canvas is only destroyed (by dispose()) after the thread has stopped and withit all GL commands.
Ciao Matthias Mann
Thanks. To what component to I call addWindowListener()?
I have concerns over this approach in general, having been bit by pc’s of various cpu speeds. If you doing any scene manip at all in a separate thread you stand a chance of updating the scene while its being rendered.
The best approach is to create a system of “scene transactions” in a queue and process some percentage of the queue each render cycle (percentage of transactions is a funtion of any required FPS, you may not be able to do everything in every cycle)
Unless your animstion thread is tightly synchronized with the render loop…trouble looms in the future. If you are using some form of sync then your frame rate may suffer.
For example suppose you are firing sheels at a bunker you might have a queue containing
0 - translate Shell A to x,y,z
1 - rotate turret Y 5 degrees
2 - update explosion particles 1 time
3 - increase output of light A 5% (for explosion affect)
in your render loop, pop the queue N time and perform until out of allocated animation time.
repeat…
jest a thought…my first version of my game had several threads, worked like a charm until run on a fast machine KABLAMM!!!
a further advantage is you can adjust translations etc based on the actual frame rate (when fast position change is in smaller incrementals, when slow move things farther each cycle. 6 steps moving 2 feet or 3 steps moving 4 feet…they both move you 12 spaces…
good advise hawkwind
Will.
[quote]jest a thought…my first version of my game had several threads, worked like a charm until run on a fast machine KABLAMM!!!
[/quote]
It gets even worse on hyper threading (or multiple) cpus…what works fine with just one cpu does strange things on HT machines.