digitalmars.D.announce - dallegro 2.0 beta 4 released
- torhu (33/33) Mar 10 2007 http://torhus.googlepages.com/dallegro_20_beta4.zip
- Tiberiu Gal (7/40) Mar 11 2007 hi
- torhu (3/7) Mar 13 2007 Thanks for the feedback. Let me know if you have any success writing
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (46/54) Mar 13 2007 It mostly works, if you set the extra "version(MacOSX)" and
- torhu (13/20) Mar 14 2007 I'll just reply to the easy parts of your post now, and try to reply to
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (14/32) Mar 14 2007 Np, and announce NG probably isn't best place for discussions anyway :-)
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
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
torhu <fake address.dude> 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 DThanks for the feedback. Let me know if you have any success writing games with it. :)
Mar 13 2007
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
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
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.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(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.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) --andersAs 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