Russ Pagel wrote:
>Your program has to be one of the most elegant programming examples I've
>ever seen!

I hope not. Elegant programming would use a correct algorithm.

>I think the problem is in FN TestCollides.  It occurs to me that some
>collisions set up an oscillation.

Your description of the pathology seems accurate. and I really like the
little vector lines in your replacement FN DrawBalls. But what is the cause
of the sticking-together disease?

After each ball is moved, the program finds at most one collision, ignoring
the fact that the new trial position may overlap additional balls. After FN
Backup, the moving ball is correctly placed with respect to the chosen
collidee, but sometimes it ends up overlapping others. Once you have an
overlapping pair, the algorithm does not usually recover :-(

It seems that one should determine which ball (or bounding wall) is hit
_first_ as the moving ball advances along its track.

Mark G suggested:
>optimizing Quickdraw itself by using FN SetStandardProcs

FB^3 understands the essential toolbox:   call SetStdCProcs(@CQDProcs)
so this should certainly be possible. It will require UNIVERSALPROC and
PROC to create a Universal Procedure Pointer to the replacement QuickDraw
procedure (in this case it would be PaintOval that you would want to
redirect to custom code).

Thanks to Al Boyd for the flicker-free animation. Much nicer to look at,
but this of course isn't part of the challenge.

Robert P.