Welcome. Maybe you'll find the attached tiny example informative, then.
You'll find move() used in the rendering part of the game loop. Feel
free to do what you want with it.
On 9/5/2015 9:27 PM, tom arnall wrote:
thanks for responding to my questions. and thanks for the helpful
ideas. i'm sti
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 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
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
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 wrote:
> You are correct, sir. The Rect methods convert your inputs to int, at
> which poin
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
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 a