I had a binding to Allegro 5 in an older iteration of Derelict, but it was problematic. There were unexpected crashes when using some Allegro dlls on Windows and there was a big issue with how to handle Allegro on Mac (it requires a special main function to run). So a while back I learned from reading about SeigeLord’s DAllegro5 that the crash issues were specific to dlls compiled with MinGW and have disappeared with newer versions of the compiler. I also discovered that he had come up with a way to deal with Mac. With those issues gone, I decided to start on a new DerelictAllegro5 binding for DerelictOrg. I worked on it sporadically, then somehow forgot all about it.
Recently, it popped back into my head so I dug up the source that I last touched in March of last year. To my surprise, I had managed to finish every module I had intended to finish. It only required a bit of tweaking to get my little allegtest app to compile and run. I’ve done a bit more work on it to make my life easier in maintaining it and now I think it’s ready for a work out, so I’ve pushed it to GitHub and will register derelict-allegro5 version 0.0.1 with dub as soon as I publish this post (I want to link here from the README until I get some better documentation).
If you are using or thinking about using Allegro 5, I’d appreciate if you’d test this out for me. Right now, it binds to the 5.0 series rather than the wip 5.1. There are a couple of things that make this binding different than other packages in Derelict and you need to be aware of them before using it.
First up, on Mac you need to launch the app with a special function in the loader. Allegro requires some special handling on OSX in order for things to work properly. I’ve adapted SeigeLord’s solution and created a function in the loader called “run”. It takes a pointer to a function that returns int and has no parameters. It will launch a separate thread and call the function pointer. So on OSX your app should call DerelictAllegro5.run(&foo) after you’ve loaded the libraries.
I’ve put up a sample at DPaste that shows how to load all of the Allegro libraries and handle the Mac workaround. Note that although the sample versions out the Mac stuff, you don’t need to do that if you don’t want. You can call the run method on any platform and it will work just fine. It’s up to you how to handle it. Also note that I’m catching any thrown Throwable in macMain, saving it in a module-scope variable, then rethrowing it in the main function. That’s because the function pointer passed to DerelictAllegro5.run will ultimately be called from the C side, so I want to make sure no exceptions are lost across the C/D boundary. If someone discovers that exceptions can cross that boundary on Mac without problem, then that isn’t necessary.
Second, the naming convention of the Allegro dlls on Windows is just outright annoying. Most C libraries out there do not include patch versions in the dll names, but all of the Allegro dlls do so. That means Derelict has to specifically ask for the 5.0.10 version of the libraries or the 5.0.11 version of the libraries and so on. On top of that, the dlls are compiled to either statically link with system libraries or not. If there’s an ‘-mt’ in the name, it’s the former, while ‘-md’ means the latter. Then there’s the option to use a monolithic dll which bundles all of the separate addons into one monster library. That’s not including the debug versions!
So, I had to make a choice: support every variation of the libraries or only rely on a specific set? I opted for the latter. By default, the loader for the core library and each addon expects the -mt versions of each library. Each loader will first look for the monolithic dll; next it will try 5.0.11; finally it will attempt to load 5.0.10. If you prefer to use the -md versions, or would like to support any 5.0.x version of the library, for now I recommend you just rename your dlls to something simple (like allegro5.dll, allegro5-audio.dll or whatnot) and pass those names to the load method for each loader to override the default behavior.
I have no idea if the Allegro5 build system is set up to build and install monolithic versions of the library on Mac and Linux, so the loaders currently don’t attempt to load those. However, the situation is better there with the 5.0.x versioning scheme, since most systems will probably be configured with a Mac framework or a dylib/so with the generic 5.0 prefix. This will allow any 5.0.x version to be loaded, though the loaders do look for 5.0.11 first on Linux (it’s intended to be the last release of the 5.0.x series, anyway). If any Allegro users on Mac or Linux could let me know about what exactly is installed on your system, that would be great. I’m particularly interested in whether or not there’s a monolithic version of the library available. Next time I boot into my Linux partition, I’ll see about installing Allegro and check it out myself (but I’m in no hurry to do that).
It seems like I’m missing something, but I can’t remember what it is. So that’s all for now. If you try DerelictAllegro5, please let me know even if it works flawlessly. Prebuilt Windows binaries for 5.0.10 are available from the Allegro Wiki. Linux users should be able to get 5.0.10 from your package manager. I’ve heard that SeigeLord updated MacPorts with 5.0.11. If you want to build it yourself, source packages for the recently released 5.0.11 and older versions are up at Sourceforge.