[OpenSCAD] Status OpenSCAD development

Don Bright hugh.m.bright at gmail.com
Mon Oct 17 06:51:51 CEST 2011

I did find this:


User "DarkUranium" had the same problem, solved by getting new glext headers.
He suspected an improper #define of GL_FRAMEBUFFER_EXT

I have been able to reproduce a 1280 error in a small framebuffer
program by editing my /usr/include/GL/glext.h  file and redefining
GL_FRAMEBUFFER_EXT to 0x0 instead of it's normal 0x8d40. Im guessing
the problem might be something weird is going on with headers.

I noticed that fbo.h doesn't include glext.h, but it includes
system-gl.h which in turn also does not include glext.h, rather only
GL/glew.h, which seems to have its own definition of
GL_FRAMEBUFFER_EXT, on my system, set to the normal 0x8d40. If i
re-write my small FBO program to use only GL/glew.h, and alter the
#define, it also produces a 1280 error.


On Sun, Oct 16, 2011 at 7:00 PM, Marius Kintel <marius at kintel.net> wrote:
> Hi again,
> I'm trying to get this to work in my Linux VM.
> I'm running Ubuntu 11.04 under VirtualBox 4.1.4 under Mac OS X 10.6.8.
> GLEW reports that I've got GL_EXT_framebuffer_object:
> $ glewinfo | grep framebuffer_object
> GL_ARB_framebuffer_object:                                     MISSING
> GL_EXT_framebuffer_object:                                     OK
> The symptom is that it fails with error 1280 "Invalid Enumerant" on the first attempt to bind an FBO (which is the first FBO-related call which is executed).
> I might dig deeper into this later on, but I just wanted to send this in case it looks familiar to anyone.
>  -Marius
> _______________________________________________
> OpenSCAD mailing list
> OpenSCAD at rocklinux.org
> http://rocklinux.net/mailman/listinfo/openscad

More information about the OpenSCAD mailing list