Algorithm for Direction Change upon Collision

[Scott Rossi]

Ender:

My codez r lame.  :-)  Guys like John Craig, Jim Hurley, Geoff Canyon, and
others have done great things with animation/motion.  But I'm glad if you
got something useful from the stack.

Related to this discussion, I will make a sacrilegious comment that I've
been wanting to make for a long time:
The whole notion of locking the screen in the LiveCode needs to go away.

Now, before you break out the pitchforks and torches, let me qualify my
statement.

I'm not saying we shouldn't be allowed to lock the screen to make updates
invisibly.  That's fine.

But when doing things like moving objects, animation, setting the scroll
of a scroller, screen transitions, or anything that involves updating
multiple elements in a stack at once, locking the screen should not be
necessary.  It places too many limitations on how objects must be handled,
limits how many objects can be handled at once, and makes the detection of
user input during the transition near impossible.

How nice would it be to be able to script "move object 1 across this card
in 1 second and move object 2 halfway across this card in 2 seconds" while
setting the blendLevel of each object to varying levels, and maybe bring
an image or two into view.  In other dev environments, these kinds of
events are essentially handled automatically, without the developer having
to do the screen lock dance: lock the screen, make some small changes,
unlock the screen; lock the screen, make some more small changes, unlock
the screen, etc.  It's just not necessary, and in an ideal world, it
shouldn't be necessary in LiveCode.

The way things stand now, we will never be able to reproduce the
multi-element transition that occurs on iOS, for example, when switching
views with a nav bar: the elements in the nav bar change position and
change transparency, while the main content of the screen changes to a
different view.  There are simply too many changes of different types and
timings going on that LiveCode just can't handle.

I'm waiting for the day we won't be locked out of development options by
screen locking.

OK, now cue the pitchforks and torches.

lock screen for visual effect
exit soapbox
unlock screen with visual "run away" very fast

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design



From:  Ender Nafi Elekcioglu <endernafi at gmail.com>
Date:  Friday, November 8, 2013 1:06 PM
To:  LiveCode Mail List <use-livecode at lists.runrev.com>, Scott Rossi
<scott at tactilemedia.com>
Subject:  Re: Algorithm for Direction Change upon Collision


>Scott, you¹re the man :)
>
>Interestingly, my collision code was exactly same as yours
>{I mean the intersect() section, swapping the directions and all},
>EXCEPT 
>that teeny, tiny line of *exit repeat* :))
>
>It solved the whole thing.
>
>I mean, almost...
>There are some little glitches but nothing which can¹t be handled.
>Occasionally some pucks can escape off the screen boundaries
>and again occasionally some pucks overlap each other.
>Yet, after a while they release from themselves.
>
>Performance is pretty good, too.
>I could go up to 32 huge pucks at a 28 fps speed.
>More than 32 pucks, refresh rate drops significantly.
>But I need just ~20 particles and they will be tiny.
>
>I still need to improve it by implementing Jim¹s, Mark¹s and Bernd¹s
>suggestions.
>There will be small sprite animations, thus I need efficiency and
>optimization.
>
>
>Anyways, thank you very much.
>
>
>-> one more thing:
>Do you think falling back to C++, writing some code snippets for
>performance driven sections, could help this kinda situations?
>Passing the locs to a dedicated C++ collision detector external and
>getting the result, maybe?
>Although on a second thought, the intersect() itself is written in C++,
>right?
>So, what are the odds that I can write more efficient / faster code than
>RunRev team?
>Perhaps, this last question deserves a separate thread; still I wanna
>hear your { plural :) } thoughtsŠ
>
>
>Kindest Regards,
>
>~ Ender Nafi