Re: [pygame] strange compile error with cocoa

2009-07-14 Thread René Dudfield
hi again,

I get this error when trying to compile after a git pull.

building 'pygame._camera' extension
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall
-Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE -arch
i386 -arch ppc -pipe -Ddarwin
-I/Library/Frameworks/SDL.framework/Versions/Current/Headers
-I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-c src/_camera.c -o build/temp.macosx-10.5-i386-2.5/src/_camera.o -C-W
-C-Wall
In file included from
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12,
 from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
 from src/camera.h:49,
 from src/_camera.c:36:
/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:124:
error: stray �...@’ in program
...
etc


ps.  for others to download it and try it out:
git clone git://github.com/ab3/pygame-mirror.git


cheers,

On Tue, Jul 14, 2009 at 9:00 AM, René Dudfield wrote:
> On Tue, Jul 14, 2009 at 8:58 AM, el lauwer wrote:
>> Ok, good news, with the current version of the camera module, I am able to
>> grab a frame from the camera, copy it to the SDL_Surface and display this
>> image in the display.
>
> awesome. nice work!
>


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

2009-07-14 Thread Paulo Silva
@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  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  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 con