Author archives: Mike

pip's changes to not install pre-release software caught me up on my bad habit of just leaving alphas and betas of little-used packages that pass testing up as the "final" release. While I'm going to have to get that habit quashed, I've updated OpenGLContext-full in the meantime to pull the correct betas and have pushed ...

Went through my piled-up PyOpenGL email from the vacation and tried to address the various bugs and issues. Other than confirming a fix on hardware I don't have we should be pretty close to ready for a second beta. I regenerated the extensions based on the latest khronos api svn, so we should be pretty ...

So I wanted to work on a little web-toy that would let kids "hunt" for high frequency words  (basically vocabulary words that need to be immediately recognized) in a field of words. But as they don't necessarily know the words yet, it needs to be something that's read out audibly "Click on <blah>" and then I ...

We've had a binding/platform for the Off-Screen Mesa (OSMesa) library for a while now. It was originally coded such that it provided all of the OSMesa entry points from the platform package (not really appropriate, as these are the same level as things such as GLX and WGL). Long story short, they've been moved to ...

I decided to use a USB key root for the RPi, and with that got a standard Raspbian setup going.  The really nice thing is that the EGL, GLES, etc entry points all resolved properly with the same code used for Linux/MESA EGL and GLES, yay.

Thing is, without the broadcom graphics module they're a ...

So as part of getting a PyOpenGL demo running on the Raspberry Pi I wrote a trivial subset of the Broadcom graphics interface api in ctypes.  There's an (abandoned? not very recent, anyway) full wrapper in Cython, but even getting that compiled just took too long for me working on the Pi (far longer than ...

There were (and still are) lots of places where PyOpenGL code assumed (assumes) that it is running GL. So far my cleanup efforts mean that on importing e.g. GLES1 you don't actually trigger a load of OpenGL. They also mean that most DLLs are lazy-loaded, something that means e.g. GLUT should no longer load on ...

There are a number of places in PyOpenGL where GL has been arrogantly assumed. In particular, error handling and the shader/VBO convenience code.  The result was that you'd wind up having GL error-checking in GLES or trying to create GL VBOs under GLES. I've done a bit of refactoring to get the error-handling squared away, ...

Needed an FTP server. 25 lines of code later an FTP server that listens on a particular interface serving files from a given directory, and half of those 25 lines are about processing command-line arguments, getting network addresses and otherwise doing "not FTP" work.

OpenGL often has situations where an argument is actually an output. PyOpenGL has traditionally wrapped those entry points such that they would be removed from the inputs and returned as an output.  I've just checked in code such that for most PyOpenGL entry points you can use either the Pythonic or the C-ish pattern (i.e. ...