Sad there were names appearing on the AD mailing list I haven't seen here for a long time as soon as there was talk about A4 and not A5. Evert even proposed doing an A5 driver for A4...

On topic:
I'd volunteer if I had the time to actually get something done regularly, which is not the case now unfortunately. Maybe I can try to contribute to documentation (and finally try to improve the website texts).

Help is always welcome

I do not have the time to spend or I would probably attempt to help out. I sort of wish more attention was paid to A4 because despite its limitations it did what it did well enough and was quite popular. I think that A4 still has advantages over A5. A5 can do more things, but it steps outside of "beginner" territory doing it. And honestly, there are just much more popular alternatives in that field for Allegro to really compete. Certainly in the state that its in now.

Implementing the Allegro API in HTML5/JavaScript would be silly because the API was designed around the features and limitations of the C language. JavaScript is a wildly different world. It would not translate. And if your HTML5/JavaScript project is unrelated to the Allegro library then sharing the same name would be confusing and silly. By all means, create yet another HTML5 game programming wrapper, but don't bother calling it Allegro.

Allegro has returned to its roots as a hobby project for the developers at this point. I'm sorry to see the community it had splitting up too because I really enjoyed the discussions and group dynamics we used to have. I intend to stick around, but I'm not expecting things to suddenly pick up steam again. We'd probably be better off just organizing a social group around this community instead of basing it on a dying programming library.

Let's create a game engine based on A5, let's call it Allegro Maker

Agreed.

I like Allegro 5, it's a nice engine, but it has strayed pretty far from it's original which was quite a bit easier, though much of it isn't too difficult to learn.

Some of the items that bother me is:

1) The sound system. For me personally, I used to adjust the pitch of my sound samples on the fly, as they played on A4 with no problems. I can no longer do that, at least not as easily. Not too big of a deal, I can live with it, but, to me it gets away from what the library was originally intended for, and that was to make things like that easier. And it may be easier than coding for windows or whatever (though I have played sounds with straight windows code, no problems), I think it should be more like A4. Add more layers to simplify things (at least so you have similarities in functionality to A4).

2) Lack of a GUI system. As ugly as it was in A4, you still have a basic GUI you could use for different tasks. One main problem I have is with the file selection dialog (al_create_native_file_dialog()) which doesn't respond to the default filename supplied, it doesn't use it at all, a royal pain for people who use my game editor when they go to resave a level of mine they loaded and they have to remember the filename because the Allegro code doesn't remember it, even though I supply it as an argument. al_create_native_file_dialog(), when supplied something like *.map should show all files with that extension or a specific filename if one is supplied the way A4 did, and most Windows programs do at the very least. I can handle my own GUI otherwise.

I only wish I knew more about programming that sort of thing or I would try my hand at it. The thing is, if I want to have the sort of features like the one mentioned with a file dialog, than I'll have to code my own windows specific code which defeats the entire purpose of using Allegro in the first place.

I like Allegro 5 and have done some nice things with it but...

For the kit thing, at the very least I'm working on getting pre-made binaries automatically made for as many platforms as possible. Building a simple installer with nsi would be doable as well.

I have no fixed timeline on when the service will be set up, but I'm half-ish way there.

@Polybios: Actually I am hoping that some people will take Allegro 4 off our hands and become maintainers of it. Personally I think Allegro 4 is obsolete, but some people have used it in their old programs and they still need support we don't have time to give them.

@Dennis: Max Savenkov started a port of Allegro 5 to Emscripten which I think is a nice idea in the long run. It's not for JavaScript programmers though, but for C programmers. But JavaScript based game library would be a completely different project.

@bamccaig: I used Allegro from the DOS days and personally I don't think the Allegro 5 API is that much harder to use than the previous incarnations. OK, we now have some very powerful stuff that is slightly harder to use, and for that we could use some convenience functions to make things even easier. Also, there are many ways to write games these days, either game libs for Java or Javascript, or whole game engines like Unity but they are not our competitors. Our main competitors are SDL 2 and SFML 2 and I find Allegro 5 much easier to use that both those libraries.

