Funny thing =]
I think this has to be the function calculating the velocities (both directions and speeds) of the balls immediately after collision from those immediately before collision. For other movements/actions I suggest using other functions because you may want to introduce some retarding factors like friction to eventually stop the balls...something like that. (division of labour is good)
Assuming all collisions to be elastic (so that the total energy is conserved, and to make things simpler in the beginning), you have to consider conservation of momentum and energy at the moment of collision (well, physics stuff...), also note that the balls have some sizes and you have to figure out the direction of the forces from the point of collision.
Why not first start with math equations so we can turn them into codes later?
Actually, this function calculates the final position of the balls after collision, assuming that there is no friction and I'm pretty well stucked with the maths part lol =p
this function calculates the final position of the balls after collision, assuming that there is no friction
If there is no friction, the ball wont really have a final position, unless you are saying the ball loses energy when it hits a wall or ball. But in that case the final position will always be against a wall (or ball). You should try and get some basic movement of one ball down before you start worrying about it's movement when it collides with other objects.
It sounds to me that that function calculates the motion vectors of both balls after they collided, rather than predicting how much further they will go.
I am left with the impression that there are like a dozen different ways to hit the ball. Each will require a totally separate mathematical method. :(
I could try to help you with the math behind "Stop and stun shots" (this looks like the simplest one (mathematically! not to perform!) to me). However, implementing the math behind all the shots in wikipedia's page seems way too difficult to me.
If you assume the balls lose 1 J of energy per second, then why not think of it as a result of frictional forces? But nevermind, the balls have to lose energy some way.
screwed up the maths...
it's something like...
for particles (with no sizes),
assuming the balls have same masses,
conservation of momentum gives ua2 = va2 + vb2 + 2vavbcos(θa - θb),
where u and v represent initial and final speeds and the subscripts represent the balls, θ is the angle the final velocity of the ball makes with the "positive" (to the right) horizontal axis (say, the +x-axis), measured anti-clockwise.
conservation of energy gives ua2 = va2 + vb2 + 2E/m, where E is the given loss of energy during collision.
Then you have to find out the angles. Another way is to break them into components and don't use angles, the makes the vectors easier to code...looks like the maths has to be longer though...
Now the balls have sizes, so you may also need their positions, the mid-point between the centers of the balls is the point of collision, and the forces must be perpendicuar to the common tangent at that point.
Again, as helios have said, you can manage the motion of the 'free' moving balls by another function, which would be easier, just decrease the kinetic energy over time until it's zero (or near zero and you round it up). For this function, only stick to generating new velocity vecotrs from old ones. For collision with a wall, just find out which wall it is then add a minus sign to the appropriate velocity component.
From the wikipedia article, I was left with the impression that the colliding balls behave *essentially* differently depending on whether the cue (white) ball is sliding or rolling.
Something more, every regular (no special technique) shot you do has two phases: "sliding phase" and "rolling phase". The length of those phases depends on the surface of the table and on the strength of the hit. Sometimes, there is even a "flying phase" for several centimeters if you hit the cue ball strong enough (regular hit).
In other words, to make a program that remotely simulates pool *with regular hits only* (only hits in the center of the cue ball), you will need to have at least two types collisions: "rolling" (the cue ball is rolling) and "sliding" (the cue ball is sliding).
:(
He's just looking for a calculation of the resulting velocity vectors for collisions involving his magic discs (which have no friction and yet slow down and stop). I doubt it's a hard-core pool simulation!