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.