# quick question about collision response

This topic is 3226 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

In pong, when the ball hits the pad. I am ignoring friction so there is no loss in energy in the x direction, so ballSpeedx equals -ballSpeedX. But for the y component, I am having a little trouble. this is what I am doing for the response : NOTE: Pongball.ballX is the x position of the ball. positionPadX is the y position of the pad. All I need help is on ballSpeedY. I want the ball in to respond in a intuitive manner. What I am doing below for ballSpeedY is taking the x to be 1, and adding 1 to the height and finding its magnitude. Any help improving this part?
		if(PongBall.ballX + PongBall.radius  >= positionPadX - padWidth/2)
{
ballSpeedX = -ballSpeedX;
}



##### Share on other sites
If you ignore friction, the intuitive reaction to me would be not to change SpeedY during the collision. But this does not leaves the player with much control, so it might not be what you want ... You could take into account the Y speed of the pad. Or also, like on some breakouts, the part of the pad that was hit by the ball (comparing ballY and paddY).

##### Share on other sites
Wouldn't it be more natural to keep constant the total speed? Of course, this can make the game horribly slow with great SpeedY values.

I have been looking at http://www.xnet.se/javaTest/jPong/jPong.html and it seems to me that it's doing something like

So, it adds to the Speed the paddle position with was hit, having the center of the paddle a value of cero, the upper part adding speed towards the top of the screen, and the lower part adding speed towards the bottom.

And it feels good.

##### Share on other sites
For ballSpeedX, it feels natural just to do ballSpeedX = -ballSpeedX.

For ballSpeedY, I need the ballSpeedY to be at least -ballSpeedY, but this
also controls the ball direction. If the ballSpeedY is fast, then the ball goes
higher. If its too low, then the ball will go in the negative y direction, and
if the ballSpeedY is close to 0, then the ball goes in a constant line.

I want to change to ballSpeeY so that the physics seems normal.
The name ballSpeedY seems contradictory because it sounds like a scaler and
not a vector, but ultimately, it acts like a vector.

		if(PongBall.ballX + PongBall.radius  >= positionPadX - padWidth/2)		{			ballSpeedX = -ballSpeedX;			ballSpeedY = -sqrt(pow(padHeight+positionPadY+1,2)/1) /100;		}

##### Share on other sites
Did you try ballSpeedY = ballSpeedY (doing nothing do ballspeedY) ?
That's the most "normal" in terms of physics.

##### Share on other sites
Quote:
 Did you try ballSpeedY = ballSpeedY (doing nothing do ballspeedY) ?That's the most "normal" in terms of physics.

Well, all that will do is make the ball travel in reverse direction with the same magnitude. This means that the ball will always travel in the same
trajectory, which is very very predictable. All I want it do is
travel in a certain direction depending of the position of collision. I though
that is want I was doing with the source code I provided, but it feels like
its not what I want it to be.

##### Share on other sites
OK, so you want some control on the ball rather than complete naturalness.
The easiest would be the formula given by ravengangrel:

PaddlePositionHit must be 0 if the ball hits the center of the pad, and range from some negative to some positive value. For example simply:

