In 2004, some guy posted a zip with the files needed to use allegro with the D programming language:
http://www.allegro.cc/forums/thread/354471/354474

The file attachment was gone, so I've uploaded it here:
http://torhus.googlepages.com/d-allegro-win32-1.0.zip

I've also started to do some improvements to his work, still for Allegro 4.0.
http://torhus.googlepages.com/d-allegro-win32-1.1-4.0.zip

I'm currently just checking out how to solve certain problem when converting C headers into D, so there's not much new yet. But I thought I'd post to see if there's any interest in this.

What's new in v1.1 is mostly that you can actually access allegro's globals directly now. Like screen, font, gfx_driver, mouse_x, etc. Version 1.0 replaces those with function calls like get_screen() and set_font().

I've started work to convert the 4.2.1 headers into D, but if and when that will be finished, I'm not sure yet. I'll organize allegro.d with one section for each C header, so it's easier to update with new allegro releases. You just go through each of the files in the order they are listed in allegro.h, and update allegro.d accordingly.

For people not familiar with D:
http://www.digitalmars.com/d/overview.html
http://www.digitalmars.com/d/comparison.html

Downloads and installation instructions are here:
http://www.digitalmars.com/d/dcompiler.html

I can tell you right away that the main weakness of D is probably the poor debugger support. You can use windbg to pinpoint access violations, but I haven't been able to use it for much more than that. Hopefully, that will change. for now it's basically printf debugging and such. If that is not an option for you, stick with C/C++.

But for those okay with not having great tools, D will be a relief, whether you compare it to C, or C++. That's what I think, anyway.

I'm going to try it.

Right now, I have to get 4.0 because that's the version that you've wrapped

Also, I'm using Linux (in case you were wondering why I don't just use alleg.lib).

The source files compile well but it's the linking part that's giving problems.

[update]
I couldn't compile 4.0.

I've ported enough of Allegro 4.2.1 to D to be able to actually start allegro and set the gfx mode. Nothing else yet. 9 of 31 headers are more or less done.

So far it's been almost too easy. I'll probably get stuck for weeks in some debugging nightmare or something soon.

For the most part, C features map nicely to D. Only a couple of things need to be worked around. I'm trying to keep as close to C and the allegro manual as possible. No D-ification of allegro is planned at the moment. If someone wants to write wrappers, my work should make that pretty easy.

*** UPDATE ***

Here's a beta release, if anyone wants to try it out.
http://torhus.googlepages.com/dallegro_20_beta1.zip

It's not completely done yet, but it's pretty close.

I've ported 18 of allegro's examples so far, and they work just fine. The only thing that worries me is that expal.d doesn't display the mouse pointer. But the mouse works fine in the other examples.

One of the annoyances when using a C lib in with D is that arrays are not quite the same as C's, and that D's IO functions don't support null-terminated strings. But you can just use C IO (import std.c.stdio;), or use toString() to convert. The D language itself has good support for them, however.

If you give a char pointer to writefln(), it will actually print the address, instead of the contents. Not very useful.

You can also get it wrong the other way around. D's preferred string type is dynamic char arrays (char[]), which are 'fat pointers', or references. Like this: struct CharArray { size_t length; char* data; }; If you give that to a variadic C function, it will print gibberish, since it will 'dereference' the lenght field. Or it might crash your game. You can use the standard D function toStringz() to convert to a C string. Using "%*s" as the format also works.

D has an array type (static arrays) that is binary compatible with C arrays. Allegro has globals that are defined like 'char allegro_error[SOME_SIZE];'. Let's say you do this:

allegro_message("Unable to set any graphic mode\n%s\n", allegro_error);

Since the function is variadic, the compiler won't complain. D does not verify variadic argument types during compilation, since it has it's own, typesafe variadic functions. What happens here seems to be that allegro_error is converted into a dynamic array, since that's the only way to have the length follow the array into the function. Which doesn't help in this case.

So D's static (fixed-length) arrays are not equivalent to pointers when used as arguments to variadic functions. The solution is to just add '.ptr' to allegro_error, since in this case we know it's already null-terminated. But I guess we are bound to forget this now and then.

Another issue is that functions that expect a static array, do not accept a pointer. Take, for instance 'void set_palette(PALETTE p);', and 'alias RGB[256] PALETTE'. If you load a palette from a datafile, you get a pointer to 256 RGB structs. And if set_palette is defined like that, it won't accept any pointer. So you have to do something like this:

PALETTE r = (cast(RGB*)datafile[THE_PALETTE].dat)[0..PAL_SIZE];
set_palette(r);

Which is pretty ugly. One option is to change set_palette() and similar functions to take an RGB* as their argument. Or to make a function template to do the conversion, preferrable without copying.

But ok, let me know how it works out for you.

And I . D seems like a decent language.

Can we compile D and target it to ARM CPUs?

How do you generate one that will target ARM7/9 then? Is there source someplace to compile a toolchain for it?

I'd assume it'd worlk like normal, compile some D code: gdc -target <platform> -arch <whatever> <etc>

That zip file is broken.

For some reason, I can't unzip it. Here's a transcript:

I can unzip d-allegro-win32-1.1-4.0.zip though.

Thanks. It looks like my download stopped prematurely on three separate occasions (and I don't think it was due to the browser cache either). Sorry about that.

Hm, SDL named their D wrapper "derelict". But I think dallegro is a good name

I've been offered svn hosting at tomasu.org. That seems like a good place to set up shop if dallegro is to become an official part of or maybe just an 'offical add-on' to allegro.

If you feel like adding dallegro support to the allegro makefiles, please do. I haven't written a makefile in a few years.

Now I've gotten the main test app to run (tests/test.c). I've run a couple of the benchmarks, and performance seems to be on par with the C version.

If anyone wants to help out, at the moment I'm mostly interested in feedback about the design of dallegro. What can be done to make using allegro with D smoother, how to help users avoid common pitfalls, etc. How to best maintain portability when D gets ported to other platforms in the future, does dallegro need to support memory locking, etc.

Mine has better uptime?