Click to See Complete Forum and Search --> : [Resolved] [Resolved] REQUEST: Billiard balls phisics...

03-15-2002, 08:15 PM


03-15-2002, 08:51 PM
I don't have a finished Billiard game but if you check the collusion of two balls by their distance (hit if distance <2*radius of two balls), use some of the stuff here:

And use vectors for the speed of the balls and the speed they give to other balls when they hit them, you could do a pretty good billiard game.

But maybe someone has the source of a finished game, would be easier ;)

03-15-2002, 11:35 PM
Yes Don I spoted this one..the problem is that the bounce off is not that simple. I think there was a formula which calculates bounce agnle depending from the agle at which the balls touch plus there was some momentum preservation, elastic collision in 2D .complicated..:D


Ed Mack
03-16-2002, 01:36 PM
I was just playing with some bouncy balls there (very educational, right up there with slinkys). They appear to swap momentum, so the slow one goes fast and the fast one goes slow. The ball collision equation: R = 2W - P seems to work well enough. But, of course I'm sure this isn't true to nature.

03-18-2002, 11:34 AM
Hey Mad-Sci,

You might wanna have a look at:


Dunno if this it's any help, but there seem to be some formula's there...

03-19-2002, 04:22 PM
The real trick is going to be interpolating the positions of the balls to find out when they would have contacted had they not skipped past the moment of collision. Momentum won't be a huge deal since all the balls are of equal mass. So mass cancels. So total x velocity just before coll=total x velocity after coll. Just before and just after because It'll need friction, which can be faked at any desired level of complexity. I like just multiplying the x and y velocities by .9 or .8 or something.


you really have to zoom in to see that these two balls are never 2r apart, they go from >2r to <2r in one frame. I worked on this about 2 months ago, I'll look for my notes because now that there's a Math and Physics forum...

03-19-2002, 05:52 PM
jobe makar give an excellent excellent discussion of this whole topic in flash super samurai.

03-23-2002, 11:43 AM
I was playing pool last night, and decided to watch the balls a little more closely....It does look very difficult.

Simply doing accurate and fast hittesting is enough of a headache.

Still, I'm going to have a go. Probably best to start off with a good hittest, and a basic bounce, then work out rebound angles and momentum afterward.

Then there's spin, which REALLY messes things up.

I imagine that a good pool game in flash would require some convincing pseudophsics, rather than using any of newton's equations etc.

I've just put this together in flash, it looks neat, but it's useless at the moment, as the balls don't collide, I'll post again as soon as I've got some kind of hittest/rebound thing going on.


Use enter to accelerate the balls, if you want to play around with it, here's the source:


Ed Mack
03-23-2002, 04:44 PM
I saw an example where when two balls hit they swapped angles and speeds.

03-25-2002, 01:34 PM
Just found this, a working example in flash:


Interestingly, you can adjust the accuracy of the physics if the game runs too slow, and the lag is only noticable when balls collide.

I'm still figuring it out.......

03-25-2002, 01:51 PM
it's definitely not just a matter of swapping speeds or reversing directions. it is all covered in conservation of momentum. you have to know the mass, angle and speed of each ball, then determine the angle of collision (angle between the two balls at point of impact) and figure out how much of each ball's momentum lies along this line. then figure out how much momentum each ball transfers to the other, figure out the resulting momentums along that line, then translate back to world coordinates. again, jobe makar describes it very very well in super samurai. almost to the point where it is understandable for us mortals. :)

03-27-2002, 09:36 PM
OK, I have not posted much on here, but I am an undergraduate engineer, and I just studied collisions in physics, so I may be of some help.

All collisions are is a transfer of "momentum". People misuse words everyday, so momentum can be defined as
p = m * v
where p is momentum, m is the mass, and v is the velocity.
V(velocity) is a vector quantity which means not only does it have a magnitude (number), but it also has a direction. This means the p (I will refer to momentum as p for the rest of this post) also must have a magnitude and direction.

Now onto collisions. There are two types of collisions: inelastic, and elastic. In an inelastic collision, the two objects stick completely together. In an elastic collision, the two objects do not. Elastic collisions are obviously the type between two billiard balls.

It is a fundamental law that in an elastic collision (which is also one with no outside forces), linear momentum is conserved. This means that the momentum before the collision must be equal to the momentum after the collision. Now onto some fundamental equations. These are the equations for a two object elastic collision where
m1=mass of object 1|m2=mass of object 2|v1=velocity of ball 1|we are assume right now that object 2 is stationary.

