On Thursday, 18 August 2016 at 03:54:24 UTC, WhatMeWorry wrote:
When I saw the .dll in OpenGL.dll, I immediately thought: just Windows. But does this hold true for the linux shared opengl libraries as well? Is this why DerelictGL3.reload() does not take a path argument. But then why doesDerelictGL3.load(lib)take an argument?
The load method is what actually loads the shared library. On Windows, that's OpenGL32.dll. All of the platform-specific library names are configured at the top of gl3.d [1]. In addition to loading the library, it also loads the functions up to OpenGL 1.1, but no higher. This is because the availability of other functions are dependent on the version of the active OpenGL context.
The reload method *does not* load the shared library, nor does it load the 1.1 functions. It loads the functions from OpenGL versions 1.2 and higher in addition to all available extensions (well, those for which support has been added to DerelictGL3). It's named reload because it should be called every time you switch contexts to make sure the functions are pointed in the right place. This is an artifact of the way OpenGL is handled on Windows. In practice, it's really only a problem there when switching between contexts that have different properties, but it simplifies the binding implementation and provides a uniform interface across platforms.
I'm current working on a new version of the library that will allow you to specify which OpenGL versions and extensions you want to load and will also let you wrap everything in a struct so that you can have one instance for each context, but the distinction between load and reload will still exist.
[1] https://github.com/DerelictOrg/DerelictGL3/blob/master/source/derelict/opengl3/gl3.d#L47
