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.
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
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.
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.
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.
As per my last post, DerelictODE is updated, branched and tagged. Use “~>1.0.0″ for ODE 0.13 and “~>1.1.0″ for ODE 0.13.1 in your dub.json dependencies. There are a couple of issues to be aware of, which are explained in the READMEs for each branch, but bear repeating here.
First, unlike the old DerelictODE configuration, the updated version is configured to work with the double-precision version of ODE out of the box. This is because the latest versions appear to be configured that way if nothing special is done. However, if you follow the instructions for building ODE with premake (which is included in released ODE source archives), you can easily configure single-/double-precision and debug/release versions for the library. To load the single-precision in Derelict, add a versions field to your dub.json and declare “DerelictODE_Single”. You need do nothing special to load the debug version. Providing it is the only version of the ODE shared library on the path, it will be loaded automatically, but if the release version is also on the path it will be preferred.
Second, there are a couple of functions that have been disabled because they are not exported from the ODE shared library. dPrintMatrix is disabled in both 1.0.0 and 1.1.0 of DerelictODE, but it has been fixed in the ODE repository and will be available in the next release. I’ll enable it when I update to that future version of ODE. In the 1.1.0 version of DerelictODE, dInifiniteAABB is also disabled, as ODE 0.13.1 doesn’t export it (at least on Windows). I’m going to file an issue with the ODE project after I finish this post.
I’ve verified that everything loads fine with the double-precision DLLs, but I haven’t tested anything, nor will I be. I’m not an ODE user and know very little about it, so I will rely on those of you who use DerelictODE to report any issues you find with it. So please be sure to let me know if you do find something.
For a long while I was under the impression that ODE was no longer under development. Then someone pointed out to me in an email exchange a few months ago that the project was indeed alive and well and development had been moved over to Bitbucket. I wasn’t sure where things stood with DerelictODE in relation to the new development, but I was told that it was able to load the new stuff fine.
Now I can say that I’ve dug into the details and I can see I’ve got some work to do. There are some cosmetic changes that really don’t affect anything on the D side, but still should be made (for example, the custom types of ODE 0.12 are now prefixed with ‘d’ in 0.13 — so int32 becomes dint32). More importantly, there are some new types and API functions, plus some older functions have been deprecated. That calls for an overhaul.
I don’t want to leave any current users in a lurch, so I’ve created a new 0.12 branch and tagged a 0.1.0 release. If you are using DerelictODE in a project at this moment, you should update your dub dependency from “~master” to “~>0.1.0″ to ensure that your app won’t break from the new changes.
My plan moving forward is to update master to match ODE 0.13, then create a 0.13 branch and tag 1.0.0. Then I’ll update master to 0.13.1, make a 0.13.1 branch (unfortunately, the ODE devs seem to have no problem adding new functions to a point release) and tag a 1.1.0 release for it.
I’ve gotten three more packages properly branched and tagged: DerelictPQ, DerelictSFML2, and DerelictAL. For the SFML2 binding, you’ll want 1.0.x for CSFML 2.0 and 1.1.x for CSFML 2.1. If anyone plans to dig around in the DerelictSFML2 code, I took some time to clean it up a bit and get it in line with the other packages. It was actually looking rather cluttered and ugly.
First off, sorry to those of you who posted comments here and didn’t get them approved for over a month. I’ve been neglecting the blog and, to a large extent, Derelict and most things D (with the exception of the newsgroups). I’m slowly trying to find my sea legs again, so I hope to get back to full speed soon.
As a start, I’m getting caught up on some much-needed Derelict love. That means getting caught up on closing issues and merging PRs and also taking care of things that have been sitting too long in a dusty corner. For example, both DerelictTheora and DerelictVorbis are properly branched and tagged now. I’ve still got a few other packages to go through and do the same to, but that requires first understanding how the C libraries are maintained. My branch/tag scheme depend on it.
For example, the SDL developers aren’t shy in adding new functions to the point releases, so 2.0.1 has functions that don’t exist in 2.0.0, and 2.0.2 adds new stuff as well. New functions means that updates of Derelict will fail to load older versions of the shared libraries. Therefore, with DerelictSDL2 I branch by point release so that updates through dub don’t suddenly break everyone’s apps (excluding any errors I make in the binding implementation, of course). GLFW releases, on the other hand, tend to bump the minor version number when new functions are added, so in DerelictGLFW3 I only need one 3.0 branch (and a new 3.1 branch when they eventually release it) and need not branch for point releases. Any new types that might be added in a point release won’t break the loader.
I don’t actually use the majority of the libraries to which Derelict binds. I’m only intimately familiar with a handful of them. As such, I need to take some time to dig around the release history of each library before deciding how to approach branching/tagging. I’ve been putting it off forever, but no more. I’ll be working to tick all this stuff off my TODO list over the next several days. So if you’re seeing deprecation messages from the latest dub when using a Derelict library, it means that I haven’t gotten around to tagging that particular binding yet — but it’s coming soon.
Given the ever-increasing number of new Derelict users sending me emails and occasionally posting in the newsgroups, I also am acutely feeling the need to get the documentation of each package going. I was trying to motivate myself to get started on it a few months back, but my aversion to writing documentation won out and I kept putting it off. I don’t think I can put it off any longer.
If you have any questions or requests regarding Derelict and can’t find help in #D or in the newsgroups, feel free to email my aldacron handle at gmail.