robot gui approach

[VisionSet]

I'm messing about with bot representations in a gui, because I've managed to
miss out doing that kind of thing. How?!

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?

 

[Oliver Wong]

I'm messing about with bot representations in a gui, because I've managed
to
miss out doing that kind of thing. How?!

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.

 

[VisionSet]

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?

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.

 

[Oliver Wong]

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

 

[Boris Stumm]

VisionSet wrote:
[...]

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. [...]
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?

Try the Observer-Pattern (java.util.Observer, java.util.Observable).
Gui = Observer, Bots = Observables.

Or, take the Swing approach, and use Listeners.
This way, your Gui will only repaint if something changes, and you can
even optimize that to only repaint the part that has changed.

 

[gwlucas]

Quite awhile ago, I wrote a robot simulator in Java. It is now quite
obsolete
both in terms of Java practices and having been bypassed by other
simulator
projects, but you may find some useful ideas in some of its concepts,
particularly the simulator task queue. At the time it was written,
Java had a big
overhead problem with mutex locking and synchronized methods.
The way tasks were managed was a way of reducing the problem.

The thing that might be most relevant to you is the way
animation rendering was treated as just another simulation task that
could be scheduled via the task queue.

See http://rossum.sourceforge.net/sim/

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?

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.