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

[Paulo Silva <nitrofurano@xxxxxxxxx>]

@Zack - here is the smaller example i were promissed -
http://pastebin.com/f65869385 - an idea about handling 4 players on
one keyboard - a very fun experience i wished to see more common on
Pygame games! ;) - it recalls a bit like those early 90's arcade games
with 3 or 4 players on the same machine and playfield (like Simpsons,
Ninja Turtles, X-Men, etc. - or even Warlords from early 80's)

and sorry this example not being pythonic yet - from people used to
code from 25 years ago, not knowing these new coding features, on an
almost 40yo guy, this process of learning is not that fast - but of
course, any help on showing what for are they used, how it works, and
a theorical idea of how the Python interpreter deals with it, and
being assured all the come doesn't became an undebuggable mess, is all
very important and useful (all these points are very important for
learning them)

but there are still a lot of obstacles: for example, that tuples
example you shown, mixing strings with integers (or floats) are
hugelly confusing  - but otherwise, example_list looks simple and
interesting (assuming there are no differences between lists and
arrays?)

thank you a lot about all help provided! :)


On 7/14/09, Zack Schilling <zack.schilling@xxxxxxxxx> wrote:
> 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,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>