www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dallegro 2.0 beta 4 released

reply torhu <fake address.dude> writes:
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!
Mar 10 2007
next sibling parent reply "Tiberiu Gal" <galtiberiu.backspace gmail.com> writes:
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
Mar 11 2007
parent torhu <fake address.dude> writes:
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. :)
Mar 13 2007
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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 ?
Mar 13 2007
parent reply torhu <fake address.dude> writes:
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;'.
Mar 14 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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#Ext aPredefinedVersions 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
Mar 14 2007