If the deflection is too much or too low (you'd be lucky if adding a position to a speed was working raw), you can use a multiplicator on PaddlePositionHit in the first formula.

If you want a larger portion of the pad that does not deflect the ball, or to keep the total speed of the ball, more complex formulas are needed.

##### Share on other sites
A more natural way to do this can be adding the Paddle speed to the ball speed (I think I have seen this in some commercial arkanoid clone), but of course, for this you need to keep track of the paddle speed.

##### Share on other sites
I will try that. I have the position of the pad in my pad class, so it shouldn't
be a trouble.

##### Share on other sites
Thanks. Finally finished it.

##### Share on other sites
Quote:
 Original post by tnuttyFor ballSpeedX, it feels natural just to do ballSpeedX = -ballSpeedX.

Yes, because the ball reflects.

Quote:
 For ballSpeedY, I need the ballSpeedY to be at least -ballSpeedY

I have no idea what you mean by "at least" here.

Quote:
 , but this also controls the ball direction. If the ballSpeedY is fast, then the ball goeshigher. If its too low, then the ball will go in the negative y direction,

You mean, if it's a positive value, the ball travels upwards, and if it's a negative value, it travels downwards. This is to be expected. That's how these things work.

Quote:
 and if the ballSpeedY is close to 0, then the ball goes in a constant line.

You presumably mean a horizontal line. The ball always travels in a straight line (the only thing that "constant line" could sanely mean) if it has a constant velocity.

Let's make sure we understand terminology.

Speed is how fast something moves. This can never be negative: you can be moving, and you can be not-moving, but you can't be un-moving.

Velocity is how fast it moves, and in which direction. In 2 dimensional geometry, velocity has an X (normally interpreted as "horizontal") component and a Y (normally interpreted as "vertical") component. If the Y component of velocity is zero, then motion is "in the X direction", or "along the X axis", and vice-versa. We can further describe motion in the X direction as being in the positive or negative X direction.

Your "speed" variables represent the X and Y components of the ball's velocity. This is a slight misnaming, but usually considered good enough.

When something reflects (assuming an ideal collision, i.e. with no loss of energy, transfer of angular momentum etc.) in a vertical line (parallel to the Y axis), its X component of velocity is negated, but its Y component stays the same. If you want some kind of variation, you can base it off of that. Adding the paddle's Y-component of velocity is a good idea.

Quote:
 I want to change to ballSpeeY so that the physics seems normal. The name ballSpeedY seems contradictory because it sounds like a scaler andnot a vector, but ultimately, it acts like a vector.

No, it doesn't. That you think it does is a symptom of your confusion.

-sqrt(pow(padHeight+positionPadY+1,2)/1) /100

Let's break that down.

First off, we start with the paddle's *position* in order to calculate a *speed*. This makes no sense.

Then we square a value, divide it by 1, and take the square-root. This gives the absolute value, i.e. the result will always be positive. The division by 1 in here is useless; if you were expecting it to round off to the nearest integer or convert the type back to int or something, you are mistaken - it won't do that. (And even if it did, the sqrt() call would give you a floating-point value back again.) In any case, an absolute-value function - abs() - is already provided; just use that instead.

Then we negate that value, so we have a result that is always negative. Finally we divide by 100 - why?

##### Share on other sites
Quote:
 I have no idea what you mean by "at least" here.

In terms of speed

Quote:
 why?

Because at certain height the ball should travel faster downwards if it was hit.
And my program is not normalized so, if I have a speed greater that 0.5 then
it would be equivalent to a speed of around 25-35 mph. Thus I divide by 100.

##### Share on other sites
Quote:
Original post by tnutty
Quote:
 I have no idea what you mean by "at least" here.

In terms of speed

That doesn't make any sense. You said ballSpeedY should be (i.e., become) at least -ballSpeedY. But ballSpeedY could be either negative or positive to begin with.

Quote:
Quote:
 why?

Because at certain height the ball should travel faster downwards if it was hit.

I don't understand what you mean at all. This is pong we're talking about, right? No gravity, right? "Height" is not a meaningful concept here, because we have a top-down view of the playing field. If the ball was already travelling upwards when it was hit, it should continue travelling upwards after being hit, in normal circumstances. The position of the collision is not relevant to that, any more than the way you catch a baseball is different if you go to a ballpark on the other side of the city.

Quote:
 And my program is not normalized so, if I have a speed greater that 0.5 then it would be equivalent to a speed of around 25-35 mph. Thus I divide by 100.

1) What are the units of speed? Pixels per frame? Something else?

2) The ball speed was in perfectly sane units before the collision. You expect the ball speed to be about the same after collision as before, right? Putting things like "/ 100" in a calculation tends to make the output very much not the same as the input.