[aldacron]

After looking at the bindings James Pelcis made available, I was heartened to see that he is loading OpenGL version higher than 1.1 through std.loader. I suddenly had new ideas on how to handle this in Derelict. But while I knew this works on Linux and Mac, I was always under the impression that it doesn't work on Windows. To be certain, I tested it out and learned that I was right. Attempting to dynamically load any of the 1.2+ functions will fail when using the normal GetProcAddress technique (as both std.loader and derelict.util.loader do internally).

The reason for this is that opengl32.dll only exposes OpenGL 1.0 and 1.1 functions. It has not been updated since it first started shipping with Windows 95 (well, it has been updated for Vista, and that version only supports verisons up to 1.4 as I recall). If you want to use any 1.2+ functions in Windows you must do so by loading them through the extension loading interface - the same way you load extensions. This means that a valid context must be created before they can be loaded. I assume that if you switch contexts, the previously loaded functions will be invalid (though I haven't yet tested that assumption). The problem this presents, and which is a problem with extensions as well, is that Derelict has no control over when or how the context is switched. The user could be using the Derelict wgl functions, or might be using wgl from another Win32 binding, or maybe using SDL or GLFW (from Derelict or otherwise). There is no way to automatically and reliably determine when a context change occurs (unless it can be done with some fancy jigerry pokety using Win32 API hooks or some such, but I don't want to go there).

Even on Linux and Mac there is no guarantee that the user will have up-to-date drivers. So even if we configured Derelict to automatically load 1.2+ on those platforms it will fail on systems where those functions are not available.

I have toyed with many ideas on how to solve this problem over the past couple of years. I have posted two or three of them here before. Now, I've got a new one Unfortunately, it requires that DerelictGL be implemented differently than other packages, but that is unavoidable.

The first step will require renaming the loader template instance in gl.d and making it private. Then a struct named DerelictGL will be declared with static methods which wrap the methods of the loader template. This will provide a seamless interface for users while still allowing one point of maintenance for loader issues (the template in loader.d).

In addition to the static wrapper methods, the DerelictGL object will have a few other static methods and some private static members. Here are the methods I envision:

loadVersion(minVersion) - load OpenGL functions 1.2+, up to minVersion
loadExtension(extName) - load a single extension
loadExtensions(extNames[]) - load multiple extensions, null for all
isVersionAvailable(version) - convenience function
isExtensionAvailable(extName) - convenience function
onContextChange() - should be called by user on after a context switch - this will reload all previously loaded extensions and versions

The two is* methods basically wrap the functionality of glGetString, but are nice conveniences to have. onContextChange is very important to anyone using multiple contexts in the same app (or process). It will also require a good bit of bookkeeping internally to automatically reload all previously loaded context-dependent functions. Arguably the method isn't even needed. The user could simply call the loadVersion/loadExt* functions again instead.

At any rate, the first three methods are mandatory. Of the remaining three, the two is* methods I see as highly useful. The last one is optional. If I do go this route, I don't think I'll implement it in the beginning. I'll wait and see. The problem is that it adds a a good amount of overhead, even for those who don't need multiple contexts. It will always be a fallback, though.

Comments before I get started on it?

[Crispy]

Looks fine from here. Not that I'm an expert with this stuff by any means.

[quartz]

First, great job with Derelict. I use it quite a bit.

It seems, at first, what you describe is vaguely familar to several design patterns involving a builder and factory.

I implemented something along thoses lines that involved java and having to deal with JOGL, LWJGL and software rendering. It seems you have a similar issue dealing with different loading approaches.

What I had done was create an interface that used a builder which in turn dealt with factories. The factories in turn dealt with the specifics.

I realize that virtual tables would be introduced but loading generally occurs only once.

...Just some thoughts.

-Will.

[JoeCoder]

You have my vote of approval.