Asynchronous control of many objects

[Jim Hurley]

Message: 21
Date: Wed, 12 May 2004 22:24:02 -0700
From: Scott Rossi <scott at tactilemedia.com>
Subject: Re: Asynchronous control of many objects
To: How to use Revolution <use-revolution at lists.runrev.com>
Message-ID: <BCC85482.DAEF%scott at tactilemedia.com>
Content-Type: text/plain; charset="US-ASCII"

Recently, "Jim Hurley" wrote:

>  I have a question about asynchronous movement of a large number of
>  graphic objects.
>
>  For example, consider a window with 50 graphic objects, perhaps 50
>  small spheres--balls.
>
>  I want to have all these objects moving asynchronously. The stack in
>  which this comes up can be seen by running the following in the
>  message box:
>
>  go url "http://home.infostations.net/jhurley/MultipleBalls.rev"
>
>  My problem is that I use the *identical handler* in *each* of the 50
>  balls. That seems inefficient. Is there a way to control a large
>  number of objects asynchronously without duplicating the handler in
>  each of the objects?

>There are many ways.  Here's one (type the following in your message box):
>
>   go url "http://www.tactilemedia.com/download/overkill.rev"
>
>See the card script for details.
>
>Snowglobe anyone?
>
>-----
>
>FWIW, in my experience, I've found that:
>
>1) Enabling each object to track its own position via its own code requires
>much heavier processor use than using one master script to move everything
>simultaneously.  I've locked up several Windows systems doing what you
>describe above, crashing Rev.  YMMV.
>
>2) Interestingly, locking the screen between each call to position multiple
>objects can also place a high demand on the processor; removing the lock
>screen is surprisingly less demanding and, if your objects are small enough,
>you won't notice much delay if any between the move of the first and last
>objects.
>
>3) Look at balancing the frequency of the message used to move the objects
>versus the actual distance moved.  Sometimes you can employ longer interval
>between moves with a longer distance moved to cut down on processor use, but
>too long a distance may produce jittery, unacceptable results.
>
>Depending on the size/type of objects, you may not be happy with performance
>beyond about 30 to 40 objects or so.  The above demo does indeed use 50
>objects and seems to perform acceptably on Mac OSX, but also appears to near
>max out the processor.  Watch out for this on Windows (on my systems, Macs
>seem to be more forgiving).  Again, YMMV.
>
>Regards,
>
>Scott Rossi
>Creative Director
>Tactile Media, Development & Design

Scott,

Thank you for the example and the analysis. It was a revelation! I 
had no idea that it was possible to sequentially move so many objects 
without it appearing that they were moving in sequence. It was for 
that reason that I gave each object its own code. That was probably 
naive since the processor must, in some sense, act sequentially on 
the objects.

I tried locking and unlocking the screen at the beginning and end of 
the repeat loop without noticeable effect. After the speed 
constraints of HC, I continue to be amazed at how quick RR is.

Jim