<p>It sounds like your version of the <code>opengl.h</code> header is too old, and doesn't include the declarations for functions and constants from newer versions. Despite that the OpenGL implementation in the driver is 4.6, you won't be able to access the newer functionality without the appropriate declarations. You'll also need code to load the function addresses from the driver for newer functions (this is called a &quot;loader&quot;).</p>
<p>There are a few different libraries/tools out there for this, but one I like is <a href="https://glad.dav1d.de/" rel="nofollow noreferrer">Glad</a>, which is an online loader generator. It will generate a header and source file that you can download and add directly to your project in place of the usual <code>opengl.h</code>.</p>
<p>You can put in the version of OpenGL you want - probably 4.6 with &quot;Compatibility&quot; profile - that will include the &quot;old-fashioned&quot; stuff like immediate mode, which I think you said you were using. (You could use &quot;Core&quot; profile if you want to get rid of all deprecated stuff and only use modern OpenGL, but that may be a steeper learning curve.) You can also put in any extensions you want to use, and it will include their associated functions and constants in the generated loader.</p>

CC BY-SA 4.0
2021-12-27T15:29:21.173Z
Thank you very much for your help again ! I managed to do that, after a while spent not realising I *do* have the admin privileges to copy and paste the glad and KHR folders alongside the GL folder somewhere in the MinGW directory. Eventually everything compiled ok, but on running, my program crashed immediately, with an access violation message...
Simon
CC BY-SA 4.0
2021-12-27T15:29:32.197Z
...By putting in printf statements, I was able to determine that the "CreateWindowEx" call to Windows seemed to have worked ok, as did the "EnableOpenGL" routine. The error was seemingly generated by what looks like the first call to OpenGL, namely the line "const GLubyte* VENDORSTRING = glGetString(GL_VENDOR);". Any ideas you might have would be very kindly received !
Simon
CC BY-SA 4.0
2021-12-27T15:48:49.853Z
You might need to do some initialization call for Glad to run the loader and populate the function pointers. You can look at glad.h and see if you can find it (or maybe the Glad website has docs), or I can look at it a little while later. BTW, putting those files into the mingw directory is not really recommended :) You can just keep them in your project's source directory and include from there.
Nathan Reed
CC BY-SA 4.0
2021-12-27T15:51:25.703Z
BTW, do you know how to use the debugger in your IDE? If not, might be a good time to learn - it would have saved you the trouble of doing printfs and taken you directly to where it was crashing.
Nathan Reed
CC BY-SA 4.0
2021-12-27T16:14:28.897Z
OMG thanks so much ! I added
if (!gladLoadGL())
    {
        printf("Failed to initialize OpenGL context");
        return -1;
    }
