How to use Glad2? (gladLoadGL completely missing)
Lunar2kPS opened this issue · comments
Context
Excuse my lack of formality.
I'm tired of being confused with OpenGL and just want to "get it" already.
It's mostly just confusing getting started with the correct Glad files or whatnot.
I'm a game developer.
I want to use C++ and make my own games, so I'm starting with OpenGL.
I used Unity for 8.5 years, and my strength is C#, but I honestly want more freedom to build my own stuff.
As for getting access to the OpenGL functions themselves,
I've heard the story about OpenGL 1997 yada yada, OpenGL being a specification, implemented by the drivers or something like that. In any case, we need a loader library (?) like Glad to load recent OpenGL functions, for example, to load those from OpenGL 4.6.
I've done OpenGL before, but I completely forgot about how to build the right glad files for my C++ project.
I'm used to Git submodule and CMake workflows, which are more flexible for my usage, but I didn't use the newer CMakeLists.txt from this Git repo because it requires Python to be installed (not inherently bad, I just have an already-complex project setup).
I assumed it'd be best to use the most recent version of Glad, which is Glad2 (v2.0.4 as of today).
But seeing from learnopengl.com, they say to use Glad1.
Why?
What's the difference?
Is there an update guide somewhere?
I found a tiny bit of information from master branch's README at the time of writing (commit b6f6ff2), but I'm still lost.
The Problem (or my Misunderstanding)
❗ My main issue is I can't seem to find this function gladLoadGL(...) anywhere, except in GLFW's dependency of Glad.. which is weird that GLFW has Glad, yet I also need to include the generated Glad files myself. Not sure if they overlap or not, or what's up with that.
From the Quick Start guide, this is the only line giving me trouble:
int version = gladLoadGL(glfwGetProcAddress);My generated Glad2 files (include/glad/gl.h and src/gl.c) don't have that function at all.
Because of that, I don't think it's a CMake problem.
I searched the generated Glad2 files and only really found gladLoadGLContext(GladGLContext *context, GLADloadfunc load) and gladLoadGLContextUserPtr(GladGLContext *context, GLADuserptrloadfunc load, void *userptr), but have no idea how to use that or maybe they're for something else.
I'm using GLFW v3.3.8 and Glad v2.0.4 using the generator with the following settings:
- https://gen.glad.sh/ (Glad2):
- Generator: C/C++
- APIs:
- gl, version 4.6
- ❓ Do I need anything else here?
- Other settings (? 🤨)
- Core or Compatibility? Core
- Common.. (no other choice?)
- Extensions:
- Everything ("ADD ALL")
- Options:
- loader (Include internal loaders for APIs)
- mx (Enables support for multiple GL contexts)
My includes should be good,
#include "glad/gl.h"
#include "GLFW/glfw3.h"Am I missing something basic?
Once I'm done, I want to write a guide on all of this stuff, cause I find it a huge barrier to entry for OpenGL. Not your fault -- Glad makes this stuff easier and easier cross-platform, but sometimes C++ is just so gnarly. Coming from C#, it's.. a lot.
I assumed it'd be best to use the most recent version of Glad, which is Glad2 (v2.0.4 as of today).
But seeing from learnopengl.com, they say to use Glad1.Why?
What's the difference?
The API is different and the features are different (the biggest glad 2 feature is probably the header only option), glad 2 also has better support for non-GL APIs (EGL, WGL, GLX) and supports Vulkan. For OpenGL the API is in both versions just a function call (slightly different name).
But essentially you can just follow your guide and not really worry about glad, it just generates a bunch of code, you call it at the right time and forget about it.
I searched the generated Glad2 files and only really found gladLoadGLContext(GladGLContext *context, GLADloadfunc load) and gladLoadGLContextUserPtr(GladGLContext *context, GLADuserptrloadfunc load, void *userptr), but have no idea how to use that or maybe they're for something else.
That's because you enabled the MX option (multiple contexts). It modifies glad in a way to support multiple, different OpenGL contexts at the same time. Don't enable it and you get gladLoadGL.
What to choose ...
Choose what you target: OpenGL + Version, most likely the core profile (gets rid of all the deprecated old APIs). (The common you see is for gles1)
All extensions is fine for development, but you could also just start with 0 and re-generate whenever you realize you need an OpenGL extension. Usually you would start with a minimal set and add extensions as you go.
Options: you don't need any. You don't need a loader, because you're using GLFW (which brings glfwGetProcAddress). MX is the issue you had before, I don't think you want to have multiple windows running with potentially different GL versions.
What you can think about, if you're using glad 2, is to enable to header only option, makes compilation and project setup a bit easier. Don't forget to set GLAD_GL_IMPLEMENTATION in one file if you do.
PS: Please don't use CMake for glad, just include the generated files in your project. Less dependencies, less gray hair and nice git diffs when you update glad.
Thanks so much for your help, and sorry for my frustration.
Gotcha, I definitely gotta read more into OpenGL contexts then -- I don't wanna make you do my research for me 😅
I will want to support multiple windows running, but they don't need to be different GL versions.
I'll look more into doing that later though.
Choose what you target: OpenGL + Version, most likely the core profile (gets rid of all the deprecated old APIs). (The common you see is for gles1)
Ahh that's good then! Might as well start out using OpenGL Core/more up-to-date functions then.
All extensions is fine for development, but you could also just start with 0 and re-generate whenever you realize you need an OpenGL extension. Usually you would start with a minimal set and add extensions as you go.
Makes sense.. I was trying to do too much, just starting out.
You don't need a loader, because you're using GLFW (which brings glfwGetProcAddress)
Ahh gotcha, my brain was like "Oh I need a loader!" but glfwGetProcAddress is the loader I need, did I say that right?
It loads functions or something.. I suppose I'm still getting used to why, but I do hear about this all the time when learning about OpenGL. I'll read more into this and probably do some testing.. I'm pretty sure it's very basic, just loading function pointers so I can call the OpenGL API, but I feel like it just hasn't clicked yet.
PS: Please don't use CMake for glad, just include the generated files in your project. Less dependencies, less gray hair and nice git diffs when you update glad.
Hahah you're probably right.
I just want my CMake final executable to have clear dependencies, even if I just copy-paste the files under my "/libraries/glad" folder and make CMake add_library(glad, libraries/glad/src/*.c) and then link my executable to that library using target_link_libraries("${PROJECT_NAME} glad) or whatnot.
But if I have trouble with that, I'll take your advice 😆
Thanks again for the detailed help! 🙏🏼
Ahh gotcha, my brain was like "Oh I need a loader!" but glfwGetProcAddress is the loader I need, did I say that right?
Yes, glad and glfwGetProcAddress together load the OpenGL functions for you
It loads functions or something.. I suppose I'm still getting used to why, but I do hear about this all the time when learning about OpenGL. I'll read more into this and probably do some testing.. I'm pretty sure it's very basic, just loading function pointers so I can call the OpenGL API, but I feel like it just hasn't clicked yet.
A bit simplified:
Think about it this way, there are millions of different devices out there with lots of different configurations of hardware (Nvidia, AMD, Intel, ...) with lots of different drivers (mesa, noveau, nvidia, ...) on different operating systems (Windows, OSX, Linux, ...) with different contexts and all of these in different ages and versions. Some features are implemented in hardware, others emulated or mapped by the driver. This is an incredible amount of variance.
And every unique environment has access to different OpenGL features (versions, profiles and extensions). This is why you can't link against OpenGL like you can link with other libraries. It simply wouldnt work on machines other than yours. Hence why all this is determined at runtime. This also makes it possible for the (game-)developer to enable or disable certain features at runtime based on presence of GL extension or even GL version.
OpenGL is quite big, so loading all functions by hand is possible but also a lot of work, that's where glad comes in, it generates that boiler plate. Now you still have to acquire the function from the driver, that's what glfwGetProcAddress does or if you enable the loader function, glad adds a loader which mostly does the right thing.
I just want my CMake final executable to have clear dependencies, even if I just copy-paste the files under my "/libraries/glad" folder and make CMake add_library(glad, libraries/glad/src/*.c) and then link my executable to that library using target_link_libraries("${PROJECT_NAME} glad) or whatnot.
That's fine, I was more talking about letting cmake call glad at build time (what the in the repo included CMake files do).
Ahhh.... wow that makes sense!
I'm definitely gonna save this explanation, that's the best I've ever heard it. Thanks again!
Re:CMake, ahh gotcha! 👍🏼 True, I tried it briefly and thought I was doing a bit overkill ;) But as long as I document how/what I generated with the web service, I should be good for future changes to it!
But as long as I document how/what I generated with the web service, I should be good for future changes to it!
The generated header file contains all options you had selected, it also directly links to the website with all the options ticked ;)
Wowww I'm so behind 🤣 NICE!!
