Quote:Original post by tnutty
For 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 goes
higher. 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 and
not 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?

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.