DerelictSFML2 Updated to CSFML3

A couple months ago I added a new branch to the DerelictSFML2 repository to support the SharedLibVersion feature of DerelictUtil, allowing multiple versions of CSFML to be loaded by one binding. Today, I was looking into whether I had updated to support CSFML3 or not when I realized something really bad: SharedLibVersion support can’t work for DerelictSFML2.

The short of it is that different minor versions of CSFML sometimes add new enum members right in the middle of existing enums, changing the value of those that come after. They also sometimes add a new member to a struct type, changing the size of the struct when it happens. While Derelict may be able to load multiple versions of the shared libraries, users won’t be able to use the new versions of DerelictSFML2 with older versions of the CSFML library.

To solve this, I’ve done what I should have done when I merged support for 2.2: I created a 2.2 branch and tagged it with version 1.2.0 for DUB. Next, I created a 2.3 branch and tagged it with version 3.0.0 for DUB. Ideally, it would be 1.3.0, but since I’ve already got the branch with SharedLibVersion support tagged with 2.0.x, I don’t want it showing up in the DUB registry as the newest version. To discourage people from using the 2.0.x versions, I’ve deprecated every module in the corresponding branch.

So here’s what it breaks down to:

  • DerelictSFML2 1.0.x -> CSFML 2.0
  • DerelictSFML2 1.1.x -> CSFML 2.1
  • DerelictSFML2 1.2.x -> CSFML 2.2
  • DerelictSFML2 2.0.x -> DEPRECATED — DO NOT USE
  • DerelictSFML2 3.0.x -> CSFML 2.3

So if you’re currently using DerelictSFML2 2.0.x, please upgrade to 3.0.x. You’ll no longer be able to use SharedLibVersion, but neither will you be left with a bug resulting from calling a function in an older version of CSFML with a new enum value that would likely only manifest itself in the wild.

DerelictGLES 0.0.1

Quite a while back, Ben Boeckel put together a binding for OpenGLES 2. It’s been sitting in the DerelictOrg group ever since, but hasn’t been in the DUB registry. Also, it only had support for loading on Linux.

Recently, when I had some downtime from the book, I decided to spend it trying to get Google’s Angle project working with DerelictGLES. Toward that end, I added some missing support for Windows, including the loading of libegl.dll and libglesv2.dll. Then I decided to try to get it working with SDL.

Long story short, when creating a window with a GLES context, SDL tries first to load everything via the graphics driver and will only load Angle if that fails. The only way to force it to use Angle is to create the EGL context yourself, then pass the window handle to SDL_CreateWindowFrom. I haven’t gone that route yet. Instead, I wanted to get it working with SDL’s context creation.

The problem is that DerelictGL.load will only load the Angle shared library, so if SDL is using the driver’s GLES2 implementation, then there are two different implementations loaded in memory and nothing is going to work. Since there’s no way to force SDL to use Angle, and since the drivers do not have a common name for their GLES DLLs, I opted to add a new load method to DerelictGLES that takes a pointer to a symbol loading function. An implementation for SDL looks like this:

