 | | | dynamic sprite creation and imaging lingo | dynamic sprite creation and imaging lingo 2003-11-29 - By Robert Tweed
Back
-- -- Original Message -- --
From: "Rasmus Keldorff (XP)" <rasmus@(protected)>
>
> Director should have a dynamic sprite allocator, or we should come up with
> a universal one that everyone can use.
I'm planning to try something like this when I've got a bit of free time
(along with about 5 million other things on my list ;) and add it to the
openLingo library.
> I have never experienced any bugs
> with puppetsprites... except if you try to mix a puppeted sprite with
> features intended for 'normal' sprites. The only problem I've ever had is
> how to reliably unpuppet a channel from Lingo.
Since I am the usual person to respond to questions about dyanmic puppets in
m.d.l, I've built up a fair amount of knowledge of this subject.
The best way to "unpuppet" a sprite (if it was created dynamically) is to
set the member to VOID, the cursor to 0 and the scriptInstanceList to [].
This effectively destroys the sprite - although not entirely.
The main problems with dynamically puppeted sprites are:
- Some features simply *do not work*. So far, the only concrete example I
have found of this is a problem with more than one cursor appearing in
dynamically added text members. The problem does not occur if the text
members are placed in the score instead of created dynamically. From
problems reported by others, I believe there are also a lot of similar
issues with Flash members.
- Some features work, but only after the stage has updated. Back to text
members again, the keyBoardFocusSprite is an example of this. For one
project, I needed to use a setKBFocusSprite function, which set a property,
which my frame script then used to set the keyboardFocusSprite on the
following prepareFrame. updateStage sometimes helps with this type of
problem, but sometimes it doesn't work.
- Some properties of the previous sprite will hang over if the sprite
channel is reused later. For example, if you create a rectangle dyanmically
and remove it, then put another rectangle in the same channel later, it will
retain the rect of the old sprite. The way around this is to set all
properties that you ever use when creating new puppets, since you cannot
"unset" any property of a dynamic puppet. In particular, this problem can
cause the width and height properties to not work correctly, when they would
have worked otherwise. I find it is a good idea to set the rect instead.
- The aforementioned problem may be worse if the type of the sprite is
changed. Officially, when you puppet a sprite you can change any property
for that member type, but you cannot change the member to a different type.
This is why dymanic puppets remain unsupported: they have no initial type,
so in theory have no properties whatsoever. In fact, if you want to change
the type of a sprite at runtime, you are better off doing it with no sprite
in the score initially because the problem is worse still if you try to
change the member type from whatever is set in the score.
The last two problems are generally not an issue if you create the sprite
and wait for the following frame before setting any properties. This is the
best way to avoid most issues with dynamic puppets, but isn't suitable for
all situations, and doesn't fix absolutely everything (esp. the annoying
cursor bug).
Effectively, Director doesn't recognise that a dynamic puppet exists until
the stage has updated, and may consider values for whatever sprite was in
the channel before valid when they are not (this is not a problem when using
the channel for the first time though).
- Robert
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
dirGames-L mailing list - dirGames-L@(protected)
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames-l
Earn $52 per hosting referral at Lunarpages.
|
|
|