@Paul whoknows:
An Allegro based game engine could be nice, like Pygame is to SDL. It's a separate project from Allegro 5 though, but I'd encourage anyone who'd like to start on this idea.

@Phrasz: Allegro is not an engine but a library. The bad part of this is that you have to write your own (simple) engine to use it, the good part is that you avoid the "engine problem" where all games made with the same engine play exactly alike. I never had C at school, I taught it myself because it's the best language for game programming. Performance still matters a lot.

I do agree Allegro 5 could be made easier to install, maybe bundled with an IDE and a compiler. So the "kit" idea is a good one. Perhaps MSYS2 will prove useful in that aspect. As for more demos: I'd encourage everyone to write great demos or even games that use Allegro5! A kit does not preclude us adding features to Allegro though. And we're wroking hard to try and make a new stable release, Allegro 5.2. So your help would be most welcome.

@NiteHackr: The sound API now is very powerful, but we could indeed use some help to etend the easy to use API on top of it. Same for other functionality I guess. I personally agree that we should have a simple non-native GUI addon, but the problem is that we can't agree on how it would look like. The old A4 GUI & GUI API was too ugly. As for the native dialogs addon, your contributions would be most welcome! It's not that hard, if you know C already.

@Polybios (again): Yes, that's the spirit! As I said before, SDL is our main competitor and it has a very mediocre API. Even when I started programming there were engines around like Verge or OHCRPGE but I never used those as I felt the "engine problem" already back then. Allegro 5 is for the discerning person who doesn't want to be bound to an engine but in stead wants to have full control of all details of their game development. Your help in updating the wiki would be great, and yes, we need to update the web site too.

We have a lot of multilingual people here; maybe we could make our docs multilingual and that would give us an edge?

I'm swamped with contracts and school, but as I have time, I will edit the docs and wiki.

Who all has GUI systems? Maybe we can sit down on IRC and agree on a set of core functionality for a core GUI addon?

{"name":"608872","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/3\/4306ccc9e15ea5217223ce864ec0f116.png","w":1080,"h":608,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/3\/4306ccc9e15ea5217223ce864ec0f116"}

We're starting an international awareness tour... All aboard...

I'm working on my second million!

I'm referring to stuff like this :

      ALLEGRO_SAMPLE_INSTANCE* instance = al_create_sample_instance(sound);
      al_attach_sample_instance_to_mixer(instance , al_get_default_mixer());
      al_set_sample_instance_playing(instance , true);
      al_play_sample_instance(instance);
      al_rest(.016);
      printf("playing sample instance of %s\n" , file.c_str());
      while (al_get_sample_instance_playing(instance)) {al_rest(.016);}

That is confusing and ugly. That is what is necessary to see if a sample is currently playing. al_play_sample should return an ALLEGRO_SAMPLE_INSTANCE, not bool like it currently does.

Also, having to know that you have to call al_reserve_samples to set up a default voice and mixer otherwise nothing will play is annoying as well. That is more of a doc issue than an api issue though.

Fine, not a problem. The main difference between your allegro 5 example and your allegro 4 example is I can change the pitch of an allegro 4 sample while it is playing, I can't do that with the allegro 5 sample without a significant amount more code. The difference grows quite a bit in the amount of extra code I need to implement in order to do something that used to be fairly straight forward under Allegro 4.

Now this isn't a major problem for me, I managed to work around it. If you play my Deluxe Pacman 2 game (link below) you will hear the pitch change as the pills get eaten, but it is in jumps. If you play the Deluxe Pacman 1 game (link below) programmed with Allegro 4, you will hear the pitch smoothly change as you eat the pills. Not a big deal as I said, I can live with that. When I was shown the code I would need to mess around with just to smooth that out, well, the effort was not worth the headache.

My MAIN headache is the file dialog, specifically saving a level with my game's level editor, I supply a default filename and it doesn't appear in the dialog, which is a pain when someone has been editing a level, goes to save it and forgets the name of the level they were editing and it doesn't appear in the save dialog. If THAT was fixed I would have no real complaints I can think of with Allegro 5. I DO have a working game with it now, so I think I have proven I can stick it out and make the effort to learn to use it.

Edit: Oh, and it is precisely this sort of sarcastic reply to people that will help drive them away.