void* loadSymbol(string name) {
    import derelict.util.exception : SymbolLoadException;
    import std.format : format;

    auto sym = SDL_GL_GetProcAddress(name.ptr);
    if(!sym) throw new SymbolLoadException(format("Failed to load symbol %s: %s",
    return sym;

With that, using DerelictGLES with SDL looks like this:

if(SDL_Init(SDL_INIT_VIDEO) == -1) throw new Error("Failed to init SDL: " ~

// Configure SDL to use OpenGLES2.

// This line is optional. If you have Angle (libegl.dll and libglesv2.dll)
// on the library path, SDL will try to load it if the driver does not support
// GLES2. When they are the same binaries that ship with Chrome, Angle requires the
// that d3dcompiler_47.dll be preloaded. With custom-built Angle binaries, this
// requirement can be turned off. If you do want to use Angle as a fallback, this
// needs to be called before creating the window.
SDL_SetHint(SDL_HINT_VIDEO_WIN_D3DCOMPILER, "d3dcompiler_47.dll");

window = SDL_CreateWindow("Hello Triangle",
    winWidth, winHeight, SDL_WINDOW_OPENGL);
if(!window) throw new Error("Failed to create window: " ~

context = SDL_GL_CreateContext(window);
if(!context) throw new Error("Failed to create GLES context: " ~
SDL_GL_MakeCurrent(window, context);


Using this approach, it’s important that DerelictGLES.load be called *after* creating the window and the context. The benefit is that no matter which GLES2 implementation SDL has loaded, the binding will be tapped in to it. I have tested this using the Hello Triangle example from the OpenGL ES 2.0 Programming Guide on Windows. It compiles and runs fine, reporting that it’s using NVidia’s implementation.

This approach to loading should also work with GLFW. It supports GLES already and should have Angle support in version 3.2.

If you’re interested in using this, please give it a spin yourself and see if it breaks for you. Currently, only Linux and Windows are supported. I have a Mac and have no idea what GLES support is like on OSX, so there’s no support for it whatsoever at the moment. I’ve seen some Mac stuff in the Angle headers, though, but I have no idea what that’s about.

DerelictSFML2 2.0.0

I’ve updated DerelictSFML2 to support CSFML 2.2. In the process, I’ve added support for SharedLibVersion, so the same loaders can now load CSFML 2.0, 2.1, and 2.2. For example, to guarantee 2.0 will load, no matter the version of the CSFML shared libraries, you can do the following.

auto slv = SharedLibVersion(2, 0, 0);

The tag to use for your DUB dependencies is derelict-sfml2 2.0.0.

DerelictFI 2.0.1

This is what I get for not having tests set up for loading every shared library in every circumstance. I realized when I went to bed last night that I had incorrectly implemented SharedLibVersion support for DerelictFI, causing it to do the wrong thing. I guess it’s been so long since I touched the code I had forgotten how it was intended to be used. I had to wait until I came home from work today to fix it, but now 2.0.1 is tagged and the DUB repository should pick it up shortly. This is now the corrected list of possible minimum versions for DerelictFI and they should all work as expected.

// Allow versions 3.15.0+
DerelictFI.load(SharedLibVersion(3, 15, 0));
// Allow versions 3.15.4+
DerelictFI.load(SharedLibVersion(3, 15, 4);
// Allow versions 3.16.0+
DerelictFI.load(SharedLibVersion(3, 16, 0));
// Allow versions 3.17.0+
DerelictFI.load(SharedLibVersion(3, 17, 0));
// Allow only the highest supported version -- Currently 3.17.0

DerelictFI 2.0.0 Supports FreeImage 3.17.0

I’ve updated DerelictFI, the FreeImage binding. It now supports up to 3.17.0 (previously it only supported 3.15.4). By default, it will load version 3.17.0 of the FreeImage shared library and will error out on older versions. However, this release also supports the SharedLibVersion feature of DerelictUtil 2.0, so you all of the following are valid:

// Allow versions 3.15.0+
DerelictFI.load(SharedLibVersion(3, 15, 0));
// Allow versions 3.16.0+
DerelictFI.load(SharedLibVersion(3, 16, 0));
// Allow versions 3.17.0+
DerelictFI.load(SharedLibVersion(3, 17, 0));
// Allow only the highest supported version -- Currently 3.17.0

To make use of these features, update your DUB dependency to “derelict-fi”: “>=2.0.0”. From here on out, development will happen in master and merged into the new 2.0 branch when ready for release. Note that I’ve only verified that this compiles and haven’t had the chance to test out the new stuff yet, so if you find any problems please report them in the issue tracker.

DerelictUtil 2.0.0

I’m taking some time away from my priority project to chip away a little at my Derelict TODO list. As part of that, I’ve just merged the 2.0 branch of DerelictUtil with master and tagged a 2.0.0 release. The plan going forward is that all development will happen on master and merged into the 2.0 branch when it’s ready to tag.

For many Derelict users, this change shouldn’t have any negative impact. Most projects should still compile and work without change. There are, however, two potential pain points.

People using DUB to manage their projects will largely be safe except in the case when they are mixing  bindings that use >=, ~>, or == in their dependency on DerelictUtil.  For example, a project with the dependency derelict-util: >=1.0.0” will always pick up the latest version when updated or first pulled down by DUB, but a project with the dependency “derelict-util”: “==1.0.0” will always get version 1.0.0 of DerelictUtil. 2.0.0 is not binary compatible with 1.0.0. At the moment, I’m not sure if DUB goes with the lowest-common-denominator in that case, but ==2.0.0 will certainly conflict with ==1.0.x. As far as I know, most, if not all, of the packages in DerelictOrg use the >= format (I’m not the primary maintainer of every package there and haven’t checked all of them to verify, so there may be one or two that don’t).

People not using DUB to manage their projects can potentially run into issues if they pull down DerelictUtil master and link it with a Derelict package that was compiled against DerelictUtil 1.0.x. If you are manually handling your project, or an IDE is without DUB, make sure to update and recompile all of your Derelict libraries with 2.0.0. Pay close attention to the dub/package.json of any Derelict-like bindings you use to see if any of them are using a == or ~> dependency on a 1.0.x version. If so, file an issue at that binding’s project page and ask them to update their dependency to 2.0.0.

Support for SDL 2.0.4 in Derelict

Thanks to Ben Boeckel, DerelictSDL2 now has support for SDL 2.0.4. It’s available in version tag 1.9.5, so you’ll want to specify that in your DUB configuration. Since SDL 2.0.4 hasn’t actually been released yet, Derelict still attempts to load SDL 2.0.2/3 by default. If you want are interested in using SDL 2.0.4 with Derelict, you’ll need to specify it with a SharedLibVersion when you call the load method.


Migration Complete

I ditched my LEMP stack and set up a LAMP stack instead. I moved everything over to a cheaper VPS plan in the process. I was only using a tiny fraction of the resources I was paying for on the old plan. Anyway, I’m on more familiar ground now.

I was unable to do everything all at once, so it took longer than I anticipated because of interruptions (the biggest one being sleep). I’ve still got a couple of plugins to install and configure. But all of the critical stuff is done, as far as I can see. If you notice any issues, please let me know.

Oh, and I’ve got email notifications working this time around. I was never able to get it functioning on the other system. So if you do leave a comment, it shouldn’t languish for days without a response.

Blog Downtime and Derelict Updates

If you’ve dropped by here any time and gotten a “502 Bad Gateway” error, my inexperience at managing a LEMP stack is probably to blame. As soon as I can make the time for it, I’m going to move to something I’m much more familiar with and eliminate the problem once and for all. Time is something in short supply right now, but I really need to get this done as it’s annoying the hell out of me.

My time shortage also means I’m going to be slower than usual in responding to Derelict issues. I generally prefer to handle them as soon as I see them in my inbox if I can. Right now, I’m knee deep in a new project that’s going to require most of my free time for the next few months. I intend to make time for Derelict every weekend (and whenever I can find breathing room during the week), so please keep that in mind if you report any new issues. Pull requests are greatly appreciated and are guaranteed to get pulled immediately if I have no objections to them, but anything that requires more than a few minutes for me to fix is most likely going to be near the bottom of my priorities.