simply pretending the lines are straight and intersecting does not work. The ball flies straight through the paddle in several instances.
But, I don’t see where the exact time matters[…]
Imo priori is amazingly accurate and robust (but it’s also horribly complicated).
Hm. Well, a rotating line segment won’t really do the trick, because those edges of the flippers are offsetted from the rotating point.
Man… my head hurts.
Well, you can always use multi sampling if the ball gets into that area… and if you find a collision you go back/forward stepsize/=2 until you reach some (abs) threshold distance, at which point you resolve the collision.
hm, so if the ball is going very fast, I find out what timespan of the total tick time the ball spends in the vincinity of the flipper, then do checks only for that distance.
It might end up using too many cycles, but it’s probably better than my solution of replacing the rotating line with 20 moving spheres, all overlapping each other. 
Shouldn’t be that bad… I think. The speed of the tip of the flipper and the speed of the ball give you the minimum step size (if it’s bigger it might warp through).
And then you either step all the way through that area and no collision happens. Or you step a few times and you get a collision… in which case you go back half the step size, then forward or back depending on the penetration depth (stepsize halved again) etc.
As soon as you found a time where the distance is <1px you can stop. Resolve the collision and advance the simulation by the remaining time (if you drop this little bit of remaining time, it will feel slower and less real/solid - it’s a very subtle thing, but it does make a bit difference).
Well, for the most part there should be only like a dozen passes at most, which should be even fast enough with action script. (Unless there is multiball it’s the only thing happening this frame… so it should be alright, I think.)
I am at work now, so I can’t check this and I am not much of a mathematician at all, so bear with me, but shouldn’t you be able to calculate the intersection by using the balls velocity ray, an assumed intersection point (projecting a rectangular line l from the velocity ray through the origin of your rotating line) and solving t in
t*vb=tan(va*(t-t0))/l
where vb is the balls velocity, va the angle velocity of your rotating line and t0 is the time the rotating line needs from rotating from it’s start point to the assumed intersection.
If you weren’t at work I would kiss you.
EDIT:
@Markus_Persson: I know the ball flies through. That’s why you use the lines and not the ball itself. Given oNyx’ wikipedia reference, I’ve been describing an a priori method whereby you see if a collision will occur in the time step, and where it will occur. Then you place the ball at the position of line intersection (not quite of course, since the intersection is the on the edge of the ball) and give it a new velocity which is the mirror of the current velocity around the perpendicular to the paddle line.
steps:
- (time step begins) calculate line that represents paddle, given current paddle orientation
- fire ball velocity ray, get list of collisions, take the first one
-
if it intersects the paddle line (or any line technically, but the paddle line is special)
place the ball at the intersection point, set new velocity, add paddle angular velocity to ball linear velocity - else update ball position by ball velocity
- (time step ends)
And what do you mean pretending won’t work? The entire thing is about pretending! 
Be careful teasering me blink
I don’t get it… could you elaborate?
Interesting topic. Can’t say that I have completely understood everything that has been written so far… I assume that you are just trying to detect collision and not necessarily at what exact time between two frame updates, right? I don’t think a player will detect a 1/50th of a sec error 
If so, couldn’t you represent the flipper as one sphere at the pivoting axle, and one smaller sphere at the tip (if you want a rounded end of the flipper) and then two line segments connecting the tangents of the spheres.
Calculate a ball movement line segment from balls previous position to balls new position.
Then you can just do:
an intersection test between the ball and the flipper line segments (in case it currently is colliding)
intersections test between ball movement line segment and flipper line segments (in case it is “moving through” the flipper)
intersection test between flipper spheres (one at a time) and the ball movement line segment, but add ball radius to the flipper sphere. (in case it hits one of the ends)
You probably have to move flipper, do tests, move ball, do tests, to be sure to not miss any collisions.
You will naturally have to move the ball out of the flipper and then bounce ball and add the speed generated by the flipper. If you don’t add the speed generated by the flipper, then you might get multiple collisions with one flipper press, and that would give very weird bouncing as result.
Hmmm really difficult to explain it without writing it on paper But it is a quite straight forward.
Let us know how you solve it in the end, and get the game ready soon. Getting eager to test it now
This is hard without a drawing (so my first post was actually wrong, but it might be the right direction), so recall the previous image of the process:
http://www.songprojector.com/temp/sphere_paddle.png
Let’s start with the rightmost figure and assume the angle between the projected ray (in the direction of the balls movement) and paddle is rectangular. You can find the intersection point between the ray and the paddle by using some vector math (I have no book at hand, so…) regarding rectangular aligned vector equations.
Now the ball needs some time to travel (at it’s known speed) to this intersection point. Also the paddle needs some time to rotate (at it’s known angle speed) to it’s position rectangular to the ray. In an ideal situation this times are equal, meaning that the ball hits the paddle while it is rectangular to the balls directional vector (the ray).
Unfortunately this might be the less likely situation, so the other figures come into play. At any given time (exept the ideal above) there is a distance between the ball and the projected intersection. This distance is minimized by the ball moving towards the paddle and the paddle rotating towards the ball. If you take our assumed rectangular intersection as a subsidiary line you can form a rectangular triangle between this line and the paddle. Now you can use the trigonometrical function
tan(angle)=o/a (a:adjacent/o:opposite leg)
You know the angle speed (va) the paddle is rotating, you can use this like
tan(va*t)=o/a
Since you need to know the distance the projected intersection point “travels” on the balls ray, you need to calculate the opposite leg o, which is
o=tan(va*t)*a
So we have one part of the equation. Remember: a is the distance between the assumed rectangular intersection and the origin.
The other part of the equation is the distance the ball is travelling in a given time, which is easy:
d=vb*t (vb is the speed of the ball)
To determine where the ball and the paddle meet, you have to calculate the distance between the ball and the projected paddle line at time 0 (using vector math); lets call it d0. Now this distance has to be equal to the distance travelled by the intersection point on the paddle and the distance travelled by the ball:
d0-(tan(va*t)*a)-vb*t=0
You have to solve this to t :P, which should be the time, when the ball and the paddle meet. Afterwards you can use t inserted in vb*t to get the accurate intersection point.
Keep in mind, that I may have made errors and that it assumes a paddle of infinite length (you have to test if the intersection point is on the finite paddle afterwards). Also you might need some case differentiation, since tan is not a continious function.
[quote=“jojoh,post:29,topic:29136”]
If it results in the ball passing through the flipper when moving really fast, he will.
I’ll try this tan angle, and post here when/if I get it working. Thanks! =D
One “good” thing with actionscript is that all operations are so slow, sin, tan and so are basically free.
In that quote, I was thinking of error in deflection angle. I should maybe have written that out.
Just before that sentence I wrote:
And then tried to describe an approach that detects ball and flipper collision even if they move through/passed each other in a single frame update! I can however understand if it was a bit difficult to decipher my explanation without any pictures to accompany it I still think it is a quite simple, straightforward solution that should be quite fast as well. The actual deflection angle should be no more difficult than any other bounce in the flipper table.
@Markus:
Any progress on this? Since I did not test it myself, I would like to know if you came up with a working solution.
I went with a bunch of moving spheres. It’s not working perfect, but at least it works.
I implemented it as I tried to explain here earlier, and collision with flipper and ball works fine. The bounce turned out to be more of a trouble and still needs a bit of a tuning, but it is pixel perfect. Give it a shot if you want. Look and table design lacks a lot, but I think the flippers work fine and you can aim and get a decent feel. I could maybe produce a graph to explain what I did if anyone is interested.
Markus, let me know if you want to do any cooperation with this. Not sure what it could be, but would be nice with a competitive pinball game made in Java. I was sort of aiming at creating a top 5 online pinball game. Not much competition there, so should be doable.
I don’t think this wil ever work before ODE supports continious collision detection. Fast objects will always cause problems.
You can put hack upon hacks but it will never really get there. Switch engine if you can’t live with it.