Allegro for D

Allegro for D

Peter Wang

Member #23

April 2000

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.

Thomas Fjellstrom

Member #476

June 2000

Quote:

I've not had any problems with SF recently

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

nonnus29

Member #2,606

August 2002

Quote:

Anyway, it doesn't matter unless we want to bundle the D bindings with the main download

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

Sorry, it had to be said....

link to my blog

juvinious

Member #5,145

October 2004

Quote:

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

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:

1/*
2 *    Example program for the Allegro library, by Shawn Hargreaves.
3 *
4 *    This is a very simple program showing how to get into graphics
5 *    mode and draw text onto the screen.
6 */
7 
8 
9import allegro.all;
10import std.stdio;
11 
12 
13int main()
14{
15   /* you should always do this at the start of Allegro programs */
16   if (allegro_init() != 0)
17      return 1;
18 
19   /* set up the keyboard handler */
20   install_keyboard(); 
21 
22   /* set a graphics mode sized 320x200 */
23   if (set_gfx_mode(GFX_AUTODETECT, 320, 200, 0, 0) != 0) {
24      if (set_gfx_mode(GFX_SAFE, 320, 200, 0, 0) != 0) {
25    set_gfx_mode(GFX_TEXT, 0, 0, 0, 0);
26    allegro_message("Unable to set any graphic mode\n%s\n", allegro_error.ptr);
27    return 1;
28      }
29   }
30 
31   /* set the color palette */
32   set_palette(desktop_palette);
33 
34   /* clear the screen to white */
35   clear_to_color(screen, makecol(255, 255, 255));
36   //clear_to_color(screen, makecol(255,0,255));
37 
38   /* you don't need to do this, but on some platforms (eg. Windows) things
39    * will be drawn more quickly if you always acquire the screen before
40    * trying to draw onto it.
41    */
42   acquire_screen();
43 
44   /* write some text to the screen with black letters and transparent background */
45   textout_centre_ex(screen, font, "Hello, world!", SCREEN_W/2, SCREEN_H/2, makecol(0,0,0), -1);
46 
47   /* you must always release bitmaps before calling any input functions */
48   release_screen();
49 
50   /* wait for a keypress */
51   readkey();
52 
53   return 0;
54}

__________________________________________
Paintown

Peter Wang

Member #23

April 2000

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?

Matthew Leverton

Supreme Loser

January 1999

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

--
RTFM | Follow Me on Google+ | I know 10 people

Elias

Member #358

May 2000

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.

--
"Either help out or stop whining" - Evert

torhu

Member #2,727

September 2002

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.

---
Smokin' Guns - spaghetti western FPS action

Michael Jensen

Member #2,870

October 2002

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!

torhu

Member #2,727

September 2002

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.

---
Smokin' Guns - spaghetti western FPS action