final velocity of ball 1= ((m1-m2)/(m1+m2))*v1
final velocity of ball 2= ((2*m1)/(m1+m2))*v1

Looking at these equations, one can see that if the two objects are of equal mass, then the final velocity of ball 1 will be "0" where the final velocity of ball 2 will be the initial velocity of the first ball.
You may be thinking to yourself, "But I have played pool before, and the cue ball still have a small velocity on it after hitting another ball." This is because of two reasons. The first is simply that the cue ball is actually a fraction bigger than all of the other balls. This mostly helps commercial ball returns. If you look at the equations, you will see that the final velocity for object 1 if it is just a little bigger than object 2 will be very small. Lastly, the collision is not completely elastic. No collision will ever be completely elastic because the balls bend in a little on contact. You can't see it, but they do, and that absorbs a tad of the momentum.

Now, what if the second ball is also moving? This is where it gets difficult. If the balls are rolling together, do you have to use one equation: m1*v1 + m2*v2 = (m1+m2)V
But if they aren't, you have to use a different equation. What I would do is to think of the balls hitting like this: During the split second that the balls are actually touching, think of one ball as being stationary and being hit by the other ball. Then when you find the final velocity of that, just add it to the actual initial velocity. On top of that, you will need to find the components of the velocities and add them up seperate. For example, a ball that is moving at 10 m/s at an angle of 40 degrees from the horizontal has a x-velocity of 10*cos40, and a y-velocity of 10*sin40. That is about the best I can do with two balls moving at once.

The angles that they hit is important too. The final angle that they rebound at is equal to the angle that they actually hit. You can find this angle by doing the following:
arctan(y/x) which is the inverse tangent function of the change in y divided by the change in x. Example, if you have a ball that's center is at the point (0,0), and it is hitting another ball whose center is at (3,1), first you would find the change in X and Y. the change in Y would be (1-0)=1, and the change in X would be (3-1)=2. So the angle between the two would be the arctan(1/2), which happens to be about 26.6 degrees. Now when these two balls hit, ingoring velocities and concentrating on angles, you can see that the ball being hit will go off at an angle of 26.6 degrees, while the first ball doing the hitting will go off in the exact opposite direction, which is either
-26.6 degrees, or 333.4 degrees.
I won't go over it, it will take too long, and this is already a quite long post, but combining those last two methods, the first of finding the magnitudes, and the second of finding the direction, you should be able to make some pretty realistic collions. Obviously, you will want to apply a friction constant, otherwise the balls will go on forever and never stop.
Also, there is one other collision, and that is with the ball and the rails. Obviously, most people know that it just kinda changes directions. If the ball is traveling upwards, and hits the right rail, the yvelocity will remain exactly the same, and the xvelocity will just inverse, for example initially a ball has xvel=2, and yvel=5, when it hits the rail, it will have a yvel=5, and a xvel=-2. To be more realistic you can add an effect that takes the velocity down just a tad when it does hit. But that must be quite small.
Well, that is about all I have time for right now. I hope this helps someone, I tried to put thought and time into it. Enjoy people

03-28-2002, 08:59 AM
Can somebody please comment my pool example:

Its not finished, must be restarted, when cue ball goes into hole :)

03-28-2002, 12:07 PM

Thanks. That's priceless, and I haven't seen it explained so well before.


I do like that, although it's a little slow, and the action could be smoother.

It's a damn site further than I've got, though.... :D

03-28-2002, 01:23 PM
Hey, it's no problem. I am just trying to help out a little with anything that I can. I ask for help with all the scripting and syntax crap, so the least I can do is help out with the things that I am good at: math and physics.

So, like I said, I am an undergraduate engineering student, so I will try to help as much as I can with these types of questions.

04-03-2002, 10:54 AM
here it is in action:

this throws in gravity, lift, and different sizes/masses on 10 balls just for fun.

the fla is not commented, so here is the theory.
calculates distance between two balls (pythag. theorem)
if distance<sum of radii, then you have a hit.
calculates angle between two balls.
uses that angle to perform coordinate rotation on the x and y velocities of each ball.
then uses the exact momentum equations given by minger to resolve the collision and new velocities.
in my own twist on things, i manually move the balls so they are just touching each other, not intersecting. this is not mathematically correct, but keeps them from getting "stuck". this is the biggest problem with these types of collisions and various methods have been made to handle it. this is my take on it.
then, re-rotate the velocities and carry on.

