GLAD is just an extension loading library. While I haven’t personally used it, I see no reason why it can’t be swapped out with your own preferred extension loading library without being too intrusive to the tutorials.
I’d prefer to use such a library than to roll my own though. I’ve better things to be doing with my time - like writing actual code that does actual work - than spending it loading GL entrypoints by hand.
I guess I haven’t needed any extensions yet, or is this an alternative to GLEW than I’m using now?
How are you managing them?
I have some questions about setting GLAD up.
I’m thinking I’ll want two sets of GLAD, in separate folders. One for the GLFW samples in the tutorial, and another for my WGL code.
Do you have a setup for multiple applications, and refer to those headers and source files, or set it up for each application?
If you set GLAD up for multiple applications, do you set it up to include all of the over 500 extensions, to cover all of the bases? Do you specify OpenGL 3.3, or will specifying 4.5 give you more flexibility?
Probably more questions are coming, but these are on my mind right now.
Typically, you will target an OpenGL version, depending on your targeted platform/your own platform capabilities.
For example, if your hardware only supports GL 2.0, then your hardware can support shaders. You’ll then use glad/glew to retrieve the function pointers that allow to create/manage shaders. Glad and glew also define all the OpenGL values needed to talk with each (all GL_ constants).
You can also use glad/glew to query if a specific functionality is available. For example to check if the current running hardware/driver supports ARB_compute_shader. If your program requires compute shader but is not available on a machine, you’ll typically return an error at the very beginning of the program, telling the user that he needs to update his hardware/drivers or a specific OpenGL capable hardware (here OpenGL 4.2 for example).
Other extensions might be just a bonus. Typically all hardware dependent extensions (GL_NV, GL_ATI…) should not block a program execution. But they could help to perform some operation more easily and/or quickly. I would suggest to stay away from them for now.
All the extensions are listed and depicted in detail here.
I don’t think I’ve used any extensions yet, so I can’t compare the GLEW and GLAD extension experience.
If GLAD is wonderful, and the wave of the future, I have little code using GLEW so now is probably a good time to change.
If not, I might stay with GLEW for my WGL code, and build sample GLFW code from the tutorial with GLAD. I’ll make a decision when I start dealing with extensions.
Googling “GLAD Forum” returns an avalanche of useless responses, and “GLEW vs GLAD” returned one passionate but not particularly enlightening thread from Reddit.
If I could find a GLAD forum I could post the questions from my previous post questions there.
Extension loading is just extension loading. I personally use GLEW but there’s no specific reason for that other than it’s what I’ve always used. If GLAD does the job and if you like the way it works then by all means use GLAD instead. Which extension loader you pick isn’t really what’s important; what’s important is that you get them loaded so that you can start writing actual code.
I don’t use glad since I did not knew it until your post. It seems it can have good things: it has pre and post callbacks which can be very helpful for debugging. For example glGetError could be called automatically after each GL call.
glew does not seem to provide such kind of functionality. However glew is more old and more widely used, so we can suppose it has more stability, and might also have less bugs. glew looks also more easy since you don’t have to generate the sources code from a script generator call. Your program then does not need to embed the sources internally but will have to rely on an external dependency which might become troublesome if the final user does not have the exact same version than you.