[GEM-dev] glew again (was Re: Gem vs ATi fglrx vs GLEW vs OpenGL 2.0)

[IOhannes m zmoelnig]

Claude Heiland-Allen wrote:
> IOhannes m zmoelnig wrote:
>> Claude Heiland-Allen wrote:
>>> Hi all,
>>> The large numbers for the shader ids look a bit suspicious to me, as 
>>> does the "no attached shader objects".  Would be useful if "GL: 
>>> invalid value" could be made more verbose, too.
>> could you re-check (with current CVS) whether the shaders now work?
>> the ID's will/might still be large numbers, but it should work 
>> nevertheless though...
> 
> I'll check as soon as possible (early March).

so now that we have tested and succeeded let's move on:

i have put more code on the way to glew into Gem proper, so you 
shouldn't need to do this manually any more.

just specify "--enable-glew" at configure-time to turn it on.
you don't need to have glew installed on your machine.




so speaking of glew, how should we proceed here?
right now, glew is a compile-time option, which adds another layer of 
#ifdef's which in turn is really ugly: glew is supposed to make code 
more readable, not less.

i would suggest to just do all builds of Gem with glew linked in, and 
gradually add the runtime checks as someone stumbles across them.

until all of the problematic objects have proper tests, these objects 
might eventually crash pd (when calling null-pointer functions), but at 
least you can load Gem - as opposed to the well known glUniform4i 
refusal to load Gem and weird maximum openGL-version compile-time hacks.

what do you think?

fgmasdr
IOhannes