Comments (6)
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.
from glad.
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).
from glad.
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!
from 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! 🙏🏼
from glad.
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 ;)
from glad.
from glad.
Related Issues (20)
- Is there an API to download platform specific headers and sources? HOT 2
- glad/egl.h is not generated
- GLX_*_ARB was not declared in scope HOT 2
- Glad.h missing HOT 1
- RFE: please start making github releases HOT 3
- GL_MAX_TEXTURE_COORDS missing HOT 2
- CMake glad_add_library(): REPRODUCIBLE keyword HOT 2
- Parsing extensions fails with Mesa and GLES2
- glad2 debug build recompiles every launch
- Surface related vk calls fail with an SDL-created Vulkan Surface (Vulkan 1.3)
- Provide cmake-package HOT 8
- [question] What heppened with the CMakeLists.txt file in the repository root? HOT 3
- glad_egl_find_core querying EGL_VERSION ahead of eglInitialize HOT 2
- <KHR/khrplatform.h> not found on OpenBSD, alpinelinux and others? HOT 14
- warning: 'GLAD_GLES2_USE_SYSTEM_EGL' is not defined, evaluates to 0 [-Wundef]
- Fail to use GL_NV_geometry_shader_passthrough bug. HOT 4
- GL/GLFW Example Displays GLAD Version "0.1" HOT 6
- Vulkan tests fail on 32bit x86 systems HOT 3
- GCC -fanalyzer report error when compiling glad
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from glad.