Addendum: Adding WX_GL_RGBA in addition to WX_GL_DOUBLEBUFFER as options to wxPython.GLCanvas also worked. Weird stuff, but probably this is a fault in wxPython (in combination with Vista?).

On Sun, Jan 24, 2010 at 9:56 PM, Nils Sudmann <> wrote:
Found the faulty code.

I was using wxPython GLCanvas and specified WX_GL_DOUBLEBUFFER. After rewriting the code to use old vertex arrays, it kind of worked, but a lot of other stuff was strange. It seems that WX_GL_DOUBLEBUFFER caused GL_VERSION to report 1.1.0 and probably disabled all the buffer object functionality and other stuff. Removing the doublebuffer option caused GL_VERSION to report 3.2.0 and everything worked!

Again thanks for all the help.

On Sun, Jan 24, 2010 at 3:01 PM, Alejandro Segovia <> wrote:
On Sun, Jan 24, 2010 at 9:15 AM, Gijs <> wrote:
On 1/24/10 12:06 , Nils Sudmann wrote:
> Hmm,
> I checked some versions and here is what I found:
> Vista - PyOpenGL 3.0.1b2, GL_VERSION = 1.1.0 (!!!)
> Fedora 11 - PyOpenGL 3.0.0, GL_VERSION = None (!!!)
> Suse 11 - At work, need to check this tomorrow.
> About vista, the GL_VERSION string seems odd. I tried a OpenGL
> extension viewer that reports OpenGL version 3.2. Again, I'm clueless
> to why PyOpenGL thinks it is dealing with a 1.1 driver.
> My Fedora server has a ATI X800 card, and AFAIK AMD/ATI has dropped
> support for "older" cards on newer kernels (ATI is on my do not buy
> list). But I managed to get it working somehow, at least glxinfo
> reports that everything is ok (OpenGL version string: 2.1 Mesa
> 7.6-devel). I did download and upgrade PyOpenGL to 3.0.1b2, but it
> still reports a GL_VERSION of None.
> So it seems that on both affected systems, there is something wrong
> with my GL setup.
Well, the problem on Fedora is that you are using the mesa driver. This
does some basic GL stuff but don't expect it do anything more than
render some polygons. You'll need to opensource ATI driver which gives
you more GL functions, or you could try out the driver of ATI. About
Windows, the OpenGL version 1.1.0 has something to do with the version
reported back by the OpenGL library itself. This will never report any
higher than 1.1.0 I think. You'd probably get a better idea as to why
this happens when you google for it.

You might have better luck trying out the ARB functions (glGenBuffersARB
and glBindBufferARB). These should work if your OpenGL installation is good.

I agree with Gijs. As far as mesa goes, it's just an OpenGL-like API which doesn't usually provide hardware rendering support. VBO's may well be out of its league. You are going to need the ATI driver here.

Regarding Windows reporting 1.1, it's not that weird. I've had NVIDIA drivers reporting up to OpenGL 2.0, but usually Windows does not provide functionality beyond 1.1 without the use of extensions.

As Gijs said, try using the glGenBuffersARB extension instead of glGenBuffers (I think it's under the OpenGL.ext package).

Let us know how it goes ;)


Regards, Gijs


Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
PyOpenGL Homepage
PyOpenGL-Users mailing list

If Atheism is a religion, then not collecting stamps is a hobby.

If Atheism is a religion, then not collecting stamps is a hobby.