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

"Allegro is a game programming library for C/C++ developers distributed freely, supporting the following platforms: DOS, Unix (Linux, FreeBSD, Irix, Solaris, Darwin), Windows, QNX, BeOS and MacOS X. It provides many functions for graphics, sounds, player input (keyboard, mouse and joystick) and timers. It also provides fixed and floating point mathematical functions, 3d functions, file management functions, compressed datafile and a GUI."

Feature list here: http://alleg.sourceforge.net/readme.html


dallegro 2.0 is a new set of D bindings for Allegro.  It's primarily tested on Windows, but is reported to work on linux.  It's also likely to work on MacOS X, although untested so far.

A bunch of examples, plus a larger demo game is included in the dallegro download.  They are all direct ports of regular Allegro's C versions, and are primarily used for verifying that dallegro works.  They are obviously not good examples of D programming.  I plan to add a simple Tetris clone as an example of a D game using dallegro.

dallegro is compatible with both Phobos and Tango.  Which revisions of Tango it compiles with is a bit unclear at the moment, but 1856 seems to work.

The dallegro API is the same as for C version, so just follow the Allegro manual.  Differences are noted in readme.txt.

Docs are available here:
http://alleg.sourceforge.net/api.html

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

The original announcement and discussion on the allegro.cc forum:
http://www.allegro.cc/forums/thread/589597/0

All Allegro's examples, the demo game, plus the tools and tests that are ported to dallegro, seem to run without a hitch.  Performance is on par with the C version.  The platform-independent parts of the API are completed, so are Windows, linux and OS X specifics.  So as far as I'm concerned, dallegro is ready for some real game programming!

On Sat, 10 Mar 2007 18:45:43 +0200, torhu <fake@address.dude> wrote:

> http://torhus.googlepages.com/dallegro_20_beta4.zip
>
> "Allegro is a game programming library for C/C++ developers distributed freely, supporting the following platforms: DOS, Unix (Linux, FreeBSD, Irix, Solaris, Darwin), Windows, QNX, BeOS and MacOS X. It provides many functions for graphics, sounds, player input (keyboard, mouse and joystick) and timers. It also provides fixed and floating point mathematical functions, 3d functions, file management functions, compressed datafile and a GUI."
>
> Feature list here: http://alleg.sourceforge.net/readme.html
>
>
> dallegro 2.0 is a new set of D bindings for Allegro.  It's primarily tested on Windows, but is reported to work on linux.  It's also likely to work on MacOS X, although untested so far.
>
> A bunch of examples, plus a larger demo game is included in the dallegro download.  They are all direct ports of regular Allegro's C versions, and are primarily used for verifying that dallegro works.  They are obviously not good examples of D programming.  I plan to add a simple Tetris clone as an example of a D game using dallegro.
>
> dallegro is compatible with both Phobos and Tango.  Which revisions of Tango it compiles with is a bit unclear at the moment, but 1856 seems to work.
>
> The dallegro API is the same as for C version, so just follow the Allegro manual.  Differences are noted in readme.txt.
>
> Docs are available here:
> http://alleg.sourceforge.net/api.html
>
> Subversion:
> https://alleg.svn.sourceforge.net/svnroot/alleg/bindings/dallegro/
>
> The original announcement and discussion on the allegro.cc forum:
> http://www.allegro.cc/forums/thread/589597/0
>
> All Allegro's examples, the demo game, plus the tools and tests that are ported to dallegro, seem to run without a hitch.  Performance is on par with the C version.  The platform-independent parts of the API are completed, so are Windows, linux and OS X specifics.  So as far as I'm concerned, dallegro is ready for some real game programming!

hi
where do I report "no bugs"?
it runs out of the box on windows with dmd 1.007;
thanks for porting it to D


-- 
Tiberiu Gal

Tiberiu Gal wrote:
> hi
> where do I report "no bugs"?
> it runs out of the box on windows with dmd 1.007;
> thanks for porting it to D

Thanks for the feedback.  Let me know if you have any success writing games with it. :)

torhu wrote:

> dallegro 2.0 is a new set of D bindings for Allegro.  It's primarily tested on Windows, but is reported to work on linux.  It's also likely to work on MacOS X, although untested so far.

It mostly works, if you set the extra "version(MacOSX)" and
tell the Makefile about gdmd and the allegro-config --libs.

(You might want to do a "version(darwin) version=MacOSX;" and
you might want to use the allegro-config output by default ?)

However, you get link errors (= no "__mangled_main_address")
since it is missing the END_OF_MAIN macro that C/C++ uses...


This is the same situation that standard SDL on Mac OS X has,
with the library written in Objective-C and needing some init.
So they #define the usual main over to something else, and then
provide a library with "main" and a callback to your usual main.

