I took a look at what I said I was going to in the other thread - building Android examples. To my surprise, it's already there. Guess I ignored it all this time. Just needed a few small modifications to get it to work on Windows host. So I'll move on to the next thing on the list.

I feel like these kinds of things belong in some sort of extension library rather than Allegro itself.
When you first get started, having too many features available can be overwhelming.

I remember spending a lot of time in XNA wondering what the hell a 'SpriteBatch' was and why I had to use it for all my drawing.

When I started using allegro, drawing things to the screen actually felt simpler -- it was just a single function and the arguments I was passing felt pretty self explanatory. As I got more experienced, I started struggling with meticulous manual ordering of draw calls and use of al_hold_bitmap_drawing. Finally I decided to write a module that would handle sorting bitmaps by a 'depth' value and batching for efficiency. About halfway through developing it, I finally went 'OH! I bet THAT's what a SpriteBatch is' (this was around a year after I had stopped using XNA).

Just got out of a University where most classes teach OOP as THE programming paradigm. After writing terrible, terrible OOP code in Java, C#, and C++, I finally started to program in pure, raw C. C taught me more about how to write good OOP code than any OOP language had, because for the first time, I actually understood that OOP isn't a necessity or requirement. OOP is a tool that can be extremely useful, but so easy to abuse.

I remember assignments that had me building inheritance hierarchies just for the sake of demonstrating what inheritance IS. Turns out that the best way to understand inheritance is to try working without it.

Well, I am absolutely new and can't program a game to save my life, but I KNOW that deploying allegro for Windows both with MSVC and Mingw64 is easy.

And I mean that, you only have to know some VERY basic concepts about building the damn stuff.

Might be because for work (oh so long ago) I had to jump through fiery hoops to get my code to work on embedded platforms so in comparison this feels easy, but I doubt it.

Allegro 5 is instuitive and complete, I can't do much for comparison (having dabbled only a tiny bit with SDL) but it's no doubt a VERY good lib.

The real problem to me is that there seems to be no regular devs besides Trent and SiegeLord (as per Trent's words) and so there's a definitive slowdown in release pace....this might have shrunk the community interest and thus the community itself ...in projects like this the community drive is of paramount importance.

I'd LOVE to contribute, but as a matter of fact I'd just love to BE ABLE to...I'm simply not enuff skilled, and can't dedicate myself to improve such skill.

Biggest concern out there I think should be (after the prioritires for 5.2) tidy up the Android port deployment, I guess. I don't care for it particularly but it clearly the hot topic in gaming and might attract more users, and in and of itself the mobile marketplace is a powerful showcase.

Allegro is not done, but unfortunately it surely suffers.

The denial in this thread is nigh legendary.

I like Allegro for what it is, and especially the community. I don't think it's important for Allegro to be popular. For me, I feel that Allegro is like that odd coffee shop hidden at one corner of a town that people rarely go to. Every time you pass by, you'll see the same bunch of people hanging out. Every year. As time passes, so did those people. Some got married. Others have girlfriends. But they'll still come back to that coffee shop to meet up. And that's cool. I like that coffee shop.

Reminds me of this xkcd comic: http://xkcd.com/1305/

Or maybe I'm just too sentimental.

Good. Exactly what this thread needs. With those numbers, and the ones I'm working on from actual developers, we'll have a (hopefully) good idea of whether anyone is actually using the lib they are downloading, because that's what actually matters.

I like to occasionally appear, though usually it's when friends remind me Allegro is still a thing.

So a decade ago, I had a need Allegro could have filled: General purpose raster graphics library. No, not cross platform, but general purpose. Give it a chunk of memory, and here are a library of function for doing anything you could ever want (sprite wise) in that RAM. Hey maybe even some simple 3D too. I would have loved to have it as a fallback renderer, when a GPU wasn't available. I still think there's a distinct lack of a good (or any) general purpose fast raster graphics library. And heck, if there was an API variation you could feed a single triangle/quad render function too, it could be forward compatible as well. Would have been great for PC/Console/Obscure porting. Alas.

When I was a wee-lad using Allegro for my gamedev on DOS and Windows 95 machines, it was the raster graphics performance and features that made me use it. Before Allegro I was a big user of a Turbo Pascal library I think was called SPX. It was capable of rendering full-screen 2D graphics at 60 FPS on my 486 DX computer. I didn't understand what or how it was so capable (I didn't understand Assembly yet), but it was easy to make, load, and display sprite graphics. It came bundled with a tool SPXMaker, and that was my workflow (edit sprites, export, load, draw in game). It felt good.

When I eventually moved to C, Allegro filled the same niche. I paired it with a similarly useful sprite and package editor, the name of which I can't remember (I never found anyone else that heard of it or used it). I believe I had a Pentium 90, which was like infinite CPU power back then. I would dabble with other libraries and tools, but Allegro is the one that performed best (at least on my teenage budget of $0). Screw Direct X, I had DJGPP and this monster.

To me, Allegro was a complete C workflow for making, packaging, loading and displaying sprite graphics on screen fast.

