[GEM-dev] GL extensions on Windows

[james tittle]

On Dec 12, 2005, at 6:37 PM, chris clepper wrote:

> I have attempted to build a version of GEM on Windows that supports  
> GL greater than 1.1 without success so far.  Google has given me  
> some conflicting info about the process stating 'use SGI glext.h'  
> or 'don't use anything from SGI' or 'use GLEW or the like'.  I have  
> glext.h which allows for a clean compile but linking always fails  
> with something like this:
>
> fragment_program.obj : error LNK2019: unresolved external symbol  
> _glGetProgramivARB at 12 referenced in function "protected: virtual  
> void __thiscall fragment_program::printInfo(void)" (? 
> printInfo at fragment_program@@MAEXXZ)
>
> Well, duh.  The MS opengl32.lib obviously knows jack about the  
> changes to GL since 1996.  It doesn't look like an alternative lib  
> exists.  So what the heck does one do?  I have a little sample code  
> that basically cuts and pastes the typedefs from glext.h into the  
> source, assigns a pointer to a local var and doesn't include  
> glext.h, but that seems like an obnoxious way to deal with the 800  
> billion extensions since GL 1.1.

...well, maybe this is the time to roll glew into gem:  seems we've  
got enough reasons to do it now!  But until then, I'd look at some of  
the tutorials from gametutorials.com (especially the later/newer  
ones), and see how they're dealing with it all...they are all in  
win32...

...also check on opengl.org, I'm sure there's a FAQ there  
somewhere...like the following:

http://www.opengl.org/resources/faq/getting_started.html

l8r,
jamie