after the line "EnableOpenGL(hwnd, &hDC, &hRC);" that came with the OpenGL template in Codeblocks, and things *seem* to work !
The line "const GLubyte* SHADINGLANGUAGESTRING = glGetString(GL_SHADING_LANGUAGE_VERSION);" now works, which is a good omen. I don't know whether I put "gladLoadGL()" in the right place, but I'm not one to look a gift horse in the mouth !! XD
Simon
CC BY-SA 4.0
2021-12-27T16:21:46.863Z
Thank you also for the advice about not putting those files in the mingw directory - I'll put them back in my own little folder. Although I seemed to have managed to make that work earlier, yet I found I needed to use the whole directory path all the way from "C:", in the #include statement, and I needed to edit this in my own code, and also in glad.h and in glad.c, and similarly in glad.h for the KHR folder. Even though I added the filepaths to the search directories for the compiler and the linker, in CodeBlocks !
Simon
CC BY-SA 4.0
2021-12-27T16:23:26.167Z
One thing that particularly spooked me about seeming to have to put those long directory paths in those #include statements, was that Windows seems to use "\" while the code seems to use "/", so I changed them all to "/"...
Simon
CC BY-SA 4.0
2021-12-27T16:24:17.147Z
If you're using brackets on your include, like `#include <glad.h>`, you might need to switch to quotes, like `#include "glad.h"`. The former is used for system headers, and the latter for ones local to your own project.
Nathan Reed
CC BY-SA 4.0
2021-12-27T20:34:43.130Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/132649/discussion-between-simon-and-nathan-reed).
Simon
CC BY-SA 4.0
2021-12-26T18:43:06.310Z
2021-12-26T18:43:06.310Z
Nathan Reed
<p>I am writing basic code to; draw triangles, lines etc; to translate and orient them, and to project them in perspective, solving the occlusion problem using the depth buffer.</p>
<p>Having had success with a hand-made projection matrix emulating what <code>glFrustum</code> used to do before it was deprecated, I upgraded to a hand-made infinite projection matrix having no far clipping plane, based on what I've read in books. This mapped <span class="math-container">$z = -\infty$</span> in camera space to <span class="math-container">$z = 1$</span> in normalised device coordinates. This all worked, and allowed me for the first time, to use infinitely distant objects, i.e. objects having <span class="math-container">$w = 0$</span>. These render correctly behind everything else, and exhibit no parallax, and no change in size. They move only when the camera <em>orientation</em> changes, as desired.</p>
<p>I was able to induce <span class="math-container">$z$</span>-fighting by having the ratio of the distances of the far and near clipping planes nice and large, and making two very large distant triangles, one parallel to and not far behind the other. I did this in order to justify upgrading my projection matrix again, this time to a reversed-<span class="math-container">$z$</span> style, again based on what I've read in books. Having done so, I changed <code>glDepthFunc(GL_LEQUAL)</code> to <code>glDepthFunc(GL_GEQUAL)</code> and set <code>glClearDepth(0.0f)</code>. The last step remaining seemed to be to  set <code>glClipControl(GL_LOWER_LEFT, GL_ZERO_TO_ONE)</code>. However, the IDE did not recognise the definitions of the two constant parameters. The specific errors from the IDE are &quot;GL_LOWER_LEFT undeclared (first use in this function). Did you mean...&quot; followed by a suggestion of something else with a similar spelling, and a similar error, for the other constant. I don't know if the problem is with the function itself - the IDE seemed not to object to it, in any case. I know that this function became available only in OpenGL version 4, however, my code reports, via <code>const GLubyte* VERSIONSTRING = glGetString(GL_VERSION)</code>, that it is using version 4.6.0.</p>
<p>The only other time I've encountered a problem like this so far, was with <code>const GLubyte* SHADINGLANGUAGESTRING = glGetString(GL_SHADING_LANGUAGE_VERSION)</code>. Here too, the constant parameter was not recognised.</p>
<p>There are more details here: <a href="https://computergraphics.stackexchange.com/q/12396/11224">How to use maximum resolution (pixel density) with OpenGL in MS Windows</a> about the template that I have borrowed and modified, in case that helps diagnose the problem.</p>
<p><strong>EDIT:</strong></p>
<p>In case it is relevant, CodeBlocks' autocomplete did <em>not</em> recognise the command <code>glClipControl</code>, whereas it did recognise the <code>glGetString</code>, in spite of it not knowing the constant GL_SHADING_LANGUAGE_VERSION that I passed to <code>glGetString</code>.</p>

<opengl><z-buffer>
OpenGL in CodeBlocks with GNU GCC compiler not recognising some constants
Simon
# OpenGL in CodeBlocks with GNU GCC compiler not recognising some constants

(Asked by: username_0 on 2021-12-24)

I am writing basic code to; draw triangles, lines etc; to translate and orient them, and to project them in perspective, solving the occlusion problem using the depth buffer.

Having had success with a hand-made projection matrix emulating what `glFrustum` used to do before it was deprecated, I upgraded to a hand-made infinite projection matrix having no far clipping plane, based on what I've read in books. This mapped $z = -\infty$ in camera space to $z = 1$ in normalised device coordinates. This all worked, and allowed me for the first time, to use infinitely distant objects, i.e. objects having $w = 0$. These render correctly behind everything else, and exhibit no parallax, and no change in size. They move only when the camera *orientation* changes, as desired.

I was able to induce $z$-fighting by having the ratio of the distances of the far and near clipping planes nice and large, and making two very large distant triangles, one parallel to and not far behind the other. I did this in order to justify upgrading my projection matrix again, this time to a reversed-$z$ style, again based on what I've read in books. Having done so, I changed `glDepthFunc(GL_LEQUAL)` to `glDepthFunc(GL_GEQUAL)` and set `glClearDepth(0.0f)`. The last step remaining seemed to be to set `glClipControl(GL_LOWER_LEFT, GL_ZERO_TO_ONE)`. However, the IDE did not recognise the definitions of the two constant parameters. The specific errors from the IDE are "GL\_LOWER\_LEFT undeclared (first use in this function). Did you mean..." followed by a suggestion of something else with a similar spelling, and a similar error, for the other constant. I don't know if the problem is with the function itself - the IDE seemed not to object to it, in any case. I know that this function became available only in OpenGL version 4, however, my code reports, via `const GLubyte* VERSIONSTRING = glGetString(GL_VERSION)`, that it is using version 4.6.0.

