Hi! I'm the Derelict guy :)

> 
> But it still uses function pointer for *everything*, right ?
> 
> i.e. not only the Extensions for 1.2 - 1.5, but also GL 1.1 ?
> 
> --anders

Conceptually, there's no difference between using function pointers and linking to the import library (in which case you are using function pointers that the OS loads for you). The overhead is the same. And you still call gl* functions as normal.

I started Derelict in lieu of the existing bindings, primarily for my own ends, because the other bindings all *require* that you link to the import libs. I rarely do this in my own projects. On Windows, one of the most cryptic error messages you can get is 'A required DLL, some.dll, is missing'. By loading manually, you are able to catch and handle the exceptional case of a missing or corrupt DLL and respond in an app-specific manner. Then the user is not left gaping at the screen wondering what is going on.

One of the things the Quake 2 engine did with explicit dll loading was to have a separate set of debug functions that could be switched to at runtime from a console command. Calling qglVertex3f, for example, would then log the call before calling the real glVertex3f function (of course, there were two sets of function pointers for that setup - the qgl* functions and the gl* functions). The Torque engine (Tribes/Tribes 2) uses this method to switch between opengl32.dll and a custom gl2d3d.dll at runtime for D3D rendering (a rather odd approach, but it works). Implicit linking would make both impossible to do.

I just find that this approach has more flexibility, and it means no extra work for the user (though it's a bear to code up in the first place). In C, I would normally put my OpenGL code in a DLL, link that implicitly with the opengl32 import lib, then load my DLL explicitly from the executable - then I wouldn't have to bother with all of the function pointers as the my DLL would fail to load if opengl were missing or corrupt. But with D I find this to be a bit awkward as the GC is statically linked to each executable/dll.

Anyway, regardless of whether official OpenGL/SDL/Python/whatever bindings crop up in Deimos or elsewhere, I intend to keep Derelict going as an alternative to implicit linkage for those who need it. That's wy it exists, that's why it uses function pointers, and I hope that clears up any confusion over it :)

Mike Parker wrote:

> Hi! I'm the Derelict guy :)

I'm a new guy, nice to meet you :-)

> Conceptually, there's no difference between using function pointers and linking to the import library (in which case you are using function pointers that the OS loads for you). The overhead is the same. And you still call gl* functions as normal.

Yes, that much is similar. One *could* do a function loading context
instead of stuffing them as globals, but that means gl.gl___ calls...

> Anyway, regardless of whether official OpenGL/SDL/Python/whatever bindings crop up in Deimos or elsewhere, I intend to keep Derelict going as an alternative to implicit linkage for those who need it. That's wy it exists, that's why it uses function pointers, and I hope that clears up any confusion over it :)

I have done a simple way to wrap all of gl/glu and glut .h headers,
both all the "extern" C functions but also an alias for each pointer.

This means that you can include this and simplify the other code,
since the function prototypes are all *optional* (versioned)... ?

As discussed, one version of making both versions the very same is
to use &function instead of getProc("function") ? Same pointer var:

version (DYNAMIC) { p = cast(PFFUNCTIONPROC) getProc("function"); }
version (STATIC) { p = &function; }

So there is no conflict, just have to port the loader.d code to darwin
to have it use CFBundleGetFunctionPointerForName to load the functions.

--anders

> As discussed, one version of making both versions the very same is
> to use &function instead of getProc("function") ? Same pointer var:
> 
> version (DYNAMIC) { p = cast(PFFUNCTIONPROC) getProc("function"); }
> version (STATIC) { p = &function; }

That works, but then 'p' becomes a package-specific function name (such as the qgl* functions in the Quake engines). Additionally, you still need to declare the library function prototypes in the static version, in which case assigning a pointer becomes redundant. What about something like this:

version (DYNAMIC) // or EXPLICIT
{
typedef void function() pfmyfunc;
pfmyfunc myfunc;
myfunc = cast(pfmyfunc) getProc("myfunc");
}

version (STATIC) // or IMPLICIT
{
extern(C) void myfunc();
}

Just eliminate the function pointer in the implicitly loaded version.

Mike Parker wrote:

>> As discussed, one version of making both versions the very same is
>> to use &function instead of getProc("function") ? Same pointer var:
>>
>> version (DYNAMIC) { p = cast(PFFUNCTIONPROC) getProc("function"); }
>> version (STATIC) { p = &function; }
> 
> That works, but then 'p' becomes a package-specific function name (such as the qgl* functions in the Quake engines).

Right, last time I used it was with a function pointer context class -
i.e. "context.p = &function;" (requires e.g. : "gl.glGetString" usage)

Besides the extra step to use it, this is nice because you can then
just load all the function pointers into a context hash at run-time...

Maybe it isn't such a hot idea ?


> Additionally, you still need to declare the library function
> prototypes in the static version, in which case assigning a pointer
> becomes redundant. What about something like this:
> 
> version (DYNAMIC) // or EXPLICIT
> {
> typedef void function() pfmyfunc;
> pfmyfunc myfunc;
> myfunc = cast(pfmyfunc) getProc("myfunc");
> }
> 
> version (STATIC) // or IMPLICIT
> {
> extern(C) void myfunc();
> }
> 
> Just eliminate the function pointer in the implicitly loaded version.

Yeah, but that makes for two public versions ?
(one use regular functions, one using globals)


Here is what I ended up with for "opengl/gl.d":

> version (GL_GL_NO_PROTOTYPES) {} else {
> version = GL_GL_PROTOTYPES;
> }

> version (GL_GL_PROTOTYPES) {
> void glAccum (GLenum op, GLfloat value);
> void glAlphaFunc (GLenum func, GLclampf ref);
> ...
> }

> alias void (*PFGLACCUMPROC) (GLenum op, GLfloat value);
> alias void (*PFGLALPHAFUNCPROC) (GLenum func, GLclampf ref);
> ...

Which should reduce the dynamic/explicit/weak version to:

>     version = GL_GL_NO_PROTOTYPES;
>     import opengl.gl;

public: (globals)
>     PFGLACCUMPROC glAccum;
>     PFGLALPHAFUNCPROC glAlphaFunc;
>     ...

private: (load function)
>     glAccum          = cast(PFGLACCUMPROC) getProc("glAccum");
>     glAlphaFunc      = cast(PFGLALPHAFUNCPROC) getProc("glAlphaFunc");
>     ...

Which is easy to generate, from a list of function names ?


Also ported loader.d (such horrible code!) to Darwin,
with the mach-o dynamic libraries and NSModule bundles...

So now one can do this:
> hgl = ExeModule_Load("/System/Library/Frameworks/OpenGL.framework/OpenGL");

BTW; What is the path on Linux ? Just "/usr/lib/libGL.so" ?
(hoping for a final fix to the version: "linux" vs "Linux")

--anders


PS. There were a "couple" of other GL functions too. :-)

Anders F Björklund wrote:
>
> 
> Maybe it isn't such a hot idea ?
> 

Actually, it's not a bad idea at all. But, I get the nagging feeling that it would be easier to leave things as two separate projects - one implicitly loaded and the other explicitly. I think implicit loading would be the normal desired behavior, and as such any 'official' opengl/sdl/whatever packages should be set up for that.

> 
> BTW; What is the path on Linux ? Just "/usr/lib/libGL.so" ?
> (hoping for a final fix to the version: "linux" vs "Linux")
> 

I have no clue, really. But I do believe it depends upon the distro.