[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] sprite collisions - looking for simple snippet



Making code more pythonic doesn't necessarily mean meeting the PEP8 style guidelines, it just means turning the ideas that you have into code in the most direct way that best uses the basic features of Python. For example, python's basic collection, the list, is not an array and works best when you don't use it as one. When you want to iterate through all the items in a list, you don't keep track of how many items there are and step through those numbers to address each data item.

example_list = [3,4.5,3,2,8.1,39]
for index in range(0,len(example_list),1):
	print "The number " + str(example_list[index]) + "is in the list."

That's a roundabout way of working with arrays in lower level languages.

In python, you should iterate through a list with this much more intuitive structure:

example_list = [3,4.5,3,2,8.1,39]
for value in example_list:
	print "The number " + str(value) + "is in the list."

This creates a loop in which each number or object in the list is substituted for "value" in turn.

Another example: Instead of creating multiple lists to hold multiple related values of different types, use tuples.

colors = [ ("Blue",0,0,255), ("Red",255,0,0), ("Green",0,255,0), ("White",255,255,255)]
print "Available colors:"
for color in colors:
	print color[0]

One of the most important things in python is writing clear and direct code. Once you're used to it, the barriers between your programming ideas and actual code will start to fall. Hope this helps you get started.

-Zack


On Jul 13, 2009, at 6:49 PM, Paulo Silva wrote:

@Zack:

'more pythonic' you mean PEP8? thanks a lot fixing the code, and
helping me sensiblelizing a habit on this codiing way

one thing i were trying to do is making the collision changing a
variable for the colour, and using 'screen.fill(collisioncolour)' just
once, as seeing the logic of your last code
http://pastebin.com/m25df2e2b , the result were not that different

one thing impressed me is that your last code seems to be much more
fluid - what you did on that?

on the other side, i'm still very far of understanding stuff like
'elif' or 'pygame.sprite.Group' - i am really having lots of
difficulties trying to understand how Pygame sprite groups work...

again, thanks a lot! :)

On 7/13/09, Zack Schilling <zack.schilling@xxxxxxxxx> wrote:
It only shows one sprite because you're filling the screen each and
every time you draw one. That's also part of the reason why your code
is so incredibly slow.

Delete this line:
screen.fill(0x998877)

And move it before the for loop:

  screen.fill(0x998877)
  for i in range (0,amnt,1):
    spridr[snum[i]].left=xpos[i]
    spridr[snum[i]].top=ypos[i]


But forget all that, what's much more important is writing code in a
more pythonic way. Look at this rewrite of your code. It's not perfect
(and still does some things strange ways for the sake of simplicity
and retaining the old structure) but it should help you a lot.

http://pastebin.com/m25df2e2b

-Zack

On Jul 13, 2009, at 3:12 PM, Paulo Silva wrote:

well, the exact answer i can say is 'yes and no'... ;)

the 'yes' is finally i can start understanding how collisions works on
pygame, and this is truly wonderful! thank you!

the 'no' is, when i did use 'if' over coordinates and size
calculations instead of collisions - http://pastebin.com/f38dfd442 -
it also shown just one sprite instead of from 'amnt' variable (i used
to try between 32 and 128), and performed hugelly slow as well... -
this is concerning me when i had some ideas on coding games with some
complexity on sprite ammounts (like doing some danmaku experimental
stuff or something in this way...)

for me were a surprise why both http://pastebin.com/m1e1c7c94 and
http://pastebin.com/f38dfd442 shown only one sprite - very weird...

overally, your correction will help me coding simpler snippets

thanks! :)   (and thanks also confirming subsurfaces are fine for
collisions - i'm still very newbie on Pygame! :) )



On 7/13/09, Zack Schilling <zack.schilling@xxxxxxxxx> wrote:
Well, this version runs. I'm not sure if it's doing what you want but
it does make a windows and draws some stuff. The subsurface splits
are
correct. I tried to make minimal corrections.

http://pastebin.com/m1e1c7c94

-Zack

On Jul 13, 2009, at 11:47 AM, Paulo Silva wrote:

@Zack - what i wanted were change the background colour to #FF0000
only when the sprites 0 and 1 collides - anyway, sorry this code is
not PEP8, and using abbreviated variable names - i came from
hobbystic
80's ansi-basic , where i were hugelly one-liner, and variable names only took 1 or 2 characters that time - i have deep bad habits from
that time, and learning PEP8 is still a huge barrier for me - be
welcome on breaking lines at ';' or rewriting variable names, if you
want...

@Henrique, if you can help fixing http://pastebin.com/f524a8cf2
would
be great - i understand what you were saying from the error message,
but i don't have any idea about the solution for that... - what i
coded there were the closest i could imagine as possible for having that working... - i even tried to avoid all default sprite collision
methods from pygame, and only using position and size calculations
for
collisions (outside of any def or class - i'm trying to avoid them
on
snippets like this), but the code became hugelly slow....

thank you all!


On 7/13/09, Henrique Nakashima <henrique.nakashima@xxxxxxxxx> wrote:
Traceback (most recent call last):
File "col.py", line 52, in <module>
 collide=pygame.sprite.collide_rect(sprid[0],sprid[1])
File "C:\Python25\lib\site-packages\pygame\sprite.py", line 1146,
in
collide_r
ect
 return left.rect.colliderect(right.rect)
AttributeError: 'pygame.Surface' object has no attribute 'rect'

This error happens because you are passing Surfaces to
pygame.sprite.collide_rect, not Sprites.

On Mon, Jul 13, 2009 at 12:27, Zack Schilling
<zack.schilling@xxxxxxxxx>wrote:

I tried to read and correct your code, but I have no idea at all
what's
going on. It's written like C++ transposed directly into python,
which is
confusing. It doesn't help that there are no comments at all and
the
variable names are cryptic. A big problem seems to be simply
feeding wrong
object types to all the functions. You're sending sprites to
blitters and
rects to the sprite collide.

I'll have a go at understanding what you want to do and making it
work,
but
I make no promises. If I can get that far, I'll also rewrite it in
a much
more pythonic way. Then you can compare the two and learn much
better
practices when working in python.

-Zack


On Jul 13, 2009, at 8:03 AM, Paulo Silva wrote:

hi!

well, for me finding a good pygame snippet with sprite collision
(and
simple to understand) is like finding a needle in a haystack...

but when i try do on my own, i get this:

Traceback (most recent call last):
File "_spritesheetexample15b4_difsiz_collision.py", line 47, in
<module>
collide =pygame.sprite.collide_rect(spridr[0].rect,spridr[1].rect)
AttributeError: 'pygame.Rect' object has no attribute 'rect'

the example is: http://pastebin.com/f524a8cf2

all suggestions are welcome! (be welcome also fixing that
pastebin,
and sending us the pastebin url with the fixes! ;) ) - sorry it's
not
PEP8 yet... :/

thanks! ;)



On 7/13/09, René Dudfield <renesd@xxxxxxxxx> wrote:

On Mon, Jul 13, 2009 at 7:32 AM, Paulo Silva <nitrofurano@xxxxxxxxx

wrote:

this reference i know from a long time, and figured out easily
there
were the exact methods to be used - the problem is i couldn't
have a
snippet working only following that - on my oppinion on that
referenence, each pygame method should have a working snippet
to be
tried out - for me is easier to work on tiny snippets, just
like with
lego bricks




Hi,

pygame comes with examples.  Either use those, or use the code
search
button
next to each method, to search through all the projects on the
internet
that
use pygame.  There's 238 results for spritcollide for example.


cu,