Tag Archives: Derelict

DLL Downloads for Derelict

Posted on by

I used to make certain precompiled DLLS available for download from the Derelict 3 repository, but since github disabled the downloads feature I’ve been unable to update them or remove them. Nor have I uploaded them anywhere else. But it just dawned on me that I could use my Dropbox account for the same thing. So I updated the Derelict README with the following links (direct links to the DLLs):

SDL2

GLFW3

I’ve gotten a number of requests for these files or instructions for building them. So here they are. I’m not on my normal box right now and don’t have a full build environment for SDL_* libraries, but I’ll try to get at least SDL_image and SDL_ttf up in the next few days (should be back on my main box by then). Also, it was recently announced on the SDL2 mailing list that the project will finally come out of beta for a release in May. At that point, they should be making binaries available and I won’t need to anymore.

Support for OpenGL 4.3 in Derelict 3

Posted on by

I’ve just pushed OpenGL 4.3 support into the Derelict 3 repo. I have no way to test it myself, with no access to a 4.x machine at the moment. There may likely be errors

Having been away from the GL loader for a while, I was rather shocked by the mess I had left there. Given that the majority of 3.0+ functions are reused from ARB extensions, I had needed to come up with an approach for special casing the loading of those functions. The architecture I came up with is rather horrid. Lots of redundant code and really tedious to update, with lots of room for error. I see now a clear way to reimplement it, so getting that done is now on my TODO list. I must have been stoned the first time around.

It has also been requested that I add 4.3 support to Derelict 2. Rather than throwing down my “Bug Fixes Only” card, I agreed to do so. Now that I’ve looked at it I can see it’s going to be a bit more work than I thought. I haven’t touched the Derelict 2 loaders in ages.

Opening Derelict’s Doors

Posted on by

A pull request was recently submitted to Derelict3 adding a binding for the PostgreSQL library, libpq. My automatic reaction was to reject it. Over the years, I’ve been conservative in allowing new packages into Derelict. My focus has always been on multimedia/game libraries. The biggest reason is that I’m the one responsible for maintaining everything and keeping all the bindings up to date. In the past, people have submitted packages and then I never heard from them again. Making sure a binding is up to date can be rather time consuming when you do it all by hand. So I’ve always felt that fewer is better when it comes to which packages come into Derelict.

While at DSource, I was fortunate to receive a lot of community contributions in terms of bug reports and zip archives of new packages, but very rarely received patches to add incremental fixes or changes. Since making the move to github, I’ve gotten a steady stream of pull requests that keep things up to date without any effort on my part. That’s a really big deal for me, given that I’m borderline dysfunctional when it comes to the number of projects and activities I have going on. I still get bug reports that don’t have an accompanying pull request, but much fewer than before.

After a brief conversation in the libpq pull request thread, and given that github is a game changer when it comes to project maintenance, I’ve changed my mind. So from now on I’m willing to accept any dynamic bindings into Derelict as long as they are to a library with a C interface (not ready to deal with C++ bindings yet). I’ll see about putting up a style guide to try and keep some consistency.

So if you have a C library you’d like a binding for, or a static binding you’d like to Derelict-ify, feel free to submit a pull request for it. I’ll be less likely to refuse it from here on out.

Compiling GLFW3 for use with Derelict

Posted on by

It seems some people have had some difficulty in getting the GLFW3 shared library compiled to use with their Derelict-based apps. Rather than post a writeup in my forums, where very few would see it, I figure it’s a good candidate for a blog post. Of course, the steps given here aren’t just for D developers. Anyone wanting to use GLFW3 as a shared library can follow along. And while most of the info is Windows-centric, users on other platforms will likely already have the required tools installed and simply need to follow the steps in the Compiling section below.

Tools

D users are likely going to have git installed already. Those who don’t, really should. It’s not an absolute requirement, as you can download the source for both Derelict and GLFW as a zip archive, but it will certainly make your life a bit easier. So if you’re a Windows user who doesn’t have git already, I recommend Git for Windows. Download it, install it, and make sure the install directory is on your path. This is a command line tool, though, so if you’re a total rube when it comes to git or have a strong aversion to command line tools, you might be more comfortable with GitHub for Windows, a GUI interface that handles most of the icky command line stuff for you behind the scenes. I’ll be focusing on the former, as that’s what I use and am familiar with. Besides, you’ll need to use the command line to build anyway.

Next up is cmake. This is an important tool to have in your toolbox these days if you are working with C or C++ libraries. A number of projects use cmake to manage build configurations. It comes with both a command line tool (cmake.exe) and a GUI interface (cmake-gui.exe). My instructions will be for the command line tool, as that’s all I ever use. And if you can’t figure out the GUI via the interface itself and the documentation, then maybe you ought to give up on this programming thing and find another hobby. You’ll also want this one on your system path.

Of course, no building of C libraries is going to get done without a C compiler. I haven’t touched Visual Studio in years, but if you’ve got it or another compiler other than DMC already installed, you can go to the next step.  I don’t know if cmake works with DMC, or if GLFW will compile with it and as I’m typing this on the POS at my hot dog shop (slow day) am neither able nor inclined to find out. Instead, I’ll tell you to go off and download the latest version of mingw-get. When you run the installer, you’ll be given a choice of packages to install. At a minimum, you’ll want the gcc and msys packages. Technically, you can get by without MSYS, but in my experience you’ll be much happier using it rather than the Windows command prompt in the long run, particularly if you want to start compiling libraries that aren’t set up to use CMake.

Compiling

Now that everything’s installed, open up MSYS and execute this command:

cd /c

Remember, MSYS is a unlix-style command line interface. The C:\ drive you’re used to is configured as /c instead. cd into a directory somewhere to clone the glfw3 repository. For this guide, let’s assume you create a directory off of C drive called ‘libs’.

mkdir libs
cd libs

Now grab the glfw3 source and navigate to the new directory.

git clone https://github.com/elmindreda/glfw.git
cd glfw

Now it’s time for CMake. We need to tell it two things. First, we are running in MSYS, so we need to tell it to give us “MSYS Makefiles”. MSYS has support for shell scripting in makefiles, whereas “MinGW Makefiles”, which is what you want for the Windows command prompt if you aren’t using MSYS, does no such thing. Second, you need to tell cmake that you want a shared library. glfw is configured by default to build static libs, the recommended way to use it these days. However, for Derelict we need the shared lib. So the cmake command needs 2 switches, like so:

cmake -G"MSYS Makefiles" -DBUILD_SHARED_LIBS=1

If you are using Visual Studio, run cmake with no arguments to determine the string you need to pass to -G.

After cmake has done its work, you should have a properly configured Makefile in your glfw directory. If instead you happened to get errors, don’t ask me about them, please. I always ask Google and he usually has the answer. If Google is clueless, your next course of action should be to head to #glfw on freenode.net where glfw support is handled.

So with your freshly minted Makefile sitting there in the glfw directory, we’ve come to the final step.

make

Done. Once compilation completes, you should find the glfw DLL in the src subdirectory. Drop that into a directory with your D app that uses Derelict, call DerelictGLFW3.load() in your code, and away you go.

Now not only do you have glfw compiled, but you are also ready to compile other C libraries you may need for current or future programs, like SDL2 or SFML2. And don’t look at me. That’s an exercise for the reader.