Easy usage of GL 3.1 / 3.2 extensions in C++

Neither method (static-linking .lib vs win32 getprocaddress) is better. Well, static linking is a wee bit faster, not that it matters:
“call xxxPatchedAddress” // some older compilers make this a jmp+call, though.
vs
“call dword ptr [xxxDynLoadedAddr]”

So, just do these things the way you like :slight_smile:

hey ijc12, that’s great. Do you mind if i host it on my website? it’s probably quite useful for others as well.

I don’t mind.

Although it should probably contain a readme file with a little explanation or something. Or you could just add a readme.txt with a link to this thread.

@ijc12:
Is it correct to use GetProcAddress instead of wglGetProcAddress. I read somewhere that depending on pixelformat, active rendering context can return different entry points when you use wglGetProcAddress.

Long time ago I made similar tool (parse glext.h and wglext.h) and generate cpp file (glExtMap.h & glExtMap.cpp). Generated code is almost the same as yours except I added flags structure for checking extensions (collect all known extensions and add flag in big bit-field structure).

But… I lost parser source code and all I have is parser executable :slight_smile: Today, Im too lazy to write new parser, so I’ll use your work. Thank you very much.

GetProcAddress returns null for funcs the opengl32.dll doesn’t export. (use Dependency Walker to see the list of exports) . It is not hooked, as the set-in-stone static linking easily renders that useless. Instead, the exported funcs are hooked by design, (note: the funcs’ addresses stay the same). For example, in opengl32.dll, this is glBindTexture():
mov eax,dword ptr fs:[00000018h]
jmp dword ptr [eax+0A08h]

wglGetProcAddress is also hooked in a similar way by the video-driver and returns context-dependent func-addresses. For funcs that are not already on the static-lib’s exports-list.

ijc12, you want to write a README and i’ll add it to the zip you linked to?

Is it correct to use GetProcAddress instead of wglGetProcAddress. I read somewhere that depending on pixelformat, active rendering context can return different entry points when you use wglGetProcAddress.

I don’t know if it’s strictly correct but it’s the only way to get function pointers to certain functions since wglGetProcAddress won’t return them. In any case GetProcAddress is only used for gl3 and only when wglGetProcAddress fails. Maybe using function prototypes instead of function pointers would be more correct for these implicitly linked functions, I don’t know.

@James

I added a little readme file, you can put this version on your page

http://www.megaupload.com/?d=6XBRFUN7

Sorry for the late reply,

I uploaded the latest version from ijc12 here:
http://www.phasersonkill.com/dl/gl%20init.rar

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.