I’ve recently started to port my plugin to MacOS. Everything renders fine, except any stuff drawn manually with OpenGL stays black. I haven’t been able to find a solution, so I decided to go back to the tutorial which spawned all my progress when I started:
And behold, it seems even the simple tutorial window will stay black.
I’ve also noticed that I absolutely need to additionally set
and adjust shaders to new openGL syntax in order not to get shader compile errors. (Btw. why does the
OpenGLVersion enum have only two entries?)
Does anybody have any idea what could be wrong here? I’d be happy to get some insights on how to debug the OpenGL stuff to begin with.
Edit: The OpenGL demos in the JUCE examples both seem to be working fine.
Edit2: Here’s some information about the build machine:
=== OpenGL/GPU Information ===
Vendor: Intel Inc.
Renderer: Intel(R) Iris(TM) Plus Graphics 640
OpenGL Version: 4.1 INTEL-12.10.30
OpenGL Major: 4
OpenGL Minor: 1
OpenGL Shading Language Version: 4.10
Debugging issues like the black screen you’re seeing is a lot easier if you enable the debug callback on the context. Take a look at the example at the bottom of this page: Debug Output - OpenGL Wiki
You can also stick a breakpoint inside the
MessageCallback to find out which calls are causing problems.
Thanks for your answer! I managed to get the debug callback working on Windows and Linux, but on Mac the function call to
glDebugMessageCallback( MessageCallback, 0 ); causes a
EXC_BAD_ACCESS (code=1, address=0x0)
It is my understanding that this happens when no context is currently active, which is weird, because I call it inside
However I noticed that even just enabling
glEnable( GL_DEBUG_OUTPUT ) without the Debug callback will enable the error handling via
JUCE_CHECK_OPENGL_ERROR. So I littered my entire code base with this debug macro, and it throws immediately on the first call. Even this code:
glEnable( GL_DEBUG_OUTPUT );
will trigger the debug macro with the message:
So a broken function call is already made before my code even starts?
I’m still at a complete loss as to what’s happening. Any help appreciated, thanks.
Did it produce any debug output on those platforms? If so, it’s worth working out exactly what’s broken on those platforms before moving on to macOS. Depending on the problem, there’s a reasonable chance that the same issue is affecting macOS builds too, but it sounds like it will be much easier to debug on Windows/Linux.
glDebugMessageCallback is only supported on OpenGL contexts version 4.3 and higher. According to this page a 4.3 context is also required in order for
glEnabled (GL_DEBUG_OUTPUT) to succeed. I think that the ‘invalid enum’ error is caused because the older context doesn’t understand the
Looking at your original post, I can see that your context is version 4.1, so it won’t have the new debugging feature. Sorry, that was bad advice!
If you remove the initial call to
glEnable (GL_DEBUG_OUTPUT) but keep all of the
JUCE_CHECK_OPENGL_ERROR calls, are any other errors produced?
Both Linux and Windows just spam buffer binds like this:
GL CALLBACK: type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 33 (bound to GL_ELEMENT_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
GL CALLBACK: type = 0x8251, severity = 0x826b, message = Buffer detailed info: Buffer object 34 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
Which I think is the desired result.
This is precisely what’s happening! I thought the
glEnable() call enabled the logging, when in reality it only triggered an error itself . Good thinking on your part.
As mentioned before, the OpenGL demos in the DemoRunner seem both to work fine on my Mac machine. Perhaps it is time to ditch the tutorial and look how things are done in the DemoRunner. Hopefully I can work towards a solution from that point. I spent half a year building on top of the tutorial, but I guess the lesson to be learned is to test on all platforms early.
Once again thanks for your answers, very much appreciated!
I managed to find a solution by recreating everything on top of the rotating teapot OpenGLDemo. I’ve taken the opportunity to do a major code cleanup. Therefore, I can’t really compare what the problem was in the first place, and why even the simple tutorial from the OP would not work. As far as I can tell, both are built on the same foundation.
If anyone finds themselves in the same situation (after following the tutorial) I would advise to use the JUCE demo as a basis.