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

[chris clepper]

GLEW is going to create a mess for a while particularly for texturing.  The
only way to proceed is to use only GLEW and get rid of all of the current
#ifdef lines.  If you are going to do it then go ahead knowing that building
GEM from CVS might be broken for a bit.  I doubt many people are relying on
the most up to date builds though.

The one bad thing about GLEW is that it requires not only a context, but a
drawable window in place in order to work.  This means some of the checks
currently done in GemMan or in constructors will have to be moved to other
places.  Most likely doing a check in startRendering() and setting a flag
would work.

On Mon, Mar 3, 2008 at 6:46 AM, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:

>
> 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
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20080303/20368122/attachment.htm>