<p dir="ltr">On May 6, 2013 10:39 AM, "Joshua Landau" <<a href="mailto:joshua.landau.ws@gmail.com" target="_blank">joshua.landau.ws@gmail.com</a>> wrote:<br>
><br>
> On 4 May 2013 00:42, Ian Kelly <<a href="mailto:ian.g.kelly@gmail.com" target="_blank">ian.g.kelly@gmail.com</a>> wrote:<br>
>><br>
>> The other thing that is suspicious about the code you posted is that<br>
>> it has two different notions of the ball's position that are not<br>
>> necessarily in agreement.  There is the ball_rect, and there are also<br>
>> the x and y variables.<br>
><br>
> <snip> <br>
>><br>
>> You should be careful to make sure these<br>
>> variables agree at all times -- or better yet, get rid of x and y<br>
>> entirely, so that you only have one notion of the ball's position to<br>
>> worry about.<br>
><br>
><br>
> Pygame uses integers for its Rects and thus I advise much the opposite: *never* store position in Rects.<br>
><br>
> 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.</p>



<p dir="ltr">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.<br>

</p>