On Sat, Apr 18, 2009 at 8:05 PM, Toni Alatalo <
antont@xxxxxxxxxxxxx> wrote:
> Yanom Mobis kirjoitti:
>>
>> So writing a game in python and pygame usually doesn't involve writing
>> C/C++ code?
>>
>
> correct. i think most of the pygame written full games are just py. i
> personally also have so far not encountered speed probs in our
pygame
> projects, they are all just py so far 'cause the libs have provided what
> have needed.
>
> some pygames have parts in native code, like iirc galcon had something,
> probably related to the large amount of 'swarming' ships it has going
> around? as it is relatively slow to iterate thru hundreds or thousands of
> things in a for loop in Python to do things on an individual basis for them.
> so for example you can't iterate thru every pixel in a bitmap in Python to
> manipulate them and expect it to run with some acceptable fps.
>
> that's why there's the surfarray module, to enable numpy usage, so you can
> from Python define operations to be done individually for every pixel, but
> have the c written native code do the iteration with optimal speed. i found
> it very interesting how Theo de Ridder had done swarming / mass movements
> using numpy in Blender
(saw his presentation at BConf07), and am looking
> forward to testing that array manipulation technique for movements myself
> too (perhaps Pygame spritegroups or something could implement the buffer
> protocol / provide numpy access somehow, for e.g. changing all positions of
> the sprites with one call from py?)
>
> but if you don't need to touch thousands of individual things every frame,
> you're probably just fine with normal Python without c or numpy. there are
> nice libraries for collision detection etc. too.
>
> typically performance problems are about lacking data structures (like space
> partitioning) or otherwise dum code, and it's easier to make it faster by
> doing something clever in py instead of porting a slow algorithm to c (if
> it's dum it may remain slow in c too).
>
> ~Toni
I agree with you in spirit but sometimes in practice C code
can get
you out of a tight spot. It is a LOT faster than python. 1000 to 10000
times faster. Sometimes that dumb code will be fast enough in C, that
you can then get on with the next part of the program. That said, slow
python code usually is from bad programming. Also, I find writing in C
to be a major pain after getting good with python.
--
Douglas E Knapp
Why do we live?