The only other time I've encountered a problem like this so far, was with `const GLubyte* SHADINGLANGUAGESTRING = glGetString(GL_SHADING_LANGUAGE_VERSION)`. Here too, the constant parameter was not recognised.

There are more details here: [How to use maximum resolution (pixel density) with OpenGL in MS Windows](https://computergraphics.stackexchange.com/q/12396/11224) about the template that I have borrowed and modified, in case that helps diagnose the problem.

**EDIT:**

In case it is relevant, CodeBlocks' autocomplete did *not* recognise the command `glClipControl`, whereas it did recognise the `glGetString`, in spite of it not knowing the constant GL\_SHADING\_LANGUAGE\_VERSION that I passed to `glGetString`.

**Tags:** opengl, z-buffer


---

## 1 answers

### Answer by username_1 on 2021-12-26. Score: 2 | Accepted answer

It sounds like your version of the `opengl.h` header is too old, and doesn't include the declarations for functions and constants from newer versions. Despite that the OpenGL implementation in the driver is 4.6, you won't be able to access the newer functionality without the appropriate declarations. You'll also need code to load the function addresses from the driver for newer functions (this is called a "loader").

There are a few different libraries/tools out there for this, but one I like is [Glad](https://glad.dav1d.de/), which is an online loader generator. It will generate a header and source file that you can download and add directly to your project in place of the usual `opengl.h`.

You can put in the version of OpenGL you want - probably 4.6 with "Compatibility" profile - that will include the "old-fashioned" stuff like immediate mode, which I think you said you were using. (You could use "Core" profile if you want to get rid of all deprecated stuff and only use modern OpenGL, but that may be a steeper learning curve.) You can also put in any extensions you want to use, and it will include their associated functions and constants in the generated loader.

> **Comments:**
> **username_0**: Thank you very much for your help again ! I managed to do that, after a while spent not realising I *do* have the admin privileges to copy and paste the glad and KHR folders alongside the GL folder somewhere in the MinGW directory. Eventually everything compiled ok, but on running, my program crashed immediately, with an access violation message...  
> **username_0**: ...By putting in printf statements, I was able to determine that the "CreateWindowEx" call to Windows seemed to have worked ok, as did the "EnableOpenGL" routine. The error was seemingly generated by what looks like the first call to OpenGL, namely the line "const GLubyte* VENDORSTRING = glGetString(GL_VENDOR);". Any ideas you might have would be very kindly received !  
> **username_1**: You might need to do some initialization call for Glad to run the loader and populate the function pointers. You can look at glad.h and see if you can find it (or maybe the Glad website has docs), or I can look at it a little while later. BTW, putting those files into the mingw directory is not really recommended :) You can just keep them in your project's source directory and include from there.  
> **username_1**: BTW, do you know how to use the debugger in your IDE? If not, might be a good time to learn - it would have saved you the trouble of doing printfs and taken you directly to where it was crashing.  
> **username_0**: OMG thanks so much ! I added if (!gladLoadGL())     {         printf("Failed to initialize OpenGL context");         return -1;     } after the line "EnableOpenGL(hwnd, &hDC, &hRC);" that came with the OpenGL template in Codeblocks, and things *seem* to work ! The line "const GLubyte* SHADINGLANGUAGESTRING = glGetString(GL_SHADING_LANGUAGE_VERSION);" now works, which is a good omen. I don't know whether I put "gladLoadGL()" in the right place, but I'm not one to look a gift horse in the mouth !! XD  
> **username_0**: Thank you also for the advice about not putting those files in the mingw directory - I'll put them back in my own little folder. Although I seemed to have managed to make that work earlier, yet I found I needed to use the whole directory path all the way from "C:", in the #include statement, and I needed to edit this in my own code, and also in glad.h and in glad.c, and similarly in glad.h for the KHR folder. Even though I added the filepaths to the search directories for the compiler and the linker, in CodeBlocks !  
> **username_0**: One thing that particularly spooked me about seeming to have to put those long directory paths in those #include statements, was that Windows seems to use "\" while the code seems to use "/", so I changed them all to "/"...  
> **username_1**: If you're using brackets on your include, like `#include <glad.h>`, you might need to switch to quotes, like `#include "glad.h"`. The former is used for system headers, and the latter for ones local to your own project.  
> **username_0**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/132649/discussion-between-username_0-and-username_1-username_1).  

---