Eventually I start doing Nintendo GameBoy homebrew. Lo and behold, the community has an amazing sprite and map editor freely available. My workflow stays intact (make assets, load assets, display assets). Before I know it, I'm making commercial GameBoy games.

A friend starts Ludum Dare. I champion Allegro as a viable tool for rapid development, because my workflow. Easy to make, load, and display assets. I use it for years, most of the early years of LD. It's me and my workflow.

At some point I stop using Allegro. I had worked on nearly a dozen console games, 4 of those in assembly, and I was always the tech lead (doing the low level shite nobody else wanted to). It just doesn't feel right anymore. I'm thinking of high resolutions and bit-depths, file format conversions, PNG files, and whatnot. The Paletted BMP and PCX formats just don't cut it anymore. SDL becomes my new home.

The thing I lost moving to SDL: Fast Raster Performance, and the workflow. The workflow was already gone. I think my mystery Sprite Editor was a DOS DJGPP program, and I was a "Paint Shop Pro" user now. Switching to a fullscreen DOS app really felt clumsy (though it had basic animation support, or rather, a button I could push to toggle frames). It's the mid 2000's, and nobody runs DOS apps anymore.

SDL quickly solved its inadequacies by having native OpenGL support. Suddenly I could do stuff again, faster than ever, with free scaling and rotating support. I still lacked a great workflow for making assets. I had an okay one, painting large images and inputting numbers (regions), but nothing so clean and optimal ever again.

Basically: If Allegro did something with that heritage of being a great sprite library (or even a full workflow), it would still be useful. I don't know what A5 is trying to be. Nostalgic? Newstalgic?

Few weeks ago there was this thread where we tried to remember people from the old days. Sure, lots of people have moved on but some are still here and are working on Allegro because it's their hobby. Nevertheless, the reason why I'm still lurking around and using Allegro library is the community.

I remember few years back when asked why I chose Allegro over SDL for my project. I answered that it's a matter of taste. I've used SDL for some school assignments because the boilerplate code was using it. It seemed reminiscent but I'm familiar with Allegro. Allegro was the first graphics library that I was introduced to so if it hadn't been this way I would have been now posting on some SDL forum probably. Thanks to this I've found a way into this wonderfull community.

Another reason why I'm still using it is the fact that I like the engineering part of game programming - getting the engine together and on top of that the gameplay mechanics. Right now I'd like to embark on creating small turn based strategy. I was thinking about Unity and then I realised that I'd get full blown game engine I'd need to learn and just use it, not to tamper with it. I like to get my hands dirty, I want to learn something. Not just to use some complicated technology of which 70% I won't even utilise. Not to mention that lots of recent Unity games sometimes suffer from occasional performance drops. I mean, I'd rather not finish the game but learn something new in the process.

Anyway, to sort of back up your position. Back in the days of Allegro 4 when I was still using Windows I can't remember ever trying to build Allegro because of the dependencies, instead I was using prebuilt binaries. Fast forward, nowdays I'm using Linux and Windows fills the role of a gaming console. When I was porting my projects to Windows I chose again prebuilt binaries of Allegro 5 because I couldn't be bothered with building the damn thing from sources. But I wouldn't blame Allegro for that. Thanks to the cmake the build is super easy, the hard part is setting up the development environment on Windows, setting up cmake and obtaining and building the dependencies.

Edit:

As far as I can remember from my last project - procedural world generator library with demonstration application - it worked nicely. I used Allegro for loading bitmaps and converting them to OpenGL textures and then for setting up the window and handling inputs. I managed all the rendering by myself using Allegro only for rendering fonts and GUI (using Guichan). I never came across problems on this part.

-- end of edit --

Oh and by the way:

I thought much the same in 2012 congratulations, as someone mentioned, we haven't thought it would be possible

Tomasu: I believe I have similar code in my project as well the only problem I've ever ran into was trying to be smart when accessing private BITMAP data to construct OpenGL cubemap texture

PoVRAZOR: Allegro 5 allows you to get the psed of OpenGL for 2d games without needing to learn the complex API. But it works well in concert with opengl as well. Allegro 5 is in essence allegro for the OpenGL age. And yes we support PNG and JPEg now as well. Which goes to show that the reputation of Allegro4 as a dDOS library still haunts us. Maybe we should rename the library after all? Allegretto perhaps :p

As of the popularity of Allegro, 5000 downloads per month isn't bad, but I see a slow but undeniable downwards trend from 2011. I think the lack of recent updates may be responsible for that.

FWIW I hear about people using Allegro 5 fairly frequently that do not visit this site.

Try to convince them to come here to talk about their projects. It would bring some life to this (half)dead community and might inspire more people to give A5 a fair chance instead of simply not using it because it seems dead, unused and frowned upon in the light of more popular alternatives... well, I know you said you don't give a damn about popularity, but more users could mean more potential devs for the library as well as they find more bugs and could implement more features, so you would not have to stay grumpy over having to do everything yourself.