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.<br>
<br>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.<br>
<br>On Mon, Mar 3, 2008 at 6:46 AM, IOhannes m zmoelnig <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
so speaking of glew, how should we proceed here?<br>
right now, glew is a compile-time option, which adds another layer of<br>
#ifdef's which in turn is really ugly: glew is supposed to make code<br>
more readable, not less.<br>
<br>
i would suggest to just do all builds of Gem with glew linked in, and<br>
gradually add the runtime checks as someone stumbles across them.<br>
<br>
until all of the problematic objects have proper tests, these objects<br>
might eventually crash pd (when calling null-pointer functions), but at<br>
least you can load Gem - as opposed to the well known glUniform4i<br>
refusal to load Gem and weird maximum openGL-version compile-time hacks.<br>
<br>
what do you think?<br>
<br>
fgmasdr<br>
IOhannes<br>
<br>
_______________________________________________<br>
GEM-dev mailing list<br>
<a href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a><br>
<a href="http://lists.puredata.info/listinfo/gem-dev" target="_blank">http://lists.puredata.info/listinfo/gem-dev</a><br>
</blockquote></div><br>