Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #44690 > unrolled thread

Collision of Two Rect

Back to article view | Back to comp.lang.python

Contents

  Collision of Two Rect Alex Gardner <agardner210@gmail.com> - 2013-05-03 15:23 -0700
    Re: Collision of Two Rect Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-03 17:42 -0600
    Re: Collision of Two Rect MRAB <python@mrabarnett.plus.com> - 2013-05-04 01:51 +0100
    Re: Collision of Two Rect Tim Roberts <timr@probo.com> - 2013-05-04 22:28 -0700
    Re: Collision of Two Rect Joshua Landau <joshua.landau.ws@gmail.com> - 2013-05-06 17:38 +0100
    Re: Collision of Two Rect Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-06 14:18 -0600

#44690 — Collision of Two Rect

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

[toc] | [next] | [standalone]

#44694

On Fri, May 3, 2013 at 4:23 PM, Alex Gardner <agardner210@gmail.com> 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
> if paddle_rect.colliderect(ball_rect):
>     y_vel*=-1
>     x_vel*=-1

What may be happening is that even though you reversed the direction
of the ball's movement, in the next frame the paddle and ball are
still detected as colliding, so they get reversed again.  If that kept
happening over and over again, then the ball would appear to be
"sticking".  You should check the current direction of movement after
detecting the collision and only reverse it if it is not already going
the proper direction.

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 center the ball_rect from the x and y
variables (somewhat awkwardly; see below), so at that point they would
agree, but then you update the x and y variables without updating the
rect accordingly.  So before you get to the collision detection code,
the position of the ball on screen and the one that is used for the
collision detection may be somewhat different from the *actual*
position of the ball.  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.

By the way, this code:

     boundsball_rect = pygame.Rect(x,y,0,0)
     ball_rect.clamp_ip(boundsball_rect)

could more simply be expressed as:

     ball_rect.center = (x, y)

Because that's all you're doing here: updating the position of the
rect.  If you take my advice and do away with the x and y variables,
then your position updating code:

     x += x_vel
     y += y_vel

could simply be:

     ball_rect.move_ip(x_vel, y_vel)

[toc] | [prev] | [next] | [standalone]

#44697

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

[toc] | [prev] | [next] | [standalone]

#44726

Alex Gardner <agardner210@gmail.com> 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
>if paddle_rect.colliderect(ball_rect):
>    y_vel*=-1
>    x_vel*=-1

I haven't looked at the rest of your code, but the lines you have here are
going to send the ball back in exactly the direction it came from -- a 180
degree reversal.  When a ball hits a paddle at an angle other than head on,
only ONE of the velocities is reversed.  When you hit a horizontal paddle,
only the Y velocity is negated.  The ball continues in the same X
direction:

    \    O
     \  /
      \/
   ========

See?  The X velocity continues unchanged until it hits a vertical wall.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[toc] | [prev] | [next] | [standalone]

#44837

[Multipart message — attachments visible in raw view] — view raw

On 4 May 2013 00:42, Ian Kelly <ian.g.kelly@gmail.com> 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
> 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.

[toc] | [prev] | [next] | [standalone]

#44848

[Multipart message — attachments visible in raw view] — view raw

On May 6, 2013 10:39 AM, "Joshua Landau" <joshua.landau.ws@gmail.com> wrote:
>
> On 4 May 2013 00:42, Ian Kelly <ian.g.kelly@gmail.com> 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
>> 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.

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web