PDA

View Full Version : header files, import and GL3+



Christoph Harder
10-26-2011, 08:55 AM
Hello,

I'm trying to create OpenGL bindings for flat assembler (on windows).
Therefore I need to parse the C headers, or at least I have choosen to do so. Well I have written a simple python script that does just that and it works quite well for the gl3.h and wglext.h files.

1. However I can't find the download location for wgl.h and glx.h, maybe you can give me a link?
Maybe it is even possible to create bindings without them? (I wish to target OpenGL 3+ exclusivly.)

2. But how would I create a 3+ context without a dummy context?
Can I use LoadLibrary and GetProcAddress to get access to wglCreateContextAttribsARB and if it is not available assume GL3+ is not supported?

3. Another Problem I have is understanding how OpenGL works when multiple different graphic cards are installed. Are there multiple OpenGL32.dll's? I exspect not, but how are different context on different graphic cards handled, especially if both cards have different features.
For example many 3+ tutorials first create a dummy context to get access to the wgl functions and then create a new context. But is it in any way guaranteed that the new context is handled by the same card?

4. Do you know any good and up-to-date tutorials that explain manual extension handling on windows? It seems GLEW is used almost exclusivly, but thats not possible with fasm.

Thanks in advance.
-Christoph

Alfonse Reinheart
10-26-2011, 10:24 AM
Therefore I need to parse the C headers, or at least I have choosen to do so.

That's probably not the best idea. Since you've done it already, I can't stop you. But I maintain more... chewable formats (https://bitbucket.org/alfonse/gl-xml-specs) of the OpenGL stuff here. It would have made your Python script much easier to write.

Also, I've added a fair number of fixes that you won't find in those C headers.


However I can't find the download location for wgl.h and glx.h, maybe you can give me a link?

wgl.h is a Windows header; it comes with the Windows SDK, which is generally part of whatever compiler install package you're using. glx.h is an X-Windows header; it similarly comes along with your Linux/*nix installs.


But how would I create a 3+ context without a dummy context?

You don't. Not on Windows you don't.


Another Problem I have is understanding how OpenGL works when multiple different graphic cards are installed.

If the cards are from different vendors, then it's simple: there is only one ICD. Therefore, one of them wins and the other loses. It's arbitrary, but I suspect it has something to do with the order of installation.

If the cards are from the same vendor, using SLI/whatever ATI calls their stuff, then it's also simple: it doesn't matter. The two GPUs are treated as one. You have one renderer, which you send commands to. The driver is responsible for sending those commands to the GPU(s) that need them.

So no, there is no way to guarantee this, but it's also not something that is likely to come up.


Do you know any good and up-to-date tutorials that explain manual extension handling on windows?

Most tutorials explain how to use OpenGL, not how to get function pointers, so talking about them gets in the way of the main thrust of the tutorial. However, you could just look at how GLEW does it. Or you could just read this Wiki article (http://www.opengl.org/wiki/Load_OpenGL_Functions).

Christoph Harder
10-27-2011, 04:51 AM
Hello,

thank you, you are a life saver.


That's probably not the best idea. Since you've done it already, I can't stop you. But I maintain more... chewable formats of the OpenGL stuff here. It would have made your Python script much easier to write.

Well I propably will switch over to the xml files, my script works now but I'm not sure it is save if anything gets changed.
I also looked at the .spec files, but since there seems to be no official format, I decided to not parse those (especially since in assemble I dont need much more than constants and function names).


wgl.h is a Windows header; it comes with the Windows SDK, which is generally part of whatever compiler install package you're using. glx.h is an X-Windows header; it similarly comes along with your Linux/*nix installs.

Okay so I can't assume that it is the same file for every compiler, right. Anyway I have seen you already have them as xml too. So no need to start with the headers (only if I wish to use your script myself). Thanks again.


there is only one ICD

Thanks for clearing that up (sounds wrong, sorry I'm not a native english speaker). Propably it is not that important anyway, seems like an unlikely setup.


Most tutorials explain how to use OpenGL, not how to get function pointers, so talking about them gets in the way of the main thrust of the tutorial. However, you could just look at how GLEW does it. Or you could just read this Wiki article.

Ah, I already read that wiki article, just couldn't find it again. And most other tutorials on the manual retrieval of function pointers still use the removed glGetString(GL_EXTENSIONS).

Just out of curiosity, do you (or anybody else) know if there is a difference between GetProcAddress and wglGetProcAddress? Seems like they provide the same functionality.

Thank you for your help.
-Christoph

Alfonse Reinheart
10-27-2011, 10:00 AM
`GetProcAddress` loads function pointers from a DLL handle. `wglGetProcAddress` loads function pointers from the OpenGL context that is current. You have to know what DLL you're using to use GetProcAddress, and Windows generally isn't going to tell you where the ICD's DLL is.

Christoph Harder
10-28-2011, 12:03 AM
`GetProcAddress` loads function pointers from a DLL handle. `wglGetProcAddress` loads function pointers from the OpenGL context that is current. You have to know what DLL you're using to use GetProcAddress, and Windows generally isn't going to tell you where the ICD's DLL is.

Again, thank you. I was thinking I could assume getting them from opengl32.dll.