partiallydisassembled.net

Toby's wish, my command?

2006-09-01 20:56:15

Yup, pyglet.GL now has all the OpenGL header, obviating need for PyOpenGL (eventually, it still uses it internally at the moment). It has a repository now, too, so you can see that I'm not just making it all up! http://code.google.com/p/pyglet/ Timings of glColor3f show that it's around 3x slower than PyOpenGL, and 2x faster than OpenGL-ctypes.

Toby writes:

What causes the speed difference?

Alex writes:

ctypes in inherently slower than calling an extension module function (checking and conversion of argtypes and restype I imagine, though I've not looked into it). Faster than OpenGL-ctypes because mine does not do error checking or function name overloading (again, presumably that's the major cause).

comment

*-ctypes

link comment

2006-08-31 00:28:59

Thinking about how easy this is getting. Toby was asking about using ctypes for all of OpenGL, not just the stuff missing from PyOpenGL. Yes, somebody's working on this (Mike Fletcher), but there could be reasons for doing a more straightforward wrap. For example, performance would be better (no type checking or error checking), and there would be no behind-the-scenes "magic". The programmer would have to be more responsible with memory though (I'm all for this, having just worked around a memory leak in PyOpenGL). Another thought: what about a pure Python windowing library. Something that does the job of SDL (for me, that means bringing up an OpenGL context and grabbing events), but without needing any libraries that are not provided by the operating system. Bindings for (parts of) X11 and GLX would be needed. Win32 and Cocoa bindings are already floating around. Of course, the first thing a person would implement is multiple window support. Besides crafting it how you like it, and probably worse performance than SDL, we would also get games with no dependencies besides Python (and that goes, too, with statically-compiled PyPy binaries).

Richard writes:

That's a heckuva sales job you've got there - where do I buy one? :)

comment

pyglet.GL (GLEW-ctypes)

link comment

2006-08-28 22:01:45

This was easy: convert GLEW's definition files into Python source files that access GL extensions (and later than 1.1 versions) with ctypes. The result is a big tidy up of the boilerplate at the start of my earlier GLSL demo. For example, to get all of OpenGL 2.0 functions (and 1.5, 1.4, etc): from pyglet.GL.VERSION_2_0 import * or, if you'd rather work with the ARB extensions: from pyglet.GL.ARB_vertex_program import * and etc. All of GLEW's extensions are in there. The nice thing about doing it this way is that testing for an extension is as simple as catching an ImportError. This code needs a home. It's in the "pyglet" namespace, which will be my ctypes alternative to Pygame (more on that in a later post). Probably it will go on the Google Code repository, because it has nice uptimes and an issue tracker, unless someone thinks it'd be better in Pygame's repository (I can't think of a reason).

Toby writes:

Nice. Do you get all of OpenGL wrapped this way? Is it going to be possible to do away with PyOpenGL? It looks that way, but I might be missing something.

Alex writes:

At the moment I'm grabbing function prototypes etc from the GLEW definition files, but it would be trivial to adapt them to gl.h. Even easier would be to just run gen-ctypes over it and clean up whatever comes out. I wouldn't want to do that over PyOpenGL though, which gives you the nice overloading (i.e. glTranslate instead of glTranslatef) and Numeric integration. There is an OpenGL-ctypes in CVS on the PyOpenGL sourceforge project being developed by the vrplumber.com guy. It's been running fine for a few months now but not sure when a release is planned.

Toby writes:

Honestly, I can live without the overloading - in fact, that makes it more difficult to prototype in python and then reimplement in c++. For a lot of opengl code (not using the type-free function variants), you can actually cut-n-paste, add ;'s and you're away. As for Numeric support, has anyone actually used it to implement something that a) couldn't be done on the GPU, given available GLSL bindings, or b) couldn't be done with pyrex or a small c extension? Something that can track the evolving GL standard + extensions without (significant) development effort is IMO much more valuable.

comment

Psychonauts

link comment

2006-08-23 19:37:03

Haven't done much work at all the last few days, because my neighbours are substance abusing anarchists. When I politely asked them to turn down their music (which they play from 9-5 every day, presumably to enhance the trip), they informed me that I was the 4th neighbour to complain, that they would do whatever they liked, and that I should take it easy. They then repeatedly chanted "life's too short" while I tried to excuse myself. Time to move house!

comment

Pygame-ctypes: 0.09 and eggs

link comment

2006-08-20 18:29:31

Decided that eggs are a good idea, so Pygame-ctypes and SDL-ctypes now have binary eggs. These are cool since * it's easier to use them without installing anything * they can download their dependencies (or more to the point, games can download Pygame as a dependency automatically). 0.09 release with its eggs is on the Pygame site now. I can't say the word "eggs" without hearing Homer Simpson say, "eggsactly... doh!" in a Mr Burns, "excellent" impression. Today (or tomorrow, depending on your timezone) is also the last day of SoC, so any further work I do on this is purely voluntary and not motivated by greed ;-)

foo writes:

eggscellent ;-)

comment