I don't have any 'real' friends. I speak the truth.

Allegro is dead, man. A4/A5....dead....allegro.cc......dead.....let's all just admit it.....I'm the only egg with the balls to say it, so, again, "I'll be the bad guy".

. Damn shame, I thought A5 would get us back but.....let's admit it guys, it's done.

It does look that way... I can't force myself to work on it anymore. I'll fix them as I need fixes but that's about it.

Allegro is pretty much a scratch an itch type thing. Work gets done when someone has an itch they need scratching.

I think the problem is that Allegro 5 changed what Allegro was. The members that were still using Allegro were alienated by it and moved on. If they had to learn something new they might as well learn something better. Allegro had its place in the 90s and early 00s, but it is more or less just nostalgic now. You can absolutely make a game with it, but it is in no way unique in that regard. And in practically all cases something better exists and has a larger user base..

The aged design of the library combined with the fact that most of our members "grew up" and "got a life" means that we have basically nobody left in the community. Even I have a girlfriend, for fucks sake. It's just a matter of time before Hell freezes over and the universe is sucked down a drain.

I think that a higher-level library is in order though. Those that still want to use Allegro 5 (or Allegro 4 for that matter) more power to you. Bug fixes where appropriate. However, low-level is just outdated... How many Allegro users ever really stressed the hardware? Probably almost none. At least within the last 5 years. And even if they did, the hardware is still faster now so it's probably not a problem anymore... Or those that continue to have performance issues are probably suffering from poor algorithms, probably in CPU code. We could probably afford to have a higher-level implementation without hurting performance significantly.

I think the ultimate failing of Allegro is that experience with Allegro can't be considered practical. You won't learn to be a "professional" game programmer writing games with Allegro. The game is forever changed. Those people seeking employment as a game's programmer need to go elsewhere. That's probably the real problem. Most of our game's industry members have moved on to greener pastures because Allegro just wasn't practical for their careers. And what's the point of working on software that isn't really useful? Perhaps we should arrange to have an online "meeting" to discuss the future of the Allegro project and come up with outrageous ideas to really make it useful again.

Maybe you're over-estimating the "language barrier"?

I used to use Allegro quite a lot. Now I use Libgdx. It's a fantastic library. Java / C / C#, who cares?

I do occasionally still yearn for ye-old days of mode-13 and putting down pixels exactly where I want them; but these days are long gone, and OpenGL has now become a familiar friend.

For pleasure-coding, I hate frameworks too. I fell in love with Libgdx within a week of using it. It's wonderfully well constructed.

I got married, bought a house, and am now a manager of a department of around 100 developers. ....I still spend the same amount of free time coding games as ever, I just don't play WoW / Wc3 / SC any more.

There was never that much energy or direction in this community. Ever. Things like it pop up on occasion... Ever seen a monday project thread?

Well, at least in my case, i'm interested but I'm also pragmatic. Would I like it to happen? Sure! Do I expect it to happen? Not really no.

I'm pretty new here, but I'd hate to see it go. I only started programming a few years ago (and game programming shortly after that), but Allegro clicked in a way no other library did. Over the past 2-3 years, I've tried Rubygame, XNA, MonoGame, Unity, SDL, SFML, and Allegro. The only one I liked close to as much was RubyGame, and thats long-since dead. Plus there are the performance concerns with Ruby (as much as I love the language).

I personally don't get the Unity thing, and I HAVE spent a decent amount of time working with it. I don't want to struggle with a heavyweight UI and massive API, I just want a thin library that provides a layer of abstraction over the parts that really ARE too low-level for me to want to deal with (low-level graphics/sound/input/events) and lets me do the rest.

That seems to leave me with 3 options: SDL, SFML, and Allegro. I tried them in that order. The basic examples for SDL and SFML had me tearing my hair out. Maybe I just got unlucky but everything seemed to go wrong for reasons I had trouble diagnosing. Then I tried the introductory Allegro5 tutorials, and everything "just worked".

The thing is, I recently started a project with a small group of people. I suggested Allegro, and everybody said "what?". Then someone else suggested Unity, and I was outnumbered everyone-else vs me. So we went with Unity. And it works alright. I make progress, but there's something missing.

