Velocity Reviews > Collision of Two Rect

# Collision of Two Rect

Alex Gardner
Guest
Posts: n/a

 05-03-2013
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
y_vel*=-1
x_vel*=-1

MRAB
Guest
Posts: n/a

 05-04-2013
On 03/05/2013 23:23, Alex Gardner wrote:
> 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
> y_vel*=-1
> x_vel*=-1
>

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
Guest
Posts: n/a

 05-06-2013
On 4 May 2013 00:42, Ian Kelly <(E-Mail Removed)> wrote:

> 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.

<snip>

> 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

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
Guest
Posts: n/a

 05-06-2013
On May 6, 2013 10:39 AM, "Joshua Landau" <(E-Mail Removed)> wrote:
>
> On 4 May 2013 00:42, Ian Kelly <(E-Mail Removed)> wrote:
>>
>> 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.

>
> <snip>
>>
>> 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

>
>
> 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.