Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.033 X-Spam-Evidence: '*H*': 0.94; '*S*': 0.00; 'argument': 0.05; 'suppose': 0.07; 'variables': 0.07; 'integers': 0.09; 'pixels': 0.09; 'screen.': 0.09; 'variables.': 0.09; 'posted': 0.15; '>>': 0.16; '*never*': 0.16; 'agree.': 0.16; 'coordinates': 0.16; 'pygame': 0.16; 'separated': 0.16; 'subject:Two': 0.16; 'wrote:': 0.18; 'email addr:gmail.com>': 0.22; 'integer': 0.24; 'logical': 0.24; 'rid': 0.24; 'sorry,': 0.24; '>': 0.26; 'header:In-Reply-To:1': 0.27; 'am,': 0.29; 'thus': 0.29; 'message- id:@mail.gmail.com': 0.30; 'code': 0.31; 'about.': 0.31; 'screen': 0.34; 'agree': 0.35; 'something': 0.35; 'objects': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'representing': 0.36; 'should': 0.36; 'two': 0.37; 'skip:& 10': 0.38; 'to:addr :python-list': 0.38; 'though,': 0.39; 'sure': 0.39; 'to:addr:python.org': 0.39; 'ian': 0.60; 'worry': 0.60; 'times': 0.62; "you'll": 0.62; 'high': 0.63; 'different': 0.65; 'default': 0.69; 'limit': 0.70; 'stronger': 0.84; 'agreement.': 0.91; 'careful': 0.91; 'notion': 0.91; 'suspicious': 0.91; '\xa0there': 0.91; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=EkJUR91i3NZROx3tuweImdEsP1b7i/aKhPqd+lET9aE=; b=Q+gSrfCAsJDxoyHs7RlWjxW4dIgRJ+9qsyfqduPyK1ZQnogfr40O7ejNH7Z2snRFfd dxXRfIKMhJmCKNvXL01HvNrZmEmwLvb/6JcL5sKMT57GRV+I0lEPJVKqZe/d22QCSBoX VjG6yA03DCcdrdRHf0X9sNYyS2NvsJHUDEYcFWmVDml0uRlU8aRLhVZQ9z7GJXI8pBJe bF8wAKmPmfbRD4ezt2jQf6Ptf1t3w/f1DXNC9J4HcMWEGkSTUROCirWUAA2KDAA66GaF lPB63bHH6qJffIj6C03bel+/sICMKvVwAf1zIjQOrpPNPG35r8QAIetONiR1zS/M8qfY +rnw== X-Received: by 10.66.250.230 with SMTP id zf6mr28819478pac.153.1367871534419; Mon, 06 May 2013 13:18:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <9083ecbc-5666-41aa-aacb-3f08f062feed@googlegroups.com> From: Ian Kelly Date: Mon, 6 May 2013 14:18:14 -0600 Subject: Re: Collision of Two Rect To: Python Content-Type: multipart/alternative; boundary=047d7b15ae9fe8567604dc12685e X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 83 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1367871542 news.xs4all.nl 16003 [2001:888:2000:d::a6]:51696 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:44848 --047d7b15ae9fe8567604dc12685e Content-Type: text/plain; charset=ISO-8859-1 On May 6, 2013 10:39 AM, "Joshua Landau" wrote: > > On 4 May 2013 00:42, Ian Kelly 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. > > >> >> 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. --047d7b15ae9fe8567604dc12685e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 th= at
>> it has two different notions of the ball's position that are n= ot
>> necessarily in agreement. =A0There is the ball_rect, and there are= also
>> the x and y variables.
>
> <snip>=A0
>>
>> You should be careful to make sure these
>> 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 posit= ion 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 t= ry to use Rects only when representing pixels on the screen. Pygame has a l= ot 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 -- ar= guably 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 g= oing to limit the number of reasonable integer velocities available.=A0 For= games where logical coordinates and screen coordinates need to be separate= d though, I agree.

--047d7b15ae9fe8567604dc12685e--