Further info regarding Rob Romanek's reply to my solicitation for alternative methods:
Rob,
I have some very interesting test results using a hybrid of your technique and my own.
Essentially, I have used your technique, with the following changes:
1. Rather than each script instance registering itself, my old faithful "Sprite Msg
Filter" registers itself.
2. The "Sprite Msg Filter" script registers itself under 4 categories: "F_<funcname>",
"G_<groupname>",
"N_<namename>", and "I_<index>".
3. When I query the registration database, I query for the intersection of the
categories I'm interested in; at
the moment it is by intersection only, no union-ing allowed.
4. I take the list of script instances returned from step 3, and send each of them a
message using the call syntax.
The message takes, as a parameter, a list of parameters for the ultimate behavior
destination.
5. The receiving method in each called instance of "Sprite Msg Filter" uses sendSprite
to broadcast to the
other script instances of its sprite. It parses the list of parameters to do so,
using lst[1] as the behavior to
be called, and the others as additional parameters.
The single major difference is that it is the "Sprite Msg Filter" that is registered,
and that the commands to
the target behaviors still pass through "Sprite Msg Filter". The major improvement is
that I don't have to
compare identifiers on a sprite-by-sprite basis, but can use the registered values
instead.
In a worst case scenario of 300 sprites, each of which correctly responds to the
command, the average
time for completion is about 10 milliseconds, of which 3 milliseconds is consumed
preparing the script
instance list, and the other 7 in issuing the call and sendSprite commands. In a
not-so-bad case more
typical of my own applications (52 cards in a deck all receiving the same command),
the time is linearly
proportional -- about 1.5 milliseconds.
I consider these times to be pretty reasonable. Most of the times I broadcast general
instructions to large
groups of sprites (the bad cases), it is on some sort of mode transition where the
extra command time is
likely to be overwhelmed by a much larger lag due to loading and drawing sprites.
In exchange for this overhead, I get some benefits that I don't think your method has
in its pure form:
1. Sprites can have multiple groups
2. Sprites can have dynamically assigned groups that change over time
3. The only script that needs to know about the identifier strings is the "Sprite Msg
Filter" script -- write it
once, stick it in a library and just attach it to sprites you'll want to address
4. I can use this method to pass commands to library scripts without modifying the
scripts.
5. The "Sprite Msg Filter" script serves double-duty, as it also adds "From"
information to messages
sent to the application from sprites.
6. Because I only register the "Sprite Msg Filter" script rather than every script, my
script database may
well be smaller and more easily searched.
Please, if I am wrong about one of the above points, or if you feel that my times are
too large
to accept, let me know. There is probably still some optimization I could do, too.
On the other
hand, if you are interested in seeing some code that demonstrates the method, let me
know -- it's
pretty kludgy right now, but seems to work correctly.
Thanks for the pointer to your article --my method is definitely BASED largely on your
method.
--
Michelle Elliott
Director of Game Development
WickedWare, LLC.
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
