I removed some of the JUCE_OPENGL3 checks recently, so perhaps that could be causing issues on some platforms which don’t support OpenGL 3 (although I did test on Linux with GL 2.1 recently and that seemed fine). I’m currently trying to find a way to force my Windows install to use an older version of OpenGL to test out this theory.
I’ve asked for some more OpenGL details from the user.
I haven’t been able to replicate this either, even with a fairly old EliteBook I’ve got.
I might have to add in a check like you linked to disable GL if the drivers don’t support it, that would be ok for new customers but it’s odd for people who it was working for if it just suddenly stops working with an update (and we don’t have any obvious rationale).
Unfortunately I’ve not had much success reproducing this. On a VirtualBox VM with no OpenGL support, the DemoRunner displays a black screen after enabling the OpenGL renderer both with JUCE 6.0.5 and with current develop. I couldn’t find a way to create an older OpenGL context in my VMWare Fusion VM, so I haven’t been able to test with an old GL context on Windows.
I’ve added a small change which should reinstate some behaviour which may have got broken during the function-loading update:
I’m not sure whether this is relevant to your user on the 965 chipset, as it seems like texture copying (and possibly other bits and pieces?) would be broken on a card which doesn’t support OpenGL 2, but thought I’d let you know just in case.
(removed commits) - need to better bisect this but I see changes of profiles on OpenGL_win32.h
On my machines I’ve noticed it’s now using a newer (latest OpenGL context).
Meaning any older glsl/opengl pre 3.x can easily fail resulting black screen.
@dave96 - In our case I’m now able to ‘reproduce’ the black screen on macOS by explicitly enforcing setOpenGLVersionRequired (juce::OpenGLContext::OpenGLVersion::openGL3_2). without this I get GLSL #110.
After this I get GLSL #150 and any removed pre-3 API breaks also on a mac.
Trying to figure out if there’s a way to enforce older opengl version on Windows.
It looks like context-creation changed a few times on Windows. For a while JUCE didn’t take the requested OpenGL version into account at all. Then, it was updated to allow creating a 3.3 core profile when openGL3_2 was requested. This was quickly adjusted to return a 3.2 core profile to match the behaviour on macOS. Shortly after that, it was updated again to return a 3.2 compatibility profile.
I’m not convinced that the latest change is correct. If we want to provide the same behaviour on macOS and Windows, then we should be creating a 3.2 core profile on Windows too. I’ll need to test a bit to find out if there are other workarounds for the issues that were mentioned in this thread: