git is shit
linus is a hipster
48bit colour was a gimmick when the ps3 came out, and is still a gimmick considering that almost everyone is using 6bit TN panels.

I've heard the performance of the memory drawing code has been improved significantly.

256 color could probably be done with a shader?

Now add a n00b friendly interface that doesn't require shader programming.

I just want to pop in and disagree with this. I think Java game libraries are direct competitors to Allegro. Two years ago, I came back to Allegro for its Android port. I didn't get very far- even after coming to the forums for advice, I was unable to get Allegro compiled for Android on Windows. There's just so much platform incompatibility with Allegro. It feels like all the Android tutorials were made for Linux, and the whole experience really turned me off.

Or rather, LibGDX turned me on. I've said it in a similar thread, but Allegro needs a lower barrier to entry to survive in the future. GDX has an extremely easy setup process. It even came with a little GUI-based project setup utility. I had my first program running on Android within a couple hours... significantly less time than I spent trying to get Allegro compiled and working for Android! Now I'm using LibGDX for everything, because it's so ridiculously easy to get it running on other platforms.

So basically, A5 needs to turn people on like other libraries do. The real issue is barrier to entry.

OK, I'll admit that certain java libraries like LibGDX, lwjgl, or Slick2D can also be considered Allegro competitors, although the fact that they are Java libraries means that you have to sacrifice some performance for convenience. And of course there are Pygame, Gosu, Love2D, etc that make using SDL even easier at an even higher performance cost. But for many games on contemporary computers performance doesn't matter that much which means they may be indirect competitors of Allegro too.

I also agree that the Android port certainly needs some tender love and care to make it easier to install and use also on windows. And of course as was said before, we need easy binary installations, maybe combined with IDE's, maybe through VM's, maybe through msys2 to get people started much more easily with Allegro.

Looking at the LibGDX web page though one thing jumps to my eye and that is that it's full of video tutorials. I think that's a great idea! We need to make many video tutorials for installing Allegro for different platforms/sub-platforms/IDE's and put them on our web page to show off that it's not that hard to install Allegro if you know what you are doing.

And this is something everyone can help with! Re-do the installation of Allegro on your platform while recording it and post the video. We can then link them, first on the wiki and later on the web page.

I agree that lowering the barrier to entry is important, but since Allegro is a C library, the barrier will always be a bit higher than for game libs written in higher level languages. But I think documentation such as video tutorials can help people get over that barrier more easily.

A wild virtual machine appeared!

It used boot Linux!

It is super-effective!

If it is that windows is being somewhat neglected, then it's because there aren't enough Allegro developers who use windows on a daily basis, but also because supporting Windows is often (not always) harder than supporting Linux. So we need more contributors to Allegro for Windows. Which was kind of the point of starting this thread...

I also agree that need a windows installer with all the bells and whistles. Perhaps NSIS can help us there, it can even be scripted to make Windows installers from Linux. I still think video tutorials would be an additional help, even with an installer, but yes, the installer is probably even more useful.

For one thing, you're potentially wrong about the fastest drivers. When Valve began working on Steam for Linux and porting Valve games to Linux they began kicking back to AMD and Nvidia to work on their Linux drivers. The end result is that in a short amount of time they managed to get Linux ports running faster than Windows ports that had had years of development time...

For another thing, I personally have a Debian VM running inside my Windows because I cannot live with Windows alone. Windows sucks. That said, I run my VM, not some half-baked PoS VM that somebody assembled for their one software project. If everybody did that we'd all have 20 VMs running and no CPU or memory left to host them.

By all means, if users want to run Linux in a VM for the Allegro development I'd encourage them to do so. It's way better. However, if they knew how to use Linux they'd be doing it already and Windows support wouldn't fucking matter. A VM is not a solution.

You're a n00b and I could run circles around you in *nix. Lay back down before you hurt yourself.

If you read carefully, I never really said install a VM just for Allegro. I said it's a much better development environment.

Sometimes... I recompile the Linux kernel in asm.js just so I can put a VM in my VM in my VM.

Mmmmmm... dat 3 MIPS.

We shouldn't bicker about what is best, VM's , installers, tutorials, etc. They're all useful. Now if we put the same intensity in actually making those in stead of just arguing, then the job will be done in a week or two.

Yes, that roadmap is mostly official, but it does need probably need some more clarification.

Those API reviews are mostly for the people who designed those API's, but it also means that the API of the subsystem in question needs suggestions on how the API should be. Concrete suggestions are always welcome. Don't just say "that API sucks", but suggest things like "maybe we should add a function X because..." , or "change the parameters of function y to a, b,c because", etc, etc.

And yes, even just running all of the examples compiled from the latest Git version and reporting any bugs or missing features you can find on your platform(s) is immensely useful! So please do that if you can.