OpenGL errors on Windows

Windows
1

I’m compiling an OpenGL app on Windows 10 with VS2019.

I am getting a load of errors e.g.

identifier "GLsizeiptr" is undefined
identifier "GL_STREAM_DRAW" is undefined
identifier "GL_STATIC_DRAW" is undefined
identifier "GL_ARRAY_BUFFER" is undefined

I’ve set OPENGL3=1 in Projucer Preprocessor Definitions.

Anything else I might have missed?

2

I don’t see any other configuration needed in my projects to make that work. Also, JUCE_OPENGL3=1 is the macro.

You sure this line is active in juce_MissingGLDefinitions.h ?

#if JUCE_WINDOWS && ! defined (GL_TEXTURE0)
3

Yes I am using JUCE_OPENGL3=1, that was a typo.

It also looks like those definitions are set:

59

4

The strange thing is that I can inspect the missing values:

48
Screenshot 2019-09-23 at 14.28.48.png1764×292 22.6 KB

5

Looks like adding the juce namespace to all the GL definitions is the solution. This code resides in a module, if that makes a difference…

6

My guess is that you don’t have DONT_SET_USING_JUCE_NAMESPACE=1 defined or you have it disabled?

Regardless, the reason this is an issue is that it’s entirely a non-standard way of going about. Everything that is a macro should remain that way, because OpenGL is fundamentally standardised as a C API.

1 Like
7

No, can’t see DONT_SET_USING_JUCE_NAMESPACE set anywhere…

However to get it working on both platforms I had to add using namespace juce to the top of the .cpp file containing the OpenGL calls. While adding juce:: to the beginning of the OpenGL definitions worked on Windows it failed on macOS.

8

Looking at the code, I see that it is a problem coming from my realtime visualization module :wink:

I tested all my code on Mac OS and iOS only so far and I do all my projects with DONT_SET_USING_JUCE_NAMESPACE turned on as I avoid using namespace at all costs – mainly because I know that people round here will read the code that might not be familiar with JUCE, so they will see immediately that I used a class from this framework. This means if I use any JUCE class or function in my code, I always prepend the juce:: namespace, as I do with all other namespaces that might occur in my project.

Now for reasons I don’t know, it seems like there was the need to define some of the Open GL macros for Windows that are missing on that platform (why??). So there is a header called juce_MissingGLDefinitions.h which contains

namespace juce
{
/** These are important openGL values that aren't defined by default
    by the GL headers on various platforms.
*/
enum MissingOpenGLDefinitions
{
   //...

   #if JUCE_WINDOWS && ! defined (GL_TEXTURE0)
    GL_OPERAND0_RGB                 = 0x8590,
    GL_OPERAND1_RGB                 = 0x8591,
    GL_OPERAND0_ALPHA               = 0x8598,
    GL_OPERAND1_ALPHA               = 0x8599,
    GL_SRC0_RGB                     = 0x8580,
    GL_SRC1_RGB                     = 0x8581,
    GL_SRC0_ALPHA                   = 0x8588,
    GL_SRC1_ALPHA                   = 0x8589,
    GL_TEXTURE0                     = 0x84C0,
    GL_TEXTURE1                     = 0x84C1,
    GL_TEXTURE2                     = 0x84C2,
    GL_COMBINE                      = 0x8570,
    GL_COMBINE_RGB                  = 0x8571,
    GL_COMBINE_ALPHA                = 0x8572,
    GL_PREVIOUS                     = 0x8578,
    GL_COMPILE_STATUS               = 0x8B81,
    GL_LINK_STATUS                  = 0x8B82,
    GL_SHADING_LANGUAGE_VERSION     = 0x8B8C,
    GL_FRAGMENT_SHADER              = 0x8B30,
    GL_VERTEX_SHADER                = 0x8B31,
    GL_ARRAY_BUFFER                 = 0x8892,
    GL_ELEMENT_ARRAY_BUFFER         = 0x8893,
    GL_STATIC_DRAW                  = 0x88E4,
    GL_DYNAMIC_DRAW                 = 0x88E8,
    GL_STREAM_DRAW                  = 0x88E0,

    //...
   #endif
}
} // namespace juce

Now if we take e.g. GL_STREAM_DRAW and look where it is defined on Mac OS, we’ll find #define GL_STREAM_DRAW 0x88E0 defined in the system header gl3.h. However on Windows there is the enum value juce::MissingOpenGLDefinitions::GL_STREAM_DRAW that holds this value, which can also be called by juce::GL_STREAM_DRAW and if you have set using namespace juce it just gets GL_STREAM_DRAW and therefore suddenly becomes silently exchangeable with the macro on the other platforms. This explains why adding that directive to the .cpp file solved the problem for you @adamski.

I personally think, declaring a missing macro as an enum inside a namespace with the assumtion that all users will have using namespace juce enabled globally is no good idea and a serious design flaw when the goal is to provide a framework that aims at writing portable code. Would love to hear from the JUCE team what they think about it and why they didn’t chose to declare the missing macros as macros? @ed95 @jules

9

I came to the same conclusion as you. It seems like a strange design decision to treat platforms differently, which can lead to anomalies as I have found.

And yes it is coming from your OpenGL module :slight_smile: Thanks for confirming re: DONT_SET_USING_JUCE_NAMESPACE I could not find a reference to it in my project (which includes your module)

10

I also found an extra GL definition missing on Windows:

#define GL_ALIASED_LINE_WIDTH_RANGE       0x846E
11

I’ve made some changes to the way that we load OpenGL symbols which should solve some of the issues raised in this thread.

Given that the change is quite large, it’s currently on a feature branch: generated-opengl-headers. I’d really appreciate any feedback on this potential change, before we merge it to develop. As always, I’m happy to answer any questions you may have about this change.

Some more details can be found in this post: FR: Wrangle a comprehensive set of OpenGL functions & macros - #5 by reuk