----- Original Message -----
From: Karina
> Mark & Colin - Thanks :)
On behalf of me, your welcome. I'm sure Mark says your welcome as well;-)
<Snip>
>
> Aha, but since all three of them happen only once in a "cycle", unless you
> want to use more then one at a time, would that fact in itslef make a
> difference?
Beg your pardon??? Not entirely sure what you are getting at here. Your
right that all three events (prepare, enter and exitFrame) are called each
time the playback head moves through a frame. I think the point is if you
need to execute something in a frame and test the result before the screen
has drawn then use prepareFrame, otherwise if you don't need to test a
condition before the screen has drawn then you may find no advantage to
using the prepareFrame. If that is the case then you might get by perfectly
well with using an enter or exitFrame handler and see no inherent advantage
(or disadvantage) to using the prepareEvent handler.
> > > Is there a specific advantage for something to happen on
> > prepare frame?
> >
> > There can be. The prepareFrame event is called before the
> > sprites in that
> > frame have a chance to draw on screen. Therefore you can
> > write some lingo
> > in the prepareFrame handler that will manipulate your sprites
> > and test the
> > results of that manipulation before they actually had a
> > chance to draw (or
> > redraw) on screen.
>
> Does that mean that you can change the loc of a sprite and then test for
> (say) intersect without doing an UpdateStage?
Bingo! In fact, updateStage does not even work in the prepareFrame handler
because there is no stage to update (so too speak) at this point. Think of
prepareFrame as the script that the actors run through in rehearsal before
they go on stage. You can test out things, find out what works and doesn't
work, and then have them execute it on stage later. Not a rock solid
analogy but hopefully you're seeing the point.
>Or do you mean change the loc
> on exitFrame, and then test the intersect on prepareFrame?
Nope, ya can do it all in the prepareFrame.
> > One example could be collision detection. Example: In the
> > prepareFrame you
> > could move a sprite, test to see if that sprite has moved
> > into (collided
> > with) another sprite and reset its position accordingly. All
> > before the
> > sprite has had a chance to be drawn on screen. Not the best
> > way to handle
> > collision detection mind you, but not terribly bad depending
> > on the scope.
>
> erhmm... Don't want to be a nag, but why isn't it the best way and what
> would be?
Nag away:p
It really does depends on the scope. Usually, I have only ever had to do
simple collision detection although a little while back I was working on a
more complex billiard table concept and quickly realized that my simplified
collision detection was not going to cut it.
Example:
If you don't have a lot of objects to test collision detection and the
objects move in a grid like manner (think Maze and perhaps using the arrow
keys to move the object through the maze at a set pixels/key click) then
using this method is quite acceptable IMO. In the prepareFrame you can move
the object in the maze let's say 20 pixels to the left in response to the
left arrow key being pressed. Test to see if that object has collided with
a wall and if it has then place it back from where it came from. This all
happens before the sprite has been drawn on screen so all your audience will
see is that the sprite does not move to the left when there is a wall next
to it. This could have been done in the enter or exitFrame handler but not
as easily and if you are not careful you would have actually seen the sprite
move into the wall and jumped back... maybe not on a fast machine but
certainly on a slower machine. The neat thing about prepareFrame is that it
does not need to wait for the stage to update to see what is going to
happen.
In more complex situations where you have more sprite objects to collision
detect and/or the objects move at different rates of speeds then this sort
of collision detection may become impractical (read: slow) or downright
unusable. Such as, what if an object's rate of speed is fast enough that in
one frame redraw it is before another object and in the next frame redraw it
has moved clean past the other object... the intersect function would never
return TRUE and it would appear that the one object moved through the other
object. In this case you will probably want to use vector maths to track
motion and possible collision outcomes. I started this a ways back and had
some minor success but had to shelf it due to other projects. There are
many others who have WAY more experience on this sort of collision detection
than I do (I'm sure that some of them are on this list but they tend to
congregate on the DirGames list).
Anyway I hope that this helped clarify the prepareFrame thang (or at the
very least I did not serve to confuse you more).
Hasta...
ck
[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!]
