Python at Perth IGDA meeting

I've just got back from an networking session organised by the IGDA chapter in Perth, Western Australia (that's my home city). For more information, read Nick Lowe's take on the event.

I caught up with some like-minded individuals, and some game producers who are looking to start up a dev shop in Perth or Melbourne. The interesting thing is... they are looking for Python programmers!

In fact, Python dominated a lot of the conversation. People are really waking up to the productivity gains a high level language like Python can provide. I've been asked to provide a demonstration of 2 or 3 games I've worked on (tommorow, at a local University), and the technology behind them. Should be fun!

Rubbery, bouncy sprites are my next big thing.

QGL is limited.

• It has no shadows.
• It has a slow culling algorithm.
• There is no animation support for 3D models.

I'm not going to be able to fix any of these problems while I limit myself to pure Python (see my previous post about this). Unfortunately, it is very hard to build a decent looking 3D game without these features. I'm not giving up on Python, and I still want to build some unique, visually appealing games using Python. So, if not 3D, what can I do to next?

I'm going to focus on a new idea I've had, which will let me create morphable, bouncy sprites. The inspiration comes from Gish, and the wobbly windows I've been throwing around the screen in Compiz/XGL.

If I map a texture onto a grid, instead of a single quad, I will be able to morph the texture by morphing the vertexes of the grid. Simple huh? I could morph the grid vertexes by interpolation between key frames, or by algorithm (think of a sine wave ripple effect).

I could even tie the vertexes together using verlet integration and a constraint solver, which would let me create bouncy, rubbery sprites which can morph in response to collisions. This requires getting my head around some new (to me) mathematics, which will take some time.

Stay tuned.

OpenGL-ctypes 3.0.0a4 works for me.

I've managed to install OpenGL ctypes 3.0.0a4, and have run the QGL tests.

Everything worked as expected, except for the lighting tests. I suspect that my lighting code is at fault, as I've had intermittent problems with the lighting code on ATI cards. I ran the tests under Xgl which may have effected things which I don't know about...

Back into the dark ages...

I've been experimenting with the OpenGL shadow extension. It can produce very nice shadows, and it is quite easy to implement.

I want to make it usable from QGL, which presents a problem. Speed.

I have to make multiple passes through my scenegraph to render a depth map from the POV of each light in the scene. Each extra pass QGL makes over the scenegraph is going to consume frames per second.

I've previously written a render visitor in Pyrex, which only provided a minimal speed increase. I think this is because the double dispatch pattern I'm using requires a couple of python function calls for each node that is rendered.

It seems that the only way to get around this is to move the entire scenegraph data structure into a C extension, providing an API to allocate and modify C structures from my Python code. This effectively means ditching the current QGL and writing a C render engine, which is not something I intended to do.