Support for GLFW 3.1 in Derelict

I’ve added support for GLFW 3.1 to DerelictGLFW3. To make use of it, use “derelict-glfw3″: “~>1.1.0″ as your DUB dependency. If  you don’t yet need the new functions and want to continue working with GLFW 3.0, then make sure your DUB dependency is “~>1.0.0″ and not “>=1.0.0″. The former will make sure you only pick up updates to the 1.0.x series, whereas the latter will update you with 1.1.0 if you run dub upgrade. Of course, specifying specific versions is always safe (“==1.0.0″ or “==1.0.1″), but doesn’t give you any updates. The 1.0.x branch has been quite stable, though, so using “==” shouldn’t hurt you at all.

I may add support for SharedLibVersion to DerelictGLFW3 at some point, but right now I have no plans to do so. Pick the version of GLFW3 you want to use and make sure you use the appropriate dependency version so that you aren’t trying to load a 3.0 DLL with the 3.1 binding.

DerelictCEF – Binding to Chromium Embedded Framework

I recently found myself wanting to play around with the Chromium Embedded Framework. I wanted to use it from D, of course, but no bindings exist for it that I’m aware of. So I did what I always do in that situation and created one.

DerelictCEF is a binding to the C API of CEF. I’m not about to try a dynamic binding to any C++ API any time soon. Unfortunately, the C API is not for the faint of heart. It requires a good deal of boilerplate, uses the ugly_underscored_functions_names that didn’t used to bother me until I started regularly using D, and has a plethora of struct types full of function pointers. Worse, the documentation on the C API is scattered and scarce AFAICT.

I’ve added the binding to DerelictOrg and the DUB registry (“derelict-cef”: “>=0.0.1″) for anyone who wants to give it a spin. But be forewarned: don’t expect too much help from me at this point. I’ve never used CEF before I implemented this binding. So far, all I’ve done is grabbed the CEF binaries, taken the sample C code from this github project (something anyone who wants to try DerelictCEF should study) and slapped something sloppily together in D to verify that the binding works on Windows. I’ve uploaded a screenshot to imgur for your viewing pleasure.

I’ll be playing around with this off and on when the whim strikes me, so I’ll be able to kick the tires a bit and look for issues, but I’m sure I won’t be getting anywhere near full coverage. At some point, I’ll boot into my Linux partition and make sure it compiles and runs there. If someone else gets there first, please let me know. I’d also love to hear the same about Mac. Eventually, when I’m more familiar with CEF and confident the binding is doing what it’s supposed to do, I’ll tag a 1.0.0 release.

In the meantime, I highly recommend that if you aren’t familiar with CEF or aren’t willing to put the time investment into learning how to use it, that you stay away from DerelictCEF for now. If you don’t know CEF have a limited knowledge of C, you’re going to be asking for trouble. I’m currently learning my way around the API and until I know what I’m doing, I’m just unable to help anyone else with it. I can already see that this is something that’s going to require more documentation than any other Derelict package. Until I’m able to write it, consider this as being for the experienced and adventurous only.

I’m really looking forward to playing with this.

DerelictFI Gets SharedLibVersion Support

For the longest time, DerelictFI did not support FreeImage 3.15.0. Between that version and 3.15.4, only one function was added in 3.15.1, so I just didn’t see the benefit in adding an entire branch to support it. Unfortunately, I’ve seen more than one report of DerelictFI.load failing because that function was missing, indicating the user’s system had 3.15.0 installed. The most recent mention of it was what prompted me to add the SharedLibVersion feature to DerelictUtil.

Now, I’ve implemented support for that in DerelictFI. I’ve added a new branch and tagged a 1.9.0 release. This will be bumped up to 2.0 once I’m sure all is well. The binding API is implemented against FreeImage 3.15.4, which doesn’t differ all that much from 3.15.0 — a few additional types and one new function. The loader will attempt to load 3.15.4 by default, but it will happily load 3.16.0 if it is available instead (just without the new API features of that version — I’ll have a new branch for that eventually). If you don’t need any of that newer stuff, you can load any version of FreeImage from 3.15.0 on up with the following:

import derelict.freeimage.freeimage;
void main() {
    DerelictFI.load( SharedLibVersion( 3, 15, 0 ));
}

If you are using DerelictFreeImage in your project, please change your derelict-fi dependency to “>=1.9.0″ and give it a spin. It should work out of the box.

New Derelict Feature

These days, a common issue new Derelict users have is the SymbolLoadException. Once upon a time, the exception message was enough for the user to figure out what was going on and act appropriately. Nowadays, there are more inexperienced programmers finding their way to D and Derelict who haven’t quite realized what exception messages are telling them. Nor can they be expected to be able to go out and determine the differences between different versions of a C library such that they can implement a MissingSymbolCallback for the Derelict loader.

