Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Problems with glext.h

I was just looking through the OpenGL updates on OS X Lion when I found something that now has me scared to use glext.h.

So, here's the bug. Lion's OpenGL.framework has a glext.h with the following definition.

typedef void *GLhandleARB;

But the glext.h from the OpenGL registry has the following instead.

typedef unsigned int GLhandleARB;

Now, the trouble is that when building for x86_64 on Lion we have sizeof(void*)==8, but sizeof(unsigned int)==4. So what do you trust? Lion's header? Or the OpenGL registry's header? Well, of course you trust the system headers, because apparently they claim to know that the ABI on 64-bit Lion has a 64-bit GLhandleARB type.

Now, this raises a few issues in my mind about various platforms:

  1. If you must use Apple's glext.h, but Apple's glext.h doesn't provide access to anything later than OpenGL 2.1, then how do you get at 3.0+ features on newer cards?

  2. Is it unsafe to use the OpenGL registry's glext.h on Linux? Or must you use the system's glext.h there as well? In that case, question #1 applies here as well.

  3. How the heck do you handle things on Windows, where there is never a glext.h on the system? You clearly can't use a driver vendor's glext.h, because different vendors may disagree on the sizes of various types. (Or is that not true?) What's the deal here?

like image 892
fieldtensor Avatar asked Nov 05 '22 16:11

fieldtensor


1 Answers

I see no problem. Just use OS/drivers provided headers. Or better use multi-platform OpenGL extension loader, that will do the trick for you. (eg. GLEW)

On the other hand in code you will use only GLhandleARB, not other things, so on Mac it will be void* - no problem, on Linux - something different - no problem, on Linux with AMD header - something entirely different - no problem.

Source code is portable across different platforms, not binaries, so I see no problem here.

1) You cant get better OpenGL if you use version served by Apple. So currently you can get max OpenGL 3.2 core profile on 10.7. (heard that Nvidia on some gpus bypassed it with its own headers with OpenGL 3.3, but have no way to check it myself).

2) It depends. If you target OpenGL 2.1 and below, open-source drivers support it, but higher versions are supported only by proprietary drivers, so you should use their headers. But in code you just put "#include ", and then link against appropriate header and .so library.

3) Do not know how things stand on Win. But probably vendors use glext from OpenGL registry.

But all of this is based on wrong assumption. You DO NOT have to know answers for them. Just use software that already know how to handle this burden. (eg. GLEW).

like image 139
przemo_li Avatar answered Nov 09 '22 15:11

przemo_li