I really don't get why it's so dead. I seriously don't get the appeal of Unity et al. I tried it, I did not like it. SDL 2 has haptics but it has a lot of other issues that Allegro solves for you. SFML is cute but no mobile support. Lib GDX is only for Java, Cocos2D only works on mobile...

I can't think of a better library than Allegro in its domain. Sure, I would probably not use it for a 3D game but for 2D games, Unity is not that amazing. I have seen countless students at my University try to make games with Unity. They get certain things done super fast, but then a bunch of things are broken/missing/crash. To get a solid polished 2D game I would say is not much easier with Unity, other than the syntax sugar of C#.

I watched a video the other day of a games company that makes their money writing Unity plugins, because a lot of people are like, ouuu we're gonna use Unity and make this super ultra amazing game, then they buy all these plugins, tile editors, etc, and the game never even gets close to done because they underestimate how much work it is to make a full polished game. Because, it's not really much easier with Unity.

As you can probably tell, I'm not a big fan of big frameworks.

In Unity, if something is broken you are at their mercy, in Allegro, just submit a patch. When I started building my game, I found bugs in A5 that I submitted patches for and they became part of 5.0/5.1. That's a pretty neat feeling if you ask me! I stopped contributing to Allegro because my game became stable. If ever my game starts crashing because of Allegro again, I will fix it.

All the libraries I use are either built by me or 100% open source / bsd. I have contributed several fixes to the networking library I use too.

That's something I just can't have with closed sourced proprietary Unity plugins.

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.

It's not an "us versus them" game. Find something high level that already works and use it/contribute to it. We don't need to make Allegro Unity or the Allegro Game Engine or some such nonsense. You'd only need to construct a new project if there's an actual use for it.

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.

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.

I more or less agree with bammcaig, specifically with Allegro being too low level to be practical.

I started programming games with Allegro, then abandoned game programming (didn't have time anymore) and just recently (thanks to a thread here) tried Unity and fell in love with it.

For me, the problem was that with only allegro everything took too much time to accomplish. It's not that Allegro is doing something wrong, it's that there are still a lot of steps you need before working on your actual game ideas!

With Unity i don't have to worry about resolution, physics engines, file loading, path finding, animation, and whole load of other low\mid-level stuff. The things I personally implement are the ones that I actually want to make different and unique. It's really faster and more pleasant!

And while i think it would be nice to have an open source alternative to Unity i doubt there is enough energy left in this community to attempt a project of such magnitude

[FMC Studios] - [Caries Field] - [Ctris] - [Pman] - [Chess for allegroites]Written laws are like spiders' webs, and will, like them, only entangle and hold the poor and weak, while the rich and powerful will easily break through them. -AnacharsisTwenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover. -Mark Twain

[FMC Studios] - [Caries Field] - [Ctris] - [Pman] - [Chess for allegroites]Written laws are like spiders' webs, and will, like them, only entangle and hold the poor and weak, while the rich and powerful will easily break through them. -AnacharsisTwenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover. -Mark Twain

I am considering to shift my priorities away from developing an HTML5 lib and to dedicate more time to developing using Allegro5(maybe start with porting/rewriting all my A4 programs) for reasons taking into consideration performance and machine access restrictions imposed by HTML5.

It is certainly nice to be able to quickly run/test everything directly in a browser without waiting for anything to compile but there still seem to be too many drawbacks (webgl performance is sluggish on hardware which is just a couple of years old and the very restricted access to the local filesystem makes it impossible to implement things like periodic autosaving(unless backed up by a webserver adding more bloat)... there is also no way to get low level access to UDP/TCP socket programming yet in the browser world).

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).

The logical response is: A5 is dead; time to start on A6 and not fuck it up this time.

Look to the core strengths of Allegro. It was always easy to set up, understand, and get 2D apps knocked out quickly. A lot of people felt that A5 reversed those trends. You had a place in the gaming world and you lost it. Curiously, few things have really moved in to fill the void.

Also, don't totally ignore the Windows branch. No one here wants to hear this but that was a major fuckup. For a long time it wouldn't even build from scratch for most people.

-->Graphic file formats used to fascinate me, but now I find them rather satanic.

@EretharExactly, 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 don't know about you, but I tend not to work on things that don't interest me. If people want it, they can work on it.

Quote:

For a long time it wouldn't even build from scratch for most people.

Which version and when? I know its a pain to compile from scratch, including all of the dependencies, but it's not been impossible as far as I can remember. Now-adays you can just grab msys2 with mingw64 and go to town. It includes most of the dependencies (possibly all of them), and its much easier to build yourself.

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.

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.

Which version and when? I know its a pain to compile from scratch, including all of the dependencies, but it's not been impossible as far as I can remember. Now-adays you can just grab msys2 with mingw64 and go to town. It includes most of the dependencies (possibly all of them), and its much easier to build yourself.

Dunno. We're talking a few years back, and I don't/didn't care enough to have kept the old files. I remember seeing a note on the download page strongly urging people to download pre-built binaries instead of rolling your own lib.

Quote:

I don't know about you, but I tend not to work on things that don't interest me. If people want it, they can work on it.

Uh huh. You don't see where that leads, do you? People don't work on it because SDL et alia already exist and are easier to get started with. People come here, download A5, see what it has to offer, and walk away. It's time to stop ignoring that.

-->Graphic file formats used to fascinate me, but now I find them rather satanic.

I wholeheartedly disagree with the general sentiment. Allegro is better than ever.Problems with A5: It's late, not advertised, crucial features (shaders, Android) are marked as 'unstable', building binaries could be easier.

This means: More and more people learn to use SDL/... instead. Those will hardly ever become A5 users, even if we know it's better. Everyone learning SDL now is probably lost for Allegro.

Priority should therefore be: Get 'stable' A 5.2 out, provide binaries, advertise and see. This is IMHO more important than adding 'some cool feature X I like', but maybe not gonna happen?

What is even planned for 5.2? I think some people have shown their willingness to help out recently, but at least I have the impression that there is no binding plan. There is a roadmap, but Trent (one of the core devs) said it's incorrect. IMHO, we need a binding plan, so people can see where they could contribute. IMHO this has to be done by the core devs, because they know the project best.

Just to clarify: I'm not for popularity as an end in itself, but because I think more users means more bug reports, more stability, more potential developers, overall better quality and less risk of 'dying'.

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 ).

I also wanted to add that, I've always sort of thought that the name Allegro itself might be a source of pitfall because Allegro up to A4 was software rendered and ran on DOS. I think a lot of people think Allegro and they think software rendered. A lot of people I have spoken to think this as well. They are unaware that a hardware accelerated Allegro even exists. Calling it something like libGator would probably have yielded more interest in itself.

I really think releasing 5.2.0 is a great idea, and releasing binaries, and having some very basic getting started guides for each platform could help a lot too. In addition, maybe also some kind of template project that comes with Allegro could be really useful too. This template project has everything to get started fast. You do not have to understand timers or event queues, it exposes a function for logic, a function for rendering, functions for mouse callbacks, etc. A bit like GLUT. GLUT was so popular because of how blatantly easy to get something going, not because it was that great.

There needs to be a way for people to get their ideas out as quickly as with A4. Then once they gain xp, they can look deeper into how the template works and modify it.

This is how I learned A5. I copied a tutorial from the Wiki and did not understand much, but I had a render, logic, kb, and mouse callback so I started making games.

Allegro 5 on Windows has never been ignored and has always easily compiled.

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.