Jon Leech wrote: > > I've updated the ABI project specification at > > http://oss.sgi.com/projects/ogl-sample/ABI/ > > as well as the glext.h/glxext.h/wglext.h linked to from there. > Hopefully they're now synced up with recent decisions by the group. > Please review the spec, try out the headers, and report problems - > except for bugfixes, we should be basically done now. > > In response to various issues/questions raised last week: > > - Steve asked whether there was a GL_GLEXT_VERSION token. Yes, > although it was named GL_GLEXT_VERSION_EXT until just now, in > response to Allen's observation that we were defacto carving out a > GLEXT namespace. Note this versions glext.h, not the ABI. For > consistency's sake, glxext.h and wglext.h have been updated to > define GLX_GLXEXT_VERSION and WGL_WGLEXT_VERSION. > > - glext.h is specified to be included by default from gl.h, likewise > glxext.h from glx.h. > > - We voted (in the noncontroversial portion of the original vote) > to: > > > Vote #1 (vote YES or NO): Add a preprocessor define specifying that > > the oglbase compiletime environment exists and specifying the > > oglbase version implemented. The symbol is GL_OGLBASE_VERSION. > > If defined, its value is (1000*major_version+minor_version). > > This should be defined in gl.h, and is the oglbase version number > (e.g. it will be '1000' once we finalize). What's needed for finalization? I'm working on the last of the updates for XFree86 4.0.1 and would like to incorporate the Linux/OpenGL standard files. > Thus, per option C, gl.h > should contain a fragment something something like this: > > #ifndef GL_GLEXT_LEGACY > #define GL_OGLBASE_VERSION <version #> > #include <GL/glext.h> > #endif > > Likewise for glx.h, GLX_GLXEXT_LEGACY, and glxext.h. The current > draft of the proposal is not completely consistent on GL_GLEXT vs. > GLX_GLXEXT. I incline that having separate symbols is a good idea > from a flexibility and namespace-pureness standpoint but it gets > wordy and perhaps hard for ISVs to remember. OTOH they are not going > to be defining either symbol very often, if we succeed in > standardizing the ABI. I'm in favor of separate, distinct GLX symbols. It's not that complicated. > - With this scheme, apps can either do: > > #define GL_GLEXT_LEGACY /* or -DGL_GLEXT_LEGACY in Makefile */ > #include <GL/gl.h> > <traditional stuff> > > or > > #include <GL/gl.h> > > #ifdef GL_OGLBASE_VERSION > <oglbase specific stuff> > #else > <traditional stuff?> > #endif > > - glext.h now includes both prototypes and typedefs. By default, > prototypes are conditionally compiled out. They can be enabled by > #defining GL_GLEXT_PROTOTYPES before #including <GL/gl.h>. Likewise > for glxext.h (here's where the schiziness enters in - should > probably use GLX_GLXEXT_PROTOTYPES). Regarding glxext.h: 1. There's a typedef: #ifndef GLX_ARB_get_proc_address typedef void (*__GLXextFuncPtr)(); #endif which isn't in the spec for GLX_ARB_get_proc_address. Where did that come from? I don't necessarily object to it, but the spec should be updated. 2. There's a number of Mesa GLX extensions that I'd like added to glxext.h. I'll send specs to you, Jon. > > - Fixed MAX_ACTIVE_TEXTURES_ARB -> MAX_TEXTURE_UNITS_ARB per Brian, > CYGWIN32 -> CYGWIN per Suhaib. Hmm, the glext.h at http://oss.sgi.com/projects/ogl-sample/ABI/glext.h still has MAX_ACTIVE_TEXTURES_ARB. Also, GL_EXT_subtexture is still defined in two sections. The second section get skipped because the first one #define's GL_EXT_subtexture. > > - ABI specification updated to version 0.9.8. > > - A few more extension specifications added to the registry. -Brian
