Algorithm for Direction Change upon Collision

[Scott Rossi]

Ender:

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
"https://dl.dropboxusercontent.com/u/7192863/LCtest/swarm2.livecode"

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
idea.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 11/8/13 1:29 AM, "Ender Nafi Elekcioglu" <endernafi at gmail.com> 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
>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
>_______________________________________________
>use-livecode mailing list
>use-livecode at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode