Suitability for games?

[srenner at lycosmail.com]

 This is the general
> principle -- Python can still perform quite well as a higher level
> controlling system (which can include a lot -- GUI, loading/saving,
> scripting of in-game objects and events, etc), even when it's not
> fast enough to do low level graphics manipulation. You use a C or C++
> library for that, but you can wrap those with Python.


"A C or C++ library" meaning Mesa or another OpenGL implementation, if
you want to use hardware accelerated graphics. PyOpenGL is available and
being maintained actively by David Ascher. I help maintain the demo
directory. If anyone has trouble installing or running the module, I'll
try to help -- mail me.

>
> For object scripting, there are some interesting developments. Python
does
> not have 'simulated threads' by default. [ Discussion of threads]
> So I'd recommend Python for game scripting. . .

Well, threads are interesting, but the rendering has to all happen in a
single process --  one can't very well have multiple streams of OpenGL
calls being shuffled together. The new nvidia chip has 4 pixel
pipelines. Presumably each pipeline has a separate context (state
machine) and so the chip could be driven by 4 renderering threads. But
you would want to balance the loads so that each pipeline was doing
about the same amount of work per frame. It's not like Guido's Brownian
motion demo with one thread per 'object', because the objects will have
to be in heirarchies for any reasonably sized and detailed scene. Now,
one might have two phases, rendering and 'world update', with objects
updating themselves in threads, but the rendering can't be split. As
long as the update doesn't step on the renderer . . .

Actually that sounds good. Watch the PyOpenGL demo directory for an
implementation.

sr


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.