The SymbolLoadException appears to be particularly common on Linux, since the package managers often are a release or two behind on some libraries, or the user hasn’t yet realized he needs to upgrade. The new Derelict user can find the versioning scheme for packages like DerelictSDL2 to be confusing, choosing to use the highest version when they really can use a lower one. The documentation, which is far from complete, doesn’t currently help as well as it should.

After giving this issue some though, I’m fairly confident that documentation isn’t going to be enough. The versioning scheme I came up with in the beginning seemed rational. But in addition to needlessly confusion new users, it has also become a bit of a maintenance hassle for me.

I’ll pick on DerelictSDL2 again. In addition to the master branch, there are three release branches: 2.0.0, 2.0.1, and 2.0.2. Each branch name corresponds to one or more SDL releases. I decided this configuration was necessary since the SDL maintainers have no qualms with introduction new functions in the API with a patch release. For example, SDL 2.0.1 and 2.0.2 both added new functions, while 2.0.3 did not. Since DerelictSDL2 can’t load what isn’t there, the 2.0.1 or 2.0.2 binding will fail to load a 2.0.0 shared library. This is rather unacceptable.

Then there are the git tags for dub management. The 2.0.0 branch is tagged with 1.0.x; 2.0.1 is tagged with 1.1.x; 2.0.2 is tagged with 1.2.x. This also seemed perfectly reasonable at the time I implemented it. But, again, it has caused some confusion among users.

The maintenance problems should be obvious. Every time someone sends a PR to master that needs to be applied to each branch, I often have to manually update each branch, as there will inevitably be merge conflicts. If I find a bug in one branch, it also usually must be propagated to all the others. When SDL 2.0.4 is released, it will have more new functions, necessitating a 2.0.4 branch and a 1.3 or 1.4 series of tags, and adding to the maintenance burden.

Until today, I hadn’t really given any thought on a better approach. But after reading a post in the newsgroup in which an issue with DerelictFI, the FreeImage binding, was mentioned, I realized it would be useful to implement one or more loaders for older versions of FreeImage. That means DerelictFI would start to have multiple branches and add to the maintenance burden — a demotivating factor if ever there was one. So I determined to do something that could benefit all Derelict bindings, including third-party ones, without breaking backward compatibility.

The result is the SharedLibVersion struct. It’s implemented in derelict.util.loader. It has three int fields: major, minor and patch. I’ve also added three new versions of the load method, one companion for each of the three existing ones, that takes a SharedLibVersion as an additional parameter. The idea is that you set the fields to the minimum version of the library that you require and the loader will load whichever version is present, greater than or equal to the required minimum.

For example, let’s say you are perfectly happy to load SDL 2.0.0 and don’t need the new functions in 2.0.1 or 2.0.2. In that case, you can load like this:

import derelict.sdl2.sdl;
void main() {
    DerelictSDL2.load( SharedLibVersion( 2, 0, 0 ) );
}

As long as any released version of SDL2 (release candidates and alpha/beta versions aren’t supported) is on the system, it should load fine if it isn’t corrupt. Following is an example and short description of each load method.

import derelict.sdl2.sdl;
void main() {
    // Only knows how to load 2.0.2/3 and will fail on 2.0.0 or 2.0.1.
    DerelictSDL2.load();
    DerelictSDL2.load( "MySDL2.dll,SDL2.dll" );
    DerelictSDL2.load( ["MySDL2.dll", "SDL2.dll"] );

    // Will load 2.0.0 and higher.
    DerelictSDL2.load( SharedLibVersion( 2, 0, 0 ));
    DerelictSDL2.load( "MySDL2.dll,SDL2.dll", SharedLibVersion( 2, 0, 0 ));
    DerelictSDL2.load( ["MySDL2.dll", "SDL2.dll"], SharedLibVersion( 2, 0, 0 ));    
}

This same mechanism is available to all Derelict loaders, as the interface is found in the SharedLibLoader class in derelict.util.loader. The versions of the load method which accept a SharedLibVersion call the protected method configureMinimumVersion. SharedLibLoader subclasses can override this method (it is optional — the default does nothing) and configure a default MissingSymbolCallback appropriate for the library being loaded. How the version number is used depends upon the library being loaded. For example, the patch number is important for SDL, but might be ignored for another library. The goal is to be as flexible as possible and allow each loader to handle things appropriately.

Again, this is entirely optional and no Derelict loader is required to implement this. DerelictGL3 likely never will, for example, since OpenGL is a rather different beast from other libraries and the binding already makes use of a special reload method. I do intend to implement this on the existing DerelictOrg packages where appropriate and encourage third-party maintainers to do the same.

To use this in your own loaders, you’ll need to add version 1.9.0 of DerelictUtil as a dependency to your dub.json. You can see use the DerelictSDL2 implementation as an example. To use this feature with SDL2 in an app, you’ll need version 1.9.0 of DerelictSDL2 as a dependency. Eventually, I’ll bump the versions up to 2.0.0. I have another major feature I want to add and test before then.

