Re: robot gui approach
"VisionSet" <spam@ntlworld.com> wrote in message
news:hOmJg.165$WV2.112@newsfe2-gui.ntli.net...
"Oliver Wong" <owong@castortech.com> wrote in message
news:l9jJg.19567$365.17537@edtnps89...
I've got a bunch of autonomous objects that have there own threads and
control there own movement. Speed of these objects is therefore
controlled
by how often I update (x ms) there position and how far I move them (y
pixels).
I have one overall controller of the gui that maintains a collection of
these objects and has its own thread that just calls paint() every z
ms.
So now I have 3 variables (x, y, z) to err... vary.
This makes it a nice OO design, but harder to control from an animation
perspective. For example it is easy to get jerky movement or excessive
paint calls for zero movement. Any tips please?
Ditch the multithreading and write your animation as a
singlethreaded[*]
app.
- Oliver
[*] Swing may create various worker threads in the background, but I'm
saying that you should not be creating any threads in your own code.
Though any of my threads are coaleseced onto the event thread.
Anyhow what you are saying is effectively - Have one thread to paint and
poll other objects for their position. Therefore it is this polling that
provides a 'clock cycle' for the autonomous objects. They know to go y
pixels when polled. Is this what you are getting at Oliver?
Yes.
I'm less interested in the best Swing approach more interested in the
modeling of the objects, so thought that they should not be reliant on a
view tiers polling?
If I keep the gui poll at a higher rate than any model tier update rate it
seems to behave nicely. The view can always ask the model what its minimum
rate should be.
I don't have a ton of threads, I realise this is bad. More, one thread
manages a group of related objects. I'm trying hard at cohesive design at
the moment.
If you're going for an accurate simulation, you may have to choose to do
non-realtime rendering. For example, when scientists are modeling the
interactions of particles, they usually want something like nanoseconds or
less between each frame, since the particles are moving so fast. That leads
to something on the order of a billion frames per second, which their
computers can't handle. So they pre-render it such that a 3 second animation
might take 3 weeks to produce, and then save it as a video file to review.
- Oliver