Dav1dde
glad2 Documentation
C
- [x] Examples
- [ ] Quick Start
- [x] Options
Rust
- [ ] Examples
- [ ] Quick Start
- [ ] Options
Related issues:
- #161
One question to glad2, am I doing this right? gladLoadGLSimple(GLADsimpleloadproc())
Edit: In case yes, what speaks against:
GLAPI int gladLoadGL();
GLAPI int gladLoadGLProc(GLADsimpleloadproc load);
GLAPI int gladLoadGLProcUsr(GLADloadproc load, void* userptr);
Still deciding on the API, currently it's:
typedef void* (* GLADloadproc)(const char *name, void* userptr);
typedef void* (* GLADsimpleloadproc)(const char *name);
GLAPI int gladLoadGL(GLADloadproc load, void* userptr);
GLAPI int gladLoadGLSimple(GLADsimpleloadproc load);
GLAPI int gladLoadGLInternalLoader();
Maybe naming the functions according to what arguments they take is the better solution. My only set goal is to get rid of the gladLoadGL() which uses the internal loader, I want the default usage to be without loader (basically every windowing framework has a GetProcAddress implementation).
...So if I call gladLoadGLInternalLoader I don’t have to call gladLoadGLSimple?
Correct, you only need to call one of those three (calling these functions in total more than once may result in weird results).
ProTip: When calling the glad executable add --loader
The loader function names have also changed:
gladLoadEGLInternalLoader -> gladLoaderLoadEGL
gladLoadGLInternalLoader -> gladLoaderLoadGL
@Dav1dde
~~I just spent a while figuring out that gladLoaderLoadGL() was failing on certain machines because it didn't find the libGL.so.1 file. It would be nice to have more informative error information from this function.~~
Thanks, I am still working on the documentation, the wiki should be accurate: https://github.com/Dav1dde/glad/wiki/C
Interesting that libGL.so isn't available, what else is available?
I am not sure how I would do a better error handling. Return code 0 (false) is failure, return code > 0 is the loaded version, negative return codes would break the if (!load()) "idiom".
@Dav1dde:
It looks like the problem wasn't with dlopen.
So when a colleague in another department tries to run the following code(link below) he gets errors when calling gladLoaderLoadGL. This occurs on all his Ubuntu 16 machines, not his Ubuntu 14 machines, for me it works fine on several Ubunut 16 machines.
https://gist.github.com/BlGene/b78e237efb65086de3ef9e8aafdbef02#file-egl_gl2-cpp-L167
Is there anything we could do to give more meaningful debug information?
What error does he get, return value of 0? Glad would usually only fail if it cannot load an essential function (a function required to get very basic information, like glGetString), on a failed allocation (malloc, calloc etc.) or glGetString returning NULL where it shouldn't. For now the easiest way to figure that out why glad is failing, is to add a printf() (or breakpoint) where glad returns 0 (just ctrl-f for return 0).
I'll try to reproduce this in the next few days and add a pre-processor flag that provides additional information why the loader is failing.
It looks like the error occurs in the function gladLoadGLUserPtr on the line glGetString(GL_VERSION) == NULL.
We tried get an error message by calling glGetError but this did not produce any results.
Doing cout << load("glGetString", userptr) << endl; returns 1.
This usually happens if there is no active/current context.
I'll have to look into that later.
But I'm creating a context and making it current https://gist.github.com/BlGene/b78e237efb65086de3ef9e8aafdbef02#file-egl_gl2-cpp-L156
Edit: I did a check and I'm not getting error messages during context creation or making it current.
Could there be a mismatch between libs: e.g. loading a nvidia EGL library and a mesa GL library?
Mh that actually makes sense that it doesn't work, glad uses a glx function to retrieve gl pointers and you're using egl not glx. Try passing eglGetProcAddress to gladLoadGL.
@Dav1dde: Looks like this solved it. Thanks!
My test file is located here in case you want to include it. (no build script) https://github.com/BlGene/glad/tree/glad2-egl-example
By the way, I'm still for adding the option to load X11 functions dynamically. It would only change ~50 lines of code, see glx_dyn.c in https://gist.github.com/BlGene/add866798e551424a75315099196b53d
I just saw you're still using version % 10 and version / 10, this does not work with the latest glad version anymore, you should use the macros GLAD_VERSION_MAJOR(version) and GLAD_VERSION_MINOR(version) instead.
I don't think I am going to dynamically load X11 functions, it's just something I don't wanna take care of (what if X11 is not available, what if the X11 so is named differentely on a platform etc.), I'll probably add a macro though which disables the usage of those 3 X11 functions (since they are just convenience) and you simply have to pass a valid screen and display instead of NULL.
@BlGene try compiling with -DGLAD_GLX_NO_X11, glad will not call X11 functions anymore, but you need to pass a valid display/screen to glad*LoadGLX.
Shouldn't this be in the "glad space 2" milestone not the "glad2" milestone?
Should I bother to call glXQueryExtension when using glad2 or is it unnecessary? I see that glXQueryVersion is used.
You don't have to, glad loads all extensions that were specified automatically. In order to check if an extension is supported you can use the global variable named after the extension and prefixed with GLAD_, e.g. to check if GLX_ARB_create_context_profile is supported:
If (GLAD_GLX_ARB_create_context_profile) {
// supported
}
I can't find any of those global variables you're talking about. Is this something I have to query using a function?
They do exist:
#define GLX_VERSION_1_0 1
GLAD_API_CALL int GLAD_GLX_VERSION_1_0;
#define GLX_VERSION_1_1 1
GLAD_API_CALL int GLAD_GLX_VERSION_1_1;
#define GLX_VERSION_1_2 1
GLAD_API_CALL int GLAD_GLX_VERSION_1_2;
#define GLX_VERSION_1_3 1
GLAD_API_CALL int GLAD_GLX_VERSION_1_3;
#define GLX_VERSION_1_4 1
GLAD_API_CALL int GLAD_GLX_VERSION_1_4;
#define GLX_3DFX_multisample 1
GLAD_API_CALL int GLAD_GLX_3DFX_multisample;
#define GLX_ARB_create_context_profile 1
GLAD_API_CALL int GLAD_GLX_ARB_create_context_profile;
I don't have anything past GLX_VERSION in my glx.h. I've added my glx.h file if you want proof.
You didn't add any extensions (from the header you attached):
/**
* <snip>
* Extensions: 0
*
* <snip>
*
* Commandline:
* --api='glx=1.4' --extensions='' c --loader --alias
*
* <snip>
*
*/
If you want support for an extension you have to add it, on the website you can just click the extensions - on commandline you have to add them to the extension argument.
What platforms does GLAD support? Does it support OpenGL ES 3.x
EDIT: Well, I see that it supports OpenGL ES 3.x but why is it listed as GLES 2. It is different enough to deserve a separate or clearer indication.
GLES 2 is the API as defined by Khronos, you are using the version 3.2 of this API.
GLES 1 is the 'old' API.
Khronos specifies the headers as <GLES3/gl32.h>. What confused me is the web service here: https://gen.glad.sh/ as all of the GL version are bunched together but the GLES are separated. I think it would be beneficial gles versions and platforms are mentioned in the documentation.
The sample doesn't have the cast but I can't compile without it: gladLoadGL((GLADloadfunc)SDL_GL_GetProcAddress);
Sorry for the confusion. I copied this line from my source. What I mean is: https://github.com/Dav1dde/glad/tree/glad2 Shouldn't that example contain the cast too for the sake of clarity:
int version = gladLoadGL(glfwGetProcAddress);
if (version == 0) {
printf("Failed to initialize OpenGL context\n");
return -1;
}
https://github.com/Dav1dde/glad/blob/glad2/example/c%2B%2B/hellowindow2.cpp
The cast here is not required because the types match, I actually prefer it without the cast (when possible), it makes sure you're not accidentally casting the wrong function and imo it looks a lot cleaner.
I agree but for tutorial's the cast needs to be documented as this will save some learner's headbanging.
I noticed that when using GLAD glXCreateContextAttribsARB hasn't been loaded (confirmed by GLAD_GLX_create_context and GLAD_GLX_create_context_profile being 0), but when I use the shared library version, the function is available and works fine in my project. Any ideas?
My opengl version using the old method for creating contexts is 4.5 (the highest my hardware allows). I did some googling and I found this link that has important info.
https://stackoverflow.com/a/12169748
I assume you've called gladLoadGLX, if so please paste the output of glxinfo somewhere (e.g. a gist).
I have called gladLoaderLoadGLX.
https://gist.github.com/surafel911/e592470618d5ffe565087d8bed21508f
@surafel911 fixed in https://github.com/Dav1dde/glad/commit/e5090adad5319b4ff130963c3c03be74de5a7cab - I broke the extension detection.
Thanks!
Will this patch be available in the extension loader or do I have to wait for the next release?
You can already re-generate from http://gen.glad.sh - For the glad2 branch I'll continuously update the web generator.
I got some compiler errors.
https://gist.github.com/surafel911/46a8add9d1e79e7dbde7a790a4953b21
What options did you use to generate (should be listed on top of the header file)? Or please upload a zip containing the C and header files.
Seems like you accidentally typed into the source file:
At least I cannot reproduce this with the options you used, also this is basically impossible to be generated by glad since all those variables are generated at the same place within one for loop.
Removing the marked line and the if at the beginning of the next makes the file compile.