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.

D has changed alot over the past couple of years. They added some really nice template syntax and the contracts thing is kinda interesting. Must look into again sometime...

Keep us posted about your progress!

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.

Great, thanks! I have a bunch of D-related stuff lurking around on my hard-disk, but I never really had the incentive to give it a try in a real application (just a bunch of very small projects playing around with the language's features). I guess it's time to get started. Once there's support for Allegro 4.2

Keep it up!

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.

nice to see, this also gives me an excuse to play with D.

And I . D seems like a decent language.

Cookies goes to Tydr Schnubbis.

Can we compile D and target it to ARM CPUs?

gdc is supposed to target anything gcc can. (The digital mars compiler itself only can target Windows and Linux I think.)

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

The gdc readme mentions it from what I remember, didn't read too closely though. Or I think it just says something like "If you need a D cross-compiler, do it like with a C++ crosscompiler." Anyway, googling for "gdc arm" seems to turn up some posts.

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

We are having trouble with dallegro on linux. juvinious and I are looking into it. We haven't tried gdc yet, just dmd. Some examples still crash on linux. I don't run linux, so if anyone feels like some debugging, we'd be glad to get some help.

*** UPDATE ***

It's not crashing anymore! Turns out I had had a small search-and-replace accident, which didn't matter on windows, but caused crashes on linux. Scary.

That zip file is broken.

Broken how? I just downloaded it, and it was fine.

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

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

It worked fine for me, however, I recompressed it for you.

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.

http://torhus.googlepages.com/dallegro_20_beta2.zip

New test version. A couple of new examples, lots of bug fixes and cleanups. And it includes a build script for linux, that also enables static linking. If you've previously tried this on linux and given up on it, please try again.

allegro_error and cpu_vendor are now char pointers, like allegro_id already was. Should make it harder to do the wrong thing when calling variadic C functions.

More volatile variables have been wrapped as properties. Not sure how useful this is.

**EDIT**

Question for you guys: Is DAllegro a good name or not? Anyone got better suggestions? Doesn't matter much, I know.

I should probably email the original dallegro guy and ask if he's okay with me stealing his project name.

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

I'd like to see D become an officially supported language for Allegro, either by bundling the bindings in the main package or as a separate download. It would be nice to install it with just a "make install-d" command.

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.

Why not the Allegro SourceForge repository?

Mine has better uptime?

I've not had any problems with SF recently, and I'm pretty sure SF is faster for me. Anyway, it doesn't matter unless we want to bundle the D bindings with the main download, in which case it would be easier if it was in the same repository.

In the past month or so I haven't seen any major problems, but I've not been looking. Before that I'd hear complaints with svn, cvs and the web sites all the time.

Oh, and I will be moving svn.tomasu.org to a higher bandwidth (10mbps vs 1mbps) server at some point. Initial setup fees suck.

Hmm, and what about the other language bindings? Aren't they good enough?

Sorry, it had to be said....

Well considering that syntactically, you will practically have all the original C functions intact unlike other bindings which usually resort to wrapping the C functions. I would say it would be a much more reasonable candidate to be included.
Here is what exhello looks like:

I knew this would come up. I basically agree with juvinious. If the bindings are basically a straight adaption of the C API to the target language (judgement call here), and the bindings are mature then I think they should be official. A big problem that prevents people using language bindings are that they become unmaintained or just disappear off the net. Who wants to write a serious program with a language binding under those conditions?

That argument is somewhat circular. Something won't be well maintained or used until it becomes official.

Well, C/C++/D are essentially the same language, or at least closer to each other than any other language - so that is some argument for giving D a special status. It's just a direct translation of the C headers into D headers, something quite different from a C++ or D wrapper which changes the API.

But most important, it seems several developers agree to maintain it, which is easiest if it's in the same repository - so e.g. adding a new symbol can be done in one commit.

I'll use svn on sourceforge, I didn't know that was the official repository.

I guess I'll ask on the AD mailing list for access, where to put it in the tree etc?

I don't know for how long I'll be able to maintain this project. But it should be easy for anyone to continue maintenance.

*** UPDATE ***
Since there's no svn yet, I'll release again.

http://torhus.googlepages.com/dallegro_20_beta3.zip

Rough changelog:
- more examples translated
- updated linux build script
- the big test app (test.c) is translated and seems to work
- added some more of allegro's #defines and platform macros, in the form of global constants or version id's. See readme.txt.
- added EMPTY_STRING and _set_color()
- benchmarked fix point maths and selected the implementations that were the
fastest on my Athlon 1.4. Not sure how smart that is.
- various fixes and cleanups

The new Tango library is supported, just apply tango.diff. Only tested with dmd 1.0.

*** UPDATE 2 ***
The Allegro demo game (demo/demo.c) seems to work flawlessly with dallegro. But I'm wondering if someone can tell me why the global struct arrays 'star' and 'asteroid' are declared volatile. They don't seem to be used by timer code or anything. If there's no good reason, I won't bother to make them 'volatile' in D, since that messes up the code a bit more than it does in C.

Just a guess, but they might have been volatile because at one point in development they were used in a timer, but now are not...

Also: Congrats on your progress/contributions with dallegro, I'll look forward to using it someday!

Thanks.

From now on, this is the place to get the latest dallegro:

https://alleg.svn.sourceforge.net/svnroot/alleg/bindings/dallegro/trunk/

I'll release zips occasionally, especially if people who are not familiar with svn request it.

*** UPDATE ***

I'm looking into porting allegroGL to D. The smallest example compiles now, but I don't have a dmd-compatible agl.lib to link with.

So I've tried to make a makefile to compile allegroGL with dmc. The makefile seems to work, but there are problems with allegroGL macros. I haven't looked into that yet. So the makefile isn't enough to get it to compile, the source also needs to be adapted.

An easier solution, at least temporarily, might be to allow allegroGL to be compiled into A .dll. Does anyone know how much work this would take?

Another possibility is to use a tool to convert msvc COFF into dmc OMF. Does anyone know about a free tool to do that? Digital Mars has got one called coff2omf, but it's not free. And I don't know how up to date it is either. I think Borland might have one, but I haven't looked into that yet.