[aldacron]

Thanks to John Reimer (JJR), DerelictGLFW has now been committed to the trunk. It's an incomplete package for the moment (no README, and the linux verison isn't done yet), but it's working on Windows for anyone who wants to try it.

[JJR]

I started working on getting the linux version working. First thing I did was build the Linux GLFW package. It was at this point that I realized the makefile only builds static libraries on linux. Hmmm... that would make the derelict dynamic loader useless for linux GLFW. (win32 is the only platform for which GLFW builds a static /and/ a dynamic library).

So what to do? I decided to modify the Makefile to make a shared GLFW library. There were a couple hiccups, one of which required a minor source level change in GLFW. Otherwise, I succeeded in creating libglfw.2.4.2.so. The problem here is that I don't know if such a library was ever intended on linux, or if it even works. So I'm going to test it out and see if I can

1) Get the DerelictGLFW loader to load the library
2) See if all the procedures get assigned
3) See if one of the example programs (converted to D) can run

I'll post here when I get my results. If this doesn't work, it may very well be that GLFW is useless as part of Derelict until the GLFW author adds proper shared library support (granted GLFW is so tiny, I can undestand why that wasn't a priority). This just means that you would have to link statically to glfw. You can still import Derelict GL into your statically linked glfw project. It just means one more step. Hopefully, though, this won't be necessary.

- John R.

[JJR]

It appears that the shared library works fine on Linux (C examples link and run great). So now all I have to do is make up the D examples and see how Derelict handles loading the library and functions.

Since I had to change the default GLFW to get this to work, I'm not sure what the correct process is to make these updates available to others. Perhaps I should also include the updated GLFW makefiles with the package. Rebuilding GLFW will be necessary for linux users. I should probably provide a readme with this package also.

- John R.

[JJR]

Should GLFW automatically import derelict.opengl.gl and derelict derelict.opengl.glu?

The GLFW documentation specifies that you don't need to (and shouldn't) "include" gl.h and glu.h. glfw.h is the only file you need to include for your program in order to do opengl programming on your platform.

Should derelict.glfw do the same for D? Doing this would also mean that the glfw module would be responsible for calling DerelictGL_Load() and DerelictGLU_Load() from within DerelictGLFW_Load().

What do you think? It would make programming GLFW with D consistant with the C implementation.

- John R.

[aldacron]

My first reaction was no, but after thinking about it some there is no reason to use GLFW except in conjunction with OpenGL, and the consistency with the C version is certainly desirable. So publicly importing the gl and glu modules is perfectly acceptable. Automatically loading the libraries is another matter.

I, for one, only use glu if I need to knock something up quickly. In production code I would never use it because it is one extra dependency that I really don't need. The only glu functions I usually have need of are gluPerspective and gluLookat, and those are easily replaced with custom versions. I've found that, at least in game development, this is not an uncommon practice. So automatically loading glu would be a no go, I think.

Then the question remains, should we automatically load GL? Again, my first thought is no, if only for consistency (if you have to manually load GLU, might as well load GL). Letting the client decide when to load a particular library is the main idea behind Derelict, and doing it automatically sort of defeats that I think,

[JJR]

[JJR]

Today, I worked on the getting glfw to work on Linux. Unfortunately, there are a few snags that prevent me from getting further.

The good news:

In the process of trying to get Derelict.glfw to work on linux, I found and fixed several bugs in the linux implementation of derelict.opengl.gl, derelict.opengl.glu, and derelict.opengl.glx. Compiling a test program also allowed the derelict opengl library to load glx up for the first time. A few fixes later, it appears to have succeeded loading all functions. That's a good start; eventually I'll actually put the functions to test in a sample program.

The bad news:

Until the C project GLFW is set to compile to a shared library on linux, I won't be able to get the derelict version to work on linux. I tried doing the shared library myself and thought it worked during a test of a C sample, but it doesn't appear to work with the dynamic loading process from derelict; it refuses to load the shared library (the name is correct; the library has been installed in the appropriate location, so I think at least). I don't know why, but I will continue to look into the issue.

- John R.