On the side, I'm still working on my own Allegro project, and its just more 'fun'. I've started using the D programming language, and the bindings provided by DAllegro provide something that feels much more natural than UnityEngine+C#. Combine that with Vim and some other nice open-source tools (LMMS, Aseprite, Inkscape, Audacity, Tiled) and I have an environment that I can actually enjoy working in (after all, this is my free time I'm spending).

Well, that turned out to be a longer comment than I intended.

@Erethar
Exactly, Unity has sort of become what SDL was in the late 90's / early 00's.

It's sad too though that in general, Allegro is the absolute last choice in everything. I see that trend often... SDL -> SFML -> Allegro

It should probably be more: Allegro -> SFML -> SDL

Allegro IS too low level by today's standards, but, I would say Unity is too high level. Things like sprite sheet animation, events, etc should be done for you, but for example, I know some students who, for their 4th year undergraduate project in Software Engineering attempted a Magic card game in Unity where 2 players can vs each other.

They used the Photon plugin for networking. After 3 months, the result of 3 students was basically a menu with generic looking buttons, the client WAS the server which caused all kinds of bugs, there were several bugs that they did not understand, the game could only play 1 land card and had to be played perfectly or the game froze/crashed. When one player lost life, the other player's life label was overlapped on top of your life label... they did not understand why... Keep in mind, these are 4th year students in computer science taking a software engineering course. Another student told me after that he could probably have gotten equivalent functionality in about a weekend in Java. Which I would agree with.

Some things they had, like a full-fledged lobby, is a nice out of the box feature, but other things like the game logic looked so tangled that I wonder if all that high level functionality is worth it.

I noticed they had a big interface for their cards, which could be resolved better with composition instead of inheritance.

That's sort of a problem too with having your first game programming experience with Unity. You do not understand fundamentally how to program. Unity uses very advanced OOP mechanisms and to use it effectively you should know OOP and design patterns.

But I guess you run into the same problems with C/C++, however with Unity, the framework is built around those OOP concepts and you should have some experience before taking on a massive project.

Another issue, which is similar to how programming shifted from asm to C, is that the new generation of programmers do not learn about concept such as:
Pointers, Heap vs Stack, Dynamic allocation vs stack allocation, function pointers, vtables etc. Therefore, you can end up with some very inefficient designs and little concern for performance. Then people blame it on JIT when in fact they are dynamically requesting memory in a super tight loop.

Computer Science programs do cover these topics, but there is nothing like hobby programming to learn the ropes.

I was talking with someone the other day and I was wondering if it is possible with Unity to create a Minecraft clone that runs as fast as its Java counterpart. I was wondering if, in general, Unity manages so much for you that you cannot make low level optimizations needed for a game displaying millions of the same cube without switching the texture in OpenGL. Can you optimize the frustum culling, the occlusion culling, PVS, etc? How many cubes would it naively render with its algorithms vs the number MC does?

Maybe it does this just fine, but I did wonder. If it can do it, how much of the wheel are you reinventing, does it require as much work as doing it in Java?

I hate the free networking solutions for Unity so much I made my own. Using a simple client-server model. I might release it publically when it's done and optimized.

When allegro 5 was released, SDL was still using its outdated API and SFML had compatibility issues with AMD. This is why I chose allegro 5, I felt it was ahead of the competition when it was released.

Allegro 5 on Windows has never been ignored and has always easily compiled. It was the FIRST branch of A5 to ever exist actually. If you can't compile it, look elsewhere for the blame.

Allegro 5 isn't, never will be and shouldn't be for everyone. For what it is it's actually very very good. I don't care one bit if it's not popular.

The only "core devs" willing to help out anymore, from what I gather are SiegeLord and I. I personally don't think much needs to be done for it to happen. Once Siege gets his compressed texture addon done, we'll release it. I'll tidy up a few things but I don't have time to do everything everyone wants (and don't agree on a lot of it anyway ).

Allegro 5 itself maybe... I faintly recall earlier versions (before cmake was around to configure and provide project files), getting all the dependencies and then Allegro 5 compiled using MSVC was a royal pain.

I have not recently compiled Allegro 5 on Windows but only two days ago grabbed the latest version from git and compiled almost without problems (only had to fix one undeclared symbol due to it having finally been removed from ffmpeg (I sent a patch to the mailing list) after it had been deprecated for a long time already) on Arch Linux.

The next challenge will be to find a way to cross-compile Windows binaries from within Linux... I guess winegcc is what I will need for that but I am unsure whether that will produce binaries which will only run in Wine and not in actual Windows.