 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2006robot gui approach
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? -- Mike W > I'm messing about with bot representations in a gui, because I've managed > to [quoted text clipped - 14 lines] > 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. > > I've got a bunch of autonomous objects that have there own threads and > > control there own movement. Speed of these objects is therefore [quoted text clipped - 18 lines] > [*] 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. -- Mike W >> > I've got a bunch of autonomous objects that have there own threads and >> > control there own movement. Speed of these objects is therefore [quoted text clipped - 27 lines] > 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 [quoted text clipped - 7 lines] > 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 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 [quoted text clipped - 41 lines] > -- > Mike W [...] > I've got a bunch of autonomous objects that have there own threads and > control there own movement. Speed of these objects is therefore [quoted text clipped - 3 lines] > 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.