For SDL it is "SDL_main", and for Allegro it is "_mangled_main".
It's expecting a C/C++ main, i.e. extern(C), and not the D main.
You can see my SDL wrappers for a workaround, where the D main
simply calls a patched mainlib and then handles the C callback.

i.e. the "main" from the Objective-C runtime library is renamed
to "D_main", and then the D main routine calls this after setup.
Then, when Objective-C is done with the setup for SDL/Allegro,
it will call the SDL_main/_mangled_main with a new argc/argv.


Where the Windows/Linux versions simple wrap the D args up as C,
do the "C" callback, and then wrap the C args back into D again:

int main(char[][] args)
{
    return sdl.main.SDL_InitApplication(args);
}

extern(C)
int SDL_main(int argc, char **argv) // _mangled_main for Allegro
{
    char[][] args = sdl.main.SDL_ApplicationArgs(argc, argv);

    // regular D program goes here

    return 0;
}

This gives the D wrapper of the C library a chance to intercept,
and initialize the Objective-C runtime if needed (i.e Mac OS X)


A similar workaround should work for using Allegro from D as well ?
But you do need to patch Allegro, and to modify the D programs...

The Allegro file is src/macosx/main.m, library is liballeg-main.a
(this would be the "Objective-C runtime" library mentioned above)


> All Allegro's examples, the demo game, plus the tools and tests that
> are ported to dallegro, seem to run without a hitch.  Performance is
> on par with the C version.  The platform-independent parts of the API
> are completed, so are Windows, linux and OS X specifics.  So as far
> as I'm concerned, dallegro is ready for some real game programming!

Good Work!

As a closing remark, you might want to offer an allegro.allegro
module (just a new name), in addition to the allegro.all module ?

i.e. just make it "public import" the other one, for flexibility...
http://www.prowiki.org/wiki4d/wiki.cgi?BestPractices#ConventionalModuleNameforImportingAllModulesinaPackage

--anders


PS. Might post a more complete Mac dallegro how-to/patch, later on.
    But it shouldn't be any harder to use Allegro than to use SDL ?

I'll just reply to the easy parts of your post now, and try to reply to the rest later.

Anders F Björklund wrote:
>(You might want to do a "version(darwin) version=MacOSX;" and
>you might want to use the allegro-config output by default ?)

http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Version#ExtraPredefinedVersions

According to that link, GDC defines MacOSX.  But if that's not that case, I'll just use 'darwin' instead.

> 
> Good Work!

Thanks!

> 
> As a closing remark, you might want to offer an allegro.allegro
> module (just a new name), in addition to the allegro.all module ?

I'm planning to rename allegro.all to allegro.allegro.  Calling it allegro.all was a mistake I made early on, and then it really did import everything.  Another option would be to put allegro.d directly in the dmd/import/ folder, but then at least two other files should probably go there too.  And maybe more later.  So it might be too messy to do that.  Even if 'import allegro;' sure looks nicer than 'import allegro.allegro;'.

torhu wrote:

> I'll just reply to the easy parts of your post now, and try to reply to the rest later.

Np, and announce NG probably isn't best place for discussions anyway :-)
Replying by email is perfectly alright for the implementation details.

>> (You might want to do a "version(darwin) version=MacOSX;" and
>> you might want to use the allegro-config output by default ?)
> 
> http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Version#ExtraPredefinedVersions 
> 
> According to that link, GDC defines MacOSX.  But if that's not that case, I'll just use 'darwin' instead.

That page is more of a "wishlist", the only two predefined versions on
Mac OS X using GDC are: darwin and Unix (compare with: linux and Unix)

MacOSX is a superset of Darwin, i.e. all MacOSX would also be Darwin -
but in theory not all Darwin need to be MacOSX - they *could* use X11...
(In practice, you could just add a line like the one above to the top.)
See also: http://en.wikipedia.org/wiki/Darwin_%28operating_system%29

>> As a closing remark, you might want to offer an allegro.allegro
>> module (just a new name), in addition to the allegro.all module ?
> 
> I'm planning to rename allegro.all to allegro.allegro.  Calling it allegro.all was a mistake I made early on, and then it really did import everything.  Another option would be to put allegro.d directly in the dmd/import/ folder, but then at least two other files should probably go there too.  And maybe more later.  So it might be too messy to do that.  Even if 'import allegro;' sure looks nicer than 'import allegro.allegro;'.

D doesn't allow you to have a module and a folder with the same name.
i.e. if you have an allegro.d, you can't have an allegro/ directory...
Besides, the repeated name is something of a common D standard anyway ?
(I'm currently using windows.windows, unix.unix, sdl.sdl, gl.gl, wx.wx)

--anders