Regarding Rob Romanek's reply to my solicitation for alternative methods:
Your method is pretty interesting -- I will need to review it and the articles you
reference more fully
to make sure I understand the whole concept. Certainly the movieVariable concept is
something I
had overlooked and will find useful in the future.
My method has a few features that yours does not seem to share, on the surface.
First, it allows me to create multiple
levels of groups that behave independently. I can dynamically address all "Display"
sprites, all "Option" sprites,
and all "Display" sprites that are also "Option sprites". I guess I could do the same
with your method by
finding the intersection of the group lists...
In the interest of brevity, I left out the fact that my method also allows the sprite
scripts to send messages to
the application, passing them through the "Sprite Msg Filter" script to tack on the
group identifiers -- kind of
like having a secretary put the return address on your letters. Again, I guess you
could work this in reverse --
the receiving method in the application looks at the sprite number, finds its entries
in the group lists, and tacks
them on.
Then there is the issue of indices. Do I really want to have a group list which
contains "Card 1", "Card 2", ...
"Card 52"? I can't really see any alternative with your system. Even if you create a
group called "Cards",
you just get a bunch of sprite channel indices, with no mechanism other than sorting
to determine which is
card 1 and which is card 52.
Finally, what about applications with dynamic creation/assignment of sprites -- like
in games, such as I'm
creating. For example, at random, every few seconds, I generate an asteroid, or maybe
a spaceship,
and send it onto the stage. I don't want to refer to the spaceship as "Asteroid", or
for that matter as
"Space Object of Unknown Type Number 5". Isn't it more logical to assign it
function="Actor", group="Enemy",
name="Asteroid", index=nextIndex ?
I'll have to think about whether these differences are more than just cosmetic.
Regarding the overhead issue -- I'd like to see an analysis of the overhead for the
following conditions,
using sendAllSprites to 100 sprites with identical scripts:
1. there are no scripts attached
2. there are <n> scripts attached, none of which has the handler being called
3. there are <n> scripts attached, of which one has the handler being called (but
contains no logic)
4. there are <n> scripts attached, of which one has the handler being called (but
contains no logic), and the behavior being called has <k> parameters expected and
passed
If you don't already have such an analysis, I will do one myself and let you know what
my results are. I suspect that the
overhead is quite low for conditions 1 and 2, but gets higher with 3 and 4.
[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!]