funny, i'm now secong guessing myself if i did the rotational vectors correctly. seemed to make sense last night, but now the math seems strange. still, it looks correct.

04-03-2002, 01:46 PM
Looks sweet Bit. Everything looks good, and the code looks good too. Man, you need to know that you are my hero. I check your page everyday to see if something new is up.
Hope my little collision explaination helped.

Keep up the good work.

04-03-2002, 01:56 PM
yeah, i just worked it out again on paper and re-convinced myself that my rotations were correct. this stuff is slippery!
actually, i used super samurai as my main learning material, but it contains all the same equations as you gave there. for someone like me who never had any formal math training, it's good to read as many versions and explanations as possible. sometimes one will give you a slightly different viewpoint that makes the whole subject click.

04-03-2002, 06:25 PM
Yeah, anytime. If anyone needs to know anything math/physics wise, I'm the guy. Recently we learned about fluid pressure, oscillations, and now we are on waves. So, if anyone has any question about those, I might now be able to do the script, but I can give the real life equations and stuff like that.

04-04-2002, 12:20 PM
here's another example

this one adds in large body gravity and drag & throw capabilities. looks pretty solid.

04-04-2002, 12:45 PM
Bit-101, that's just sick.

Good work.

04-04-2002, 12:59 PM
I just love this thread :)

Magic :)

04-04-2002, 01:59 PM
Bit, once again you amaze me man. One day.....one day I will be as good as you. Until then...I will just sit here and wonder.

04-04-2002, 02:44 PM
it's just about learning the basics. i concentrate on one thing until i know it so cold i can code it in my sleep. then i just play with the different formulas. how many different ways can you combine elasticity, gravity, momentum, accelleration, rotation, bouncing, angles, etc. etc. ? it's endless.

04-04-2002, 03:02 PM
yeah, it sure it about the basics. I have been learning physics and calculus and stuff like that for years, but I have only been scripting for like a month. I have all of these ideas that I know how to do with real-life formulas and stuff like that, I just don't know the exact script and code and things like that. As soon as I can get the basics, I will hopefully be able to start turning out some good stuff like you.

04-11-2002, 08:08 AM
thats amazing! you can actually get the little ones to orbit the big ones for a short time.

04-11-2002, 10:47 AM
I've played around a bit with the file from BIT-101. It's now a good example to show how something in a perfect order can go in chaos really fast. ;)



04-11-2002, 10:50 AM
Originally posted by cadwallader
thats amazing! you can actually get the little ones to orbit the big ones for a short time.

yup. there's another one, i think on April 7th (www.bit-101.com) that does orbiting directly.

04-28-2002, 01:15 AM
Originally posted by lesli_felix
I was playing pool last night, and decided to watch the balls a little more closely....It does look very difficult.

Simply doing accurate and fast hittesting is enough of a headache.

Still, I'm going to have a go. Probably best to start off with a good hittest, and a basic bounce, then work out rebound angles and momentum afterward.

Then there's spin, which REALLY messes things up.

I imagine that a good pool game in flash would require some convincing pseudophsics, rather than using any of newton's equations etc.

I've just put this together in flash, it looks neat, but it's useless at the moment, as the balls don't collide, I'll post again as soon as I've got some kind of hittest/rebound thing going on.


Use enter to accelerate the balls, if you want to play around with it, here's the source:


The system cannot find the file specified.

04-28-2002, 04:59 AM
My site's down, and will be for a little while.

I'll upload a file later on my freehost.

I'm getting a little further with the game, I'm playing around with different collision detection routines for the balls. Starting off with 16 balls in pool really slows the game down!!!

Also trying to correctly simulate the friction of the table. Subtracting .1% each frame looks good, but the ball never actually hits zero velocity when you do that, so you have to increase the friction as velocity approaches zero, and arbitrarily stop the ball when the velocity goes below a certain point.

I'm also playing around with things like balls casting dynamic shadows on the table, but this isn't any good on slower machines, unfortunately.

There's quite a few hurdles to programming pool. Here's a few more I haven't even contemplated yet...

Opponent AI
Multiplayer capability
Targetting, showing path of object ball if hit.
Finding some decent sound FX :D

04-29-2002, 10:29 AM
"friction" is quite often taken as a percentage of speed like that. i usually do it that way myself. but it's not physically accurate. it would actually be mathematically represented by an acceleration in the opposite direction of the motion, or a negative acceleration, if you will. so it would be a constant amount, but of course it would never actually reverse the direction of the object, only stop it.

