Algorithm for Direction Change upon Collision

Scott Rossi scott at
Fri Nov 8 15:16:34 EST 2013


I thought RunRev recently added something along the lines of a collision
message, but I can't find anything in any of the help references.  It
might be that intersect() is the only option available for collision, but
if so, it seems impractical to use it in a looping script on a lot of
objects.  Somebody like Geoff Canyon or John Craig may know a better way.

I tried to briefly play around with this and updated the swarm stack I
made a long time ago to make it run better.  It does fine detecting the
edges of the card, but when trying to detect all possible collisions slows
way down.
Message box:  go url

Changes added:
- object arrays
- moving objects are now images with dynamic layerMode
- acceleratedRendering for the stack

There is a rudimentary collision handler in the card script than can be
turned on/off, and the performance difference is substantial.  Without an
engine-based message devoted to collision, I don't immediately see a way
to handle this efficiently.  But again, somebody else may have a better


Scott Rossi
Creative Director
Tactile Media, UX/UI Design

On 11/8/13 1:29 AM, "Ender Nafi Elekcioglu" <endernafi at> wrote:

>Hi folks,
>I¹m dealing with this problem for a week now and I am officially stuck.
>A little push, any insight would be great.
>It¹ll be a particle animation {sparkle effect} for an iOS app.
>But for the base structure, I¹m trying to make it dead simple;
>so, think an Airhockey game in which there are ~20 pucks constantly
>colliding and changing direction.
>TactileMedia¹s excellent ³bouncer2.rev² stack doesn¹t help, Œcause it¹s
>performance falls short for my situation.
>Try it with 4 balls instead of 2 and it starts to crawl. I need at least
>AnimationEngine doesn¹t help much, its performance is not sufficient
>enough, likewise.
>I had to write my own handlers.
>Good news is, I managed to achieve 100+ balls at 30fps without collision
>detection and near 40 balls at 30fps with collision detection.
>Bad news is, my collision handler doesn¹t work correctly, hence this
>question :)
>Here¹s my algorithm:
>* on openCard
>-> create pucks
>-> set its speed random as a custom property
>-> set its destination / direction random as a custom property
>-> put the long id¹s into an array for further calculations
>* on each screenUpdate
>** for each puck
>-> check any collision via intersect()
>-> if yes, update the speed and direction of both collided pucks
>-> move each puck {either with updated or standard params}
>The problem is: collided pucks can¹t get the chance to move in their
>fresh updated directions.
>Apparently intersect() has 2 - 4 pixels threshold; actually it¹s not a
>threshold, well, I don¹t know what it is.
>Probably, it¹s related to the speed of the pucks and screen update delay.
>I¹ve recorded the stats and looked at the collided grcs¹ rects;
>I see that they¹re not precisely side-by-side. One¹s right is 202 and the
>other one¹s left is 198, for example.
>Back to the problem:
>They collide, 
>collision handler updates their direction,
>but in next screen update they¹re still collided because of the
>aforementioned issue,
>so their directions are getting transposed again, and again, and again, Š
>After 20 - 30 seconds, all pucks are gathered somewhere just trembling
>I know that I have to create a flag as a custom property saying ³this
>puck¹s already handled, don¹t check it² to the intersect() function.
>But no matter which path I chose to accomplish this, it became dead end.
>Any quick ideas, anyone?
>Thank you very much,
>~ Ender Nafi
>use-livecode mailing list
>use-livecode at
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:

More information about the Use-livecode mailing list