I use Numpy to control particles drawn with OpenGL. Since PyOpenGL can
take a Numpy array of coordinates and render it as shapes or points,
all the actual work is done outside Python. I can make bursts or
streams of thousands and thousands of particles, each with its own
position, color, lifespan, velocity, and acceleration, then render the
effect inside of a game running at 60 FPS without a problem.
-Zack
On Apr 18, 2009, at 2:05 PM, Toni Alatalo 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
--- On *Fri, 4/17/09, J Dunford /<smilecha...@smilechaser.com>/*
wrote:
From: J Dunford <smilecha...@smilechaser.com>
Subject: Re: [pygame] C/C++ and Python
To: pygame-users@seul.org
Date: Friday, April 17, 2009, 4:51 PM
On Fri, Apr 17, 2009 at 3:10 PM, Yanom Mobis <ya...@rocketmail.com
</mc/compose?to=ya...@rocketmail.com>> wrote:
I've heard some games are made with C/C++ and Python together.
Where does Pygame fit into this?
That really depends on the game. Some games, such as Civilization
IV, use Python as an embedded scripting language. This allows the
developer to write the performance intensive parts in C/C++ and
the game logic in Python.
Users of pygame generally operate in the reverse direction. They
have a Python program that deals with all the high-level concepts,
but then delegates the fiddly low-level stuff to the Pygame
library.