so say you have an object with velocity vx. (we'll limit it to the x-axis) if vx is positive, frictionx will be negative, and vice versa. if vx is less than frictionx, vx should simply be set to 0.

} else if(vx<-frictionx){
} else {

as far as number of balls, yeah, my system seems to max out at 10 or so. after that, too clunky. i could work at optimizing, but the fact is theres a lot of math to do each frame.

04-29-2002, 03:25 PM

To speed things up a bit, try using the basic hit-test before using the pythagoras distance test.
Only use the pythagoras test if you get a positive result on the bounding-box hittest.

Here's that bouncing demo you did to illustrate. I set the balls to 20. There's also a moock fps speedometer in there to give you a frame rate:


Now instead of this:
checkColl(b(i), b(j));

Use this:
if (b(i).hitTest(b(j))){
checkColl(b(i), b(j));

It goes from about 8fps to around 14fps on my machine:


BTW, here's what I've got so far. It's non-interactive at the moment. I'm still looking for ways to speed it up on the break, which is the slowest part of the game.


04-29-2002, 03:44 PM
wow, that pool game looks nice.

and it's kind of spooky seeing my files up there with stuff added to them! :D

keep at it!

05-01-2002, 12:23 AM
mamma mia...this is way cool and way too dif. for me :D I would sugest you guys look in the GamesForum for Xentor's Flash peer-to-peer VB thingie...:D


thanx for the tut..


05-01-2002, 08:15 AM
Being able to dissect your bouncing code helped a great deal, along with minger's explanation of the physics.
Another thing I'm working on is a way of giving a ball a rotating spot, so you can see it rolling. I have a very vague idea of how this might be done, I'll post as soon as/if I work it out.

That looks very cool.

I was wondering, whether you could apply your mass collision detection routine to pool balls??? I haven't looked at the code myself, so I don't know. But I'm sure the same principle could be used to speed things up.

05-02-2002, 02:05 AM
I guess so..keep in mind that the way it works is one moving against many static,you may want to tweek it a bit


06-08-2002, 12:06 AM
I haven't looked through the code much in the files posted so far, but I haven't seen any that ensure the balls haven't passed through each other completely. Let's say you have two balls, each with a 3 pixel radius. They are moving on a collision path at 30 pixels per step and appear to go through eachother. Do any of the SWF's or FLA's address this issue? I have a feeling that would slow down flash quite a bit in a game like pool where there are many tests going on at once, but it is an essential element to consider if you are trying to write a billiards game.

06-08-2002, 05:04 AM
The only thing I've noticed is that the bounce angles and collision detection become a little less accurate as the balls get faster. This actually happens on a real table, as human accuracy decreases the faster the balls are hit.

So it doesn't matter, as long as the increments each ball makes aren't big enough to pass through a ball at a direct angle.

Another 'problem' I've noticed is that when you break the pack hard enough, two balls appear to overlap as they don't have enough space or anywhere to go. Anybody who's broken up hard enough on a real table will see the same thing, only the ball is forced upwards.

06-08-2002, 07:39 AM
Good point, but it is possible to keep the balls slow enough not to pass through in most cases, but what about two balls that are going should touch edges? That is tough to protect against. I know Yahoo's pool doesn't allow many pass throughs (even on edges).

The problem wasn't addressed very well in the Samurai book, but I know it can be done. I know what you're saying about the slop factor at higher speeds, but game code can be precise since we don't have to worry about external forces. I don't think it will be all that difficult to fix.

06-08-2002, 01:07 PM
(I think) the yahoo pool is timebased, not framebased, so it's coded in a completely different way. If I remember correctly, the ball doesn't slow down in real time, but 'fast-forwards' to its final position.

With frame-based pool, the innacuracy comes from having a ball move too far in one increment, so you need to make sure that the balls aren't ever moving more than a certain number of pixels per frame. If you want a ball moving quickly, and you're movie's running at 15fps, then this is easier said than done!

Another thing to remember is that java is faster than flash, so you can afford more elaborate routines for hit-testing and physics. With actionscript, you have to try and get a good balance between realism and performance.

I actually tried an experiment by putting a ball very slighly in the path of another in flash, and it only hit it when it was travelling below a certain speed. As I said before, this happily reflects the behaviour of a real table in that hitting a ball quickly at an almost 90 degree angle will often result in a miss.

This gave me another idea (which I haven't tried) - What if you increased the size of the ball proportionally to it's speed to exactly compensate for this? As the ball gets faster, it's more likely to miss, so make it bigger! Not physically, but just the hit-radius.

It's an approximate solution, but it could work...

Ed Mack
06-08-2002, 04:35 PM
I was thinking of the ball going through another.

And idea would be for the balls in turn to have an invisible hairline MC skewed to run from the balls curent position to somwhere 1 frame ahead of it using the current velocities. HitTest it with the other balls, though tihs carries the bounding box problem.

06-08-2002, 06:15 PM
Hmm.. well I am going to mess around with it and see if I can get it to work in spite of flash. I know going for english might be a bit much for flash, but I am sure it is possible to code it frame based and have the balls detect a hit even if according to step size they would have stepped through eachother.

06-24-2002, 08:59 AM
What happened to the people over here ??

I am really impressed with mingers theory and bit 101's mastery in flash AS Vis-a-Vis trignometry.

I have question to minger and bit 101.

based on mingers theory I have built this samll swf. I have got evrything correct but the ball that is hitting the stationery ball isnt behaving properly it is not following mingers theory of the ball going in a direction that is -ve of the angle of the ball being hit.

minger and bit 101 ur help pls !!!!!

files :


07-05-2002, 01:46 PM
I just need to know ONE thing...What are the equations and/or how do you determine how much of one balls momentum is transferred to the other ball. I have read all the posts and this is the one thing that doesn't come up. If the balls hit straight on, then all of the momentum is transferred, but if they dont hit straight on (which happens most of the time) then only a certain percentage of the momentum is transferred. PLEASE someone answer this.. THanks you sooo much!

07-05-2002, 01:58 PM
and in reply to var_flash_games's post here is the code for ball1 that will fix your problem:

onClipEvent (enterFrame) {
// trace(x);
if (hit eq "yes") {
x = xspeed*Math.cos(angle)*fric;
y = yspeed*Math.sin(angle)*fric;
_x += x;
// _y += y;
if (hitTest(_root.ball2)) {
diffx = _root.ball2._x-_x;
diffy = _root.ball2._y-_y;
angle = (Math.atan2(diffy, diffx));
angle2 = (180/Math.PI)*(Math.atan2(diffy, diffx));
_root.ball2.hit = "yes";
i += 1;
if (i<=1) {
_root.ball2.x = x;
_root.ball2.y = y;
_root.line._x = _root.ball2._x;
_root.line._y = _root.ball2._y;
_root.line._rotation = angle2 +90;
if (fric<=0) {
fric = 0;
} else {
fric -= 0.1;
onClipEvent (load) {
hit = "yes";
angle = 1;
xspeed = 4;
yspeed = 4;
fric = 3;

There are still many problems, but the line works now.

07-09-2002, 03:31 AM
Hi DjBlaze thanx for your code.

But I found no difference in the ball1 behaviour. Also the ball2 is now not following the hit angle it just keeps going staright no matter what the hitAngle is.

Is it that I need to wqork around the code again ??

Can u pls if possible edit the fla and post it again.

I want the ball1 to follow a reverse direction of the hitAngle. And The ball2 to follow a direction defined by the hitAngle. How do I achieve it.


07-12-2002, 01:36 AM
Will some one PLS come out and help me !!!!!

Or is it that I havent explained it well.

I dont mind explaining it again and again and again ....


A moving cue ball hits a stationery ball. The statinery ball gets deflected and moves in the direction defdined by the angle of hit. well Its all working till here.

But when the hit occurs the cue ball shoud ideally based on the laws of ball physics should deflect and move in the direction opp to that of the hit angle. How do I do this.

refer to the above links for the files.


07-12-2002, 08:55 AM
the best explanation for all this, that ive found, has been in macromedia flash super samurai. jobe makar's chapter. it still took some working over to fully understand it though.

basically, you need to know each ball's momentum (mass*velocity).
then you need to know the angle of collision - the angle formed by the line between the two balls.
then you need to determine how much of each ball's momentum lies on that angle, using some coordinate rotation type trig.
then you apply your conservation of momentum forumas to the momentum on that angle.
then you rotate the coordinates back to the stage coordinates, which will give you the ball's new momentums.

simple! :D


i've also seen some decent tutorials on this written for director. although the code was a bit different, the explanations were half decent. don't have the urls though. your best bet is to buy the book. well worth it for the other stuff in jobe's chapter alone, not to mention the other authors.

07-12-2002, 01:34 PM
Now this thread is getting long, and it may be time to open a discussion about how much code you tell others about?

I think lots of people have done movies using this type of physics, but I think they are all sitting back thinking:

"well it took me x long to sort it out, why should I give away a nice neat function where you give in two balls'
velocities and get their new velocities out." Me included!!!!!

Anyone interested in having this conversation? or is it as I suspect an unwritten rule, based on a subjective scale of "blood and sweatiness"?

And just to upset the ones who haven't "toiled hard or long enough" yet:


07-12-2002, 01:41 PM
nice movie. for me the issue is more like: it would take me several hours to write out a concise, understandable explanation with all the formulas. i just might do that someday and put it up as a tutorial someday so that i can just hand out the link and end these long threads! :)

07-13-2002, 02:11 AM
Well, bit-101
I am waiting for ur tutorials despartely !!!

Ofcourse I have went thru most of ur tutorials on ur website.

They are very useful.

and swills its very impressive ur movie is, it also means that U have got the ball physics right !!!

would u please share ur theory and how did u work around to get this thing done.

Also I would be pleased if u can tell me where I need to work on in my fla so that I get the desired effect.


07-13-2002, 02:21 AM
hey swills I missed ur first line,

well, why u feel its necessary to discuss on how much one should discolse his codes.

opensource enables the development of the entire group and also it enhances the software tool value.

This will only help people in developing some excting and extraordinary applications or games in flash which otherwise would have been not possible without sharing of knowldege !!!!!!!

07-13-2002, 07:22 AM
Actually, I disagree.

On the one hand the open-source approach allows far more to be achieved by a community of developers, but this community has to be supported by developers who get down and work some things out for themselves.

Of course, nobody can be expected to re-invent the wheel. I've never even contemplated writing my own javascript pop-up window routine, as there are so many good open-source ones out there.

Some people claim they can't learn anything without seeing other people's code. This couldn't be further from the truth. I've learned much more from tackling problems by myself than I could ever have from seeing other people's work. For one thing, understanding code somebody else has written is 10 times harder than understanding your own.

And let's not forget how rewarding it is to solve a problem yourself....

Here's something I tried for ages to get to work in flash 5, eventually I gave up as it just wasn't possible. However, when MX came out, I tried it again with the new dynamic masking technique and it worked a treat.


mouse to change direction, cursors to move, enter/space to turn gravity on and off. shift/ctrl to turn extra friction on/off.

When I have the time this'll turn into a kickass platform game.

07-13-2002, 07:44 AM

I tend to agree. Its as though some aspects of coding become so much the norm that then open source is available for people to "catch up". Where-as maybe the good coders who don't show everything are, in effect, dragging everyone else up - in a good direction. No pain, no gain!

By the way, love the ladybird, it seems MX could be useful after all! ha! ha!

This was done in 5:

I've tried to help some people on these boards and they've got really irrate because I haven't just given them an fla. You are right about trying to understand another persons code - A persons coding style is probably much worse than their hand-writing! Indecipherable!

Anyone else have any comments?


[Edited by swills on 07-16-2002 at 07:48 AM]

07-14-2002, 02:21 AM
hey leslie,
nice buggy work

swills ur molecules where excellent impressive work !!!!

thanx pals, atleast its good to c nice works and get inspired. Thats why I like this forum so much.

07-17-2002, 11:40 AM
nice, way to post your addresses on the net, expect a bomb in 1 or 2 weeks, smart move

*note: this is not a threat I wont be sending anything, but you guys are retarded to fall for this and put your addresses online.*

08-02-2007, 10:58 AM

To speed things up a bit, try using the basic hit-test before using the pythagoras distance test.
Only use the pythagoras test if you get a positive result on the bounding-box hittest.

Another way to speed things up would be to compare the *squared* values only in your collision detection test, and then work out the square root afterwards (only if a collision happens).

//distance between two balls, squared
var distance_SQUARED = dx*dx+dy*dy;

//distance within which a collision would happen, squared.
var collision_dist_SQUARED = (b1.radius+b2.radius)*(b1.radius+b2.radius);

if (distance_SQUARED < collision_dist_SQUARED)
var dist = Math.sqrt(distSQ);
var angle = Math.atan2(dy, dx);

... and so on

Calculating square roots is very expensive. The above replaces it with a single multiplication. I've also moved the angel calculation so that it's only worked out after a collision.

Anyhoo, nice job on the original code (and the math). It's very much appreciated.