thanks for responding to my questions. and thanks for the helpful ideas. i'm still very much in learning mode with pygame. with python too actually.
On 9/5/15, bw <stabbingfin...@gmail.com> wrote: > It's convenient. Also, in my experience move() is faster than "rect.x += > 1; rect.y += 1" even though it creates a new Rect object. > > I use it in the case where I have a map of objects that is bigger than > the screen. The screen is a viewport that pans around. move() is > valuable in converting the objects from real space to screen space. > > On 9/5/2015 6:29 PM, tom arnall wrote: >> you mean by manipulating Rect.x etc? yep that works fine and that's >> how i handle the problem. >> >> but why have the move() method in pygame at all? i mean, what do >> people use it for typically? >> >> >> On 9/5/15, bw <stabbingfin...@gmail.com> wrote: >>> You are correct, sir. The Rect methods convert your inputs to int, at >>> which point precision is lost. If we want finer spatial calculations we >>> must keep them in forms that don't lose precision, and apply them to the >>> Rect object as needed. >>> >>> On 9/5/2015 2:52 PM, tom arnall wrote: >>>> The docs say the Rect.move() can take only integers for the offset >>>> parameters. My experiments seem to verify that. This means that it can >>>> move an object in only a few directions, i.e., 1,0 for 0 degrees, 1,1 >>>> for 45 degrees etc. You can of course increase the magnitudes of the >>>> offsets and get more angles, but then it is impossible to create the >>>> effect of smooth movement. >>>> >>>> My take anyway. Am I missing something? >>> >> > > -- ..... “Once you can accept the universe as matter expanding into nothing that is something, wearing stripes with plaid comes easy.” Albert Einstein ..... “I have no special talents, only a passionate and stubborn curiosity.” Albert Einstein
