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@12 referenced in function "protected: virtual void __thiscall fragment_program::printInfo(void)" (? printInfo@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