Category archives: Snaking
Discussions of programming, particularly of programming Python RSS
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 OpenGL/osmesa instead. Code that uses OSMesa in PyOpenGL can just update the imports to
# from OpenGL.platform import *
from OpenGL.osmesa import *
to get the entry points that have moved.
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 writing a ctypes wrapper).
The little wrapper module needs work to be usable, but I don't really have the interest needed to do what needs to make it truly useful. What really seems to be needed is to take the 5 or 6 ...
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 every PyOpenGL import. However, a lot of the helper code is still GL-arrogant, and that includes such basic things as the array handlers (which import OpenGL to get access to constants, etc) and the VBO module, which has a pluggable implementation, but ...
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. if you do not pass in a value, you get a new array, if you do pass in a value, your value is used).
Client code should not require any changes, but it should allow exotic things such as passing in VBOs, memory-mapped ...
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 bit useless, as the EGL Native types are all BCM data-types (I can query configurations, etc, but I can't actually put anything up on screen). There's a Python wrapper for broadcom, but so far it's taken way too long even ...
So Pygame based EGL + OpenGL-ES1 context works with PyOpenGL 3.1 under Kubuntu amd64 with MESA EGL/GLES. Yay.
Really do need to get a couple SD cards ordered so I can port to the Raspberry Pi too. I expect that will be a matter of just getting the proper library-names defined in the platform loading code. Likely should rename the "egl" platform to "mesaegl" too, as I expect we'll need to differentiate between the various EGL/GLES platforms.
It seems like it might be possible to make an OpenGLContext base context for EGL too (basically a Pygame context ...
PyOpenGL and PyOpenGL_accelerate 3.1.0b1 are now up on PyPI. There's MS Windows 32 and 64-bit installers for the windows-ians. The main "features" planned for the 3.1.0 release (and available in the beta) are:
- raw wrappers generated from the ARB source XML definitions, this means that it covers a lot more extensions, including GLX, WGL, EGL extensions (partially from Roman Valov)
- heavily restructured internally to make sub-packages less inter-dependent (raw hierarchy is now somewhat self-contained)
- same code-base for Python 2.6, 2.7, 3.3 and 3.4, Python 2.5 is no longer supported, 3 ...
So Python 3.3 and 3.4 require Visual Studio (Express) 2010 to compile extensions. I already had my machine setup with Visual Studio Express 2008 + the platform SDK to get 32 and 64-bit compilers for Python 2.6 and 2.7, but to release for the 3.x's I needed to get the new compilers. There is, however, a bug in the Visual Studio service pack that deletes the 64-bit compilers the SDK has installed. There's a KB article that lets you download those compilers again, but the patch doesn't give you a vcvars64.bat file ...
Booted into Windows to get the PyOpenGL-Accelerate release compiled, and started following my standard "update windows, AV definitions, etc" pre-release steps... and Windows Update failed. Lots of fail (and 3 hours of trolling through MS support and trying dozens of different fixes intended to reset/verify/cleanup Windows Update state) later I wound up with some Windows Fixit thing that managed to tweak whatever lever was in the wrong place so that the update can actually start.
It's a good thing to boot into Windows every once in a while to remind yourself what it was like.
[Update] And ...