chris clepper wrote:
On 1/25/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
if this is what you meant by having "to clean up some code based on platform assumptions in order to make it work", then i'd answer "YES".
The other option is to add in those platform and vendor specific defines by adding a __APPLE__ to the preprocessor check.
i don't like this: it would make another bunch of work whenever GL_APPLE_texture_range is available on non-apple platforms. (who says that this will never be?) on my linux-PC "GL_SUN_slice_accum" is as supported (i just randomly picked one).
Either way is about the same amount of work, but moving to GLEW also introduces a dependency on another lib for GEM. Hopefully, they keep it up to date on all three platforms.
i was thinking of including glew in Gem, as it is really just 2 files (glew.c and glew.h) and regenerate from time to time.
note on "regenerate": most of the code in glew is generated from the openGL-specifications. they provide a generation-script which queries http://www.openGL.org for all available extensions and whatever. so people can keep it uptodate themself.
The other assumptions are any places where __APPLE__ really means PowerPC and so on.
well imo __APPLE__ should mean PowerPC and MacIntel....and nothing else!
mfg.asdr. IOhannes