This will eventually be in the documentation, which I hope to finish up before the end of January. By the way, any web design wizards who are are willing to submit a PR to the docs with a nice-looking and responsive stylesheet will be much appreciated!

Derelict 3 Removed From DUB Repository

I stopped maintaining Derelict 3 about three months ago, but now and again I see people mention it in the newsgroups. With the latest DMD, it no longer compiles. I have absolutely no intention of fixing it, given that DerelictOrg is the way to go now.

All the packages were migrated to DerelictOrg except for two: the libtcod and FreeGLUT bindings. I have no idea if anyone is using them, but together they are one of the reasons I haven’t deleted the repository. However, today I did remove Derelict 3 from the DUB registry. I certainly don’t want to encourage anyone new to use it.

Anyone who feels they absolutely must have Derelict 3 and can’t deal with DerelictOrg should clone the Derelict 3 repo and maintain their own copy. It’s possible that I will delete it at some point if it proves to be too much of a source of confusion for newcomers.

T3 Updated

I’ve done some work on my toy game app, T3, a simple little TicTacToe implementation for D newcomers  to play around with and learn some features. Primarily, I just updated the long outdated README and edited some comments, but I did make a minor change to the source. I wanted to post about it here to remind people that it’s out there. If you’re new to D and have an interest in games, take the code, extend it, change it, do whatever you want with it.

Be aware that I’ve suddenly encountered a problem with the sound effects on my system and I haven’t yet figured out what that’s about. I won’t be looking into it any time soon, though, so that could be another, as they say, exercise for the reader :)

DerelictGL3 — Bugfixes and Support for OpenGL 4.5

I’ve gone through the OpenGL loader in DerelictGL3 and found a few things that were a bit off, mostly in the ARB extension loader. A few were missing, some were implemented but not loaded. Mostly it had to do with flags being set improperly for extensions that have no associated functions. At any rate, the extension loader should be more robust now, though I plan to go through later and make it even more so.

Support for 4.5 is completely untested, so if you happen to have a card and driver combo that exposes the 4.5 API, I’d love to hear if it works for you. Use the 1.0.7 1.0.8 tag in your dub configurations to get it.

DerelictLua and DerelictFT Branched and Tagged

Both DerelictLua and DerelictFT should now be usable with the latest dub release.

I’ve updated DerelictFT to FreeType 2.5.3. In the process, I decided to reorganize the layout of the files to make them more maintainable. I didn’t do the original binding and, over the years, I’ve never bothered to reformat any of it. That was a mistake, as declarations were spread out all over the place with no connection to how they were laid out in C. That makes maintenance a real PITA. Should be smooth sailing from now on. However, it’s quite possible that I overlooked a new struct field here, or an adjusted function parameter there. I can promise it loads, but users should be on the lookout for bugs. You can use the new 2.5 branch via the 1.0.0 tag in your dub configurations.

I’m more confident about DerelictLua working properly. No updates were needed there. However, I decided to take a different approach with the tagging. There’s a single new branch, 5.2, which corresponds to version 5.2 of Lua. You can use this branch via 1.2.0 in your dub configurations. I chose to use 1.2.0 rather than 1.0.0 because there’s a strong possibility I will add a 5.1 branch. In addition, version 5.3 of Lua is currently in development. This means 1.1.0 can be used to correspond to the former, 1.3.0 to the latter, while 1.2.0 corresponds to Lua 5.2. It just happens that 5.2 is the version the binding was implemented against.

With these two packages properly set up and updated, that means I’m apparently caught up on tagging all of the packages I’m directly responsible for. That should also mean that every Derelict package currently registered with dub should be good to go. Since I want to put off working on documentation as long as possible, the next thing on my list is to add OpenGL 4.5 support to DerelictGL3.

DerelictPHYSFS and DerelictIL Branched and Tagged

I’ve now gotten DerelictPHYSFS and DerelictIL properly branched and tagged with 1.0.0 releases, so they should work in the latest version of dub now. DerelictIL was woefully out of date and also somewhat buggy (which may well be a sign that no one is using it extensively, if at all), so I got it updated to version 1.7.8 of DevIL, the most recent release of the library. If anyone out there is using DerelictIL, I’d love to hear if it’s working for you.

DerelictPHYSFS was originally implemented against version 2.0.3 of PhysicsFS. Since no other releases of that library have been made since, all should be well. I used this binding a bit a little while back (which actually was the reason I implemented it) and didn’t encounter any issues with it then.

Only a few more packages to branch and tag, then I can focus on documentation. I’ve also got a binding to Allegro 5 that I’ve been working on sporadically for a while. It’s not quite yet complete, but isn’t far from it. I plan to get it that some time soonish and will add it to the repo when I do.