Algorithm for Direction Change upon Collision

Jim Hurley jhurley0305 at
Fri Nov 8 06:55:24 EST 2013

Hi Ender,

You might want to check out a stack I put  up on "User Samples" some time ago titled "Two ball collisions". It was written to deal with the basic physics of collisions between pool balls, but the dynamics  is the same as hockey pucks. 

This stack provides a function that allows one to allow for collisions between circular graphic objects.  It is based on the physics of an ideal, elastic collision in which the total momentum and energy are conserved. Given the position and velocities of each ball just before the collision, the "getVel" function will return the velocities of each ball just after the collision.

Also there is a couple of versions of Nine Ball pool on my web site:

Run Rev is up to the task of 9 (actually 10 including the cue ball) colliding balls.  I don't know about 20.


> Message: 8
> Date: Fri, 8 Nov 2013 11:29:29 +0200
> From: Ender Nafi Elekcioglu <endernafi at>
> To: LiveCode Support <use-livecode at>
> Subject: Algorithm for Direction Change upon Collision
> Message-ID: <etPan.527caef9.6b8b4567.184c5 at fdbqMacBookPro.local>
> Content-Type: text/plain; charset="utf-8"
> 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 20.
> 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 crazily.
> 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
> ----

More information about the Use-livecode mailing list