Collision of Two Rect

[Alex Gardner]

When rect A collides with rect B they stick when I am wanting A to bounce off of B. I have tried different methods, but none seem to work. My source is here: http://pastebin.com/CBYPcubL

The collision code itself is below:

 

[MRAB]

When rect A collides with rect B they stick when I am wanting A to bounce off of B. I have tried different methods, but none seem to work. My source is here: http://pastebin.com/CBYPcubL

The collision code itself is below:
------
# Bounce off of the paddle
if paddle_rect.colliderect(ball_rect):
y_vel*=-1
x_vel*=-1

Apart from the other comments, I'm not sure about this line:

y_vel = (math.fabs(2 - x_vel)**2) ** .5

Firstly, instead of math.fabs you could use abs:

y_vel = (abs(2 - x_vel)**2) ** .5

Then again, you're squaring the result, and the square of (2 - x_vel)
will always be positive anyway:

y_vel = ((2 - x_vel)**2) ** .5

You're also calculating getting the square root, for which math.sqrt
would be simpler:

y_vel = math.sqrt((2 - x_vel)**2)

Then again, you're calculating the square root of a squared number, so
you might as well just write:

y_vel = abs(2 - x_vel)

 

[Joshua Landau]

The other thing that is suspicious about the code you posted is that
it has two different notions of the ball's position that are not
necessarily in agreement. There is the ball_rect, and there are also
the x and y variables.

You should be careful to make sure these
variables agree at all times -- or better yet, get rid of x and y
entirely, so that you only have one notion of the ball's position to
worry about.

Pygame uses integers for its Rects and thus I advise much the opposite:
*never* store position in Rects.

Sorry, but it's true. You'll need to keep x and y around and try to use
Rects only when representing pixels on the screen. Pygame has a lot of
deficiencies with its default set of objects and functions, so it's
something to get used to.

 

[Ian Kelly]

Pygame uses integers for its Rects and thus I advise much the opposite:

*never* store position in Rects.

Sorry, but it's true. You'll need to keep x and y around and try to use

Rects only when representing pixels on the screen. Pygame has a lot of
deficiencies with its default set of objects and functions, so it's
something to get used to.

You don't need subpixel positioning for many games -- arguably including
Pong, although I suppose the argument would be stronger if the OP were not
using a ludicrously high frame rate of 200 fps, which is going to limit the
number of reasonable integer velocities available. For games where logical
coordinates and screen coordinates need to be separated though, I agree.