Collision of Two Rect

[Ian Kelly]

On May 6, 2013 10:39 AM, "Joshua Landau" <joshua.landau.ws at gmail.com> wrote:
>
> On 4 May 2013 00:42, Ian Kelly <ian.g.kelly at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130506/23d95ce6/attachment.html>