In the last two years activity on developing Allegro5 has slowed down considerably. There are various reasons for this but the main factor in my opinion is that we need more people to help out. Hence this call for help.

So who do I think we need? Here's the short list:

Maintainers & Developers per platform.

• One or more Android maintainers and developers.

• One or more iOS maintainers and developers.

• One or more OSX maintainers and developers.

• One or more Windows maintainers and developers.

• Linux developers are welcome but less urgently needed.

The job of these Maintainer/Developers is to develop ports of new features on their platform, and to make sure that everything stays working for them on their platform. You need to have some experience of programming in C on your platform for this job. No need to know about Allegro's internals, you'll learn that progressively as you help out.

Documentation Writers

• We need one or more people to improve the documentation where needed. No programming skills needed, just read the documentation and suggest improvements.

• One or more wiki wranglers. The wiki needs to be cleaned up and kept up to date better. No programming skills needed, just read the wiki and suggest improvements on the talk page or edit it outright if you know how to improve an article.

There is a road map with features that we still may want to implement:
https://wiki.allegro.cc/index.php?title=Allegro_roadmap

And here are some details on how development proceeds:
https://wiki.allegro.cc/index.php?title=Allegro_development

If you feel you'd like to help out, please reply here, or on the mailing list, or visit the Freenode #allegro channel for a friendly chat.

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

Well, I'm out.

Help is always welcome

A port of the library to HTML5/Javascript would make some sense now(or maybe not a port but a rewrite/reinvention, keeping in mind all the stuff that HTML5/Javascript already does for us for free without the need for extra dependencies).

By the time that rewrite/reinvention is finished, browsers will be sufficiently advanced to compete with the performance of platform native compiled code.

That rewrite could be called AllegroWeb or similar to avoid confusion with the older libs. Usage would be simpler than ever before, the only dependency for both developers and users would be an up-to-date browser.

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.

So... it's manually doing what Emscripten and asm.js already do automatically?

I already played Dune 2 recompiled for Javascript last week, let alone a fully network aware Linux VM.

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

TL;DR: We are old, the library is old, we are from C (which is rarely taught); We need to make it easier to "unzip and ready to code like kit" and a bitchin' set of demos...

The Problem
===========
Bamcaig has it right: Allegro is TOO complex for beginner, and we frankly don't have a way/method/solution to mitigate this fact. Why use allegro when Unreal, Unity, and all the other ones are out there: http://en.wikipedia.org/wiki/List_of_game_engines

C is no longer a primary language at school either... (thanks to Java/Python/etc).

A solution
==========
I feel that "kits" need to be made before features need to be added. We have the power to make standalone scripts to build/configure/setup a development environment. Better yet a Virtual Machine could be made to allow cross compiling of EVERYTHING except Mac ports (put mingw(-w64) with all the android stuff on Linux).
(Closest thing to a "kit": https://github.com/phrasz/A5_Installer & https://github.com/phrasz/A5_1_Apt_Installer)

Also: we have no "WOW" demos... We are pitching/showcasing/promoting "very simple" demos, but this pales in comparison to a ready to rock full platformer that Unity has: http://unity3d.com/learn/resources/downloads.

IMO
===
We need less new features and less of ones that don't promote core gaming (FMV << Network/Multiplayer - Unless you are Nintendo - But I've always whined about this ... but I'm getting there for known what to do), more stable/predictable Binary releases (look at the last 2 years and lack thereof), and a SICK demo that is deployed on all supported OS's (and something with Alex and I wish we'd be able to co-op).

Self-Devil's Advocate: Unless I'm submitting to the dev branches I cannot complain, and won't (at least often ). Also, we are a LIBRARY not an ENGINE, but people want engines nowadays (see Paul's statement ^)

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

Allegro isn't an engine. That's like saying why use a gasoline when you can use a car?

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.

I think people need more confidence in Allegro5. AFAIK is has advantages over SDL.
But, of course, when everyone is whining about that Allegro 4 was better and that A5 is not a framework or an engine, we will get nowhere.

The thing which made me switch to A5 was events. Honestly, input in A4 was a mess. I remember implementing "events" myself by polling the key array for changes which was just absurd (because it must have been filled by events anyway on non-DOS platforms). The mess of A4's input system kept permeating my own code constantly.

No, Allegro5 isn't an engine or a framework, but it's a very nice C API in the spirit of A4 which does a lot of things better and has a lot more features. There are even some commercial games done with it.
I see there are better alternatives for absolute beginners now, but SDL, which does roughly a similar thing (with a much uglier API ), isn't dying out either AFAIK.

A5 isn't particularly hard to learn, I admit you need some more lines for initializing things, though. But you get more flexibility in return.

/rant

That's good news! Please keep it up!

Maybe the "real" problem might be that you need a different way to approach things when you deal essentially with a 3D API in the background, ie. you don't optimise by using "dirty rectangles" but by using a spritesheet / texture atlas etc.

Another problem is of course that A5's development and release was somehow going on in the background, not even the official website changed much. Ie. you can't tell by looking at the facade that there is still life in the cellar where engineers have developed a whole new exciting thing.
But we've discussed that already.

edit:
You do remember that in the thread I started with using the bad m-word there were some old guys appearing who didn't even know about A5? IIRC, they were using SDL now.

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

This lifted my spirits. Keep it up! We're rooting for you.

I will fund a full-time developer for a year, when I make my first million.

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?

I think part of the confusion is that people think allegro 5 is just a continuation of allegro 4 when it has actually completely diverged from it. This myth needs to be dispelled. Basically, Allegro 5 needs to be advertised more, so people figure out that it's not a dead library.

And yes, the input system for A4 was kind of a pain. I wrapped it in an input library so I would have actual events and not polling too.

Actually building allegro 5 is not that hard. At least on Windows and perhaps Linux. I don't see much support for iOS or Android though. Even OSX seems to have difficulties with frameworks and xcode.

The sound API for allegro 5 is confusing. And/or the docs just aren't good enough to explain it properly at this point. When you have to make a forum thread just to get a sound to play something is lacking.

{"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...

Well, it's not much, but my own game "Deluxe Pacman 2", not 100% finished yet, but playable (only a few menu options left to do) is available on my page at the link in the signature of this message. It was done 100% with Allegro 5 and I think it looks quite nice (just got a $1250 donation from someone to complete it), comes with level editor, free of course. My original Deluxe Pacman 1 was created 100% using Allegro 4 (actually started using Allegro 2 on it for DOS!).

I think it shows off Allegro 5 nicely, for 2D stuff anyhow. Also 100% written in pure C (compiled with C, not a C++ compiler, using the 2011 C standard setting).

I have an older video of it I have showed before and the level editor...

Gameplay...

Level Editor...

Would love to see what others have done as well.

I'm working on my second million!

al_init();
al_init_acodec_addon();
al_install_audio();
al_reserve_samples(16);
sample = al_load_sample(filename);
al_play_sample(sample, 1.0, 0.5, 1.0, ALLEGRO_PLAYMODE_LOOP, NULL);

allegro_init();
install_sound(DIGI_AUTODETECT, MIDI_NONE, NULL);
sample = load_sample(filename);
play_sample(sample, 255, 0, 1000, 1);

If you find one or the other significantly more complicated, I feel for you.

Ever try to get Allegro 4 built for Android? Now that was difficult.

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.

That stuff is only required if you want more control. Which most people don't. But it is considerably more flexible.

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.

There are some ideas that may make the "simple" audio api more useful, but it means adding a crap load more functions to the api, pretty much duplicating a bunch of the sample instance api. soooo its kinda a bit of a clusterfsck.

Really, the original api probably should have returned a sample instance, but then it tries to do clever things like reusing its own sample instances internally and they can be freed... so thats why it has the crazy sample id thing. ugh.

I may give the audio another go. When I first encountered this problem I was still fairly new to allegro 5. I have gotten my hands dirty now and accomplished quite a bit with it, so perhaps I could revisit this and see if I can understand what needs to be done. <shrug>

Then how is it any different from the instance api? The whole point is you don't have to manage a second set of data structures or set up mixers, etc.

Anyway, it's not like backward compatibility really matters between 5.0 and 5.2. If a substantionally better API is made, it could be included without hardly affecting anybody for the worse.

I want to help with maintaining Allegro for iOS/OSX or Windows, but I have zero idea how to do it though.

Well, you might want to find a specific thing to work on, then study the source to figure out how the part you want to change works. And of course ask questions here, and on the AD mailing list.

How exactly do these mobile ports work? I thought IOS had to be written in Objective-C and Android required Java?

ObjC is C/C++ compatible, and Android has the NDK which supports native C/C++ code. Android is harder as there has to be some java code at the top layer if you need to avoid the NativeActivity code (which allegro does want to avoid, its a polling interface, not event based).

I personally don't mind just adding a few al_set_sample_id_gain/pan/speed functions to make the simple audio API more usable... what's an extra 5-6 functions between friends?

Alternatively/additionally, could easy add a ALLEGRO_SAMPLE_INSTANCE* al_play_sample_from_mixer(ALLEGRO_MIXER* mixer, ALLEGRO_SAMPLE* sample, gain, pan, speed, loop) to simplify Edgar's code a tiny bit.

I've TL;DR'ed some of the comments here, but the gist I've gotten is that

1: It would be very useful to have a plethora of examples, and
2: In order to get a lot more control over some of the features (like sound), the code grows quickly from "dumb simple" to "a bit frustrating".

I started using Qt for work, and as soon as you launch the Qt Creator application, the first screen you encounter is a page FULL of run-out-of-the-box examples: You select it, hit compile, and you're instantly running little demo programs showcasing one specific aspect of the language.

I remember A4 having a hefty examples/ folder that I learned from. (I haven't touch A5, but I'd imagine that it, too, has something like this?) Would having even more example code be beneficial?

Most of my interest in game development centers around tile-based ones: Those take a bunch of brain power to wrap your head around: You have to understand how tilemaps work; you have to draw some layers over other layers; you have to include music; you have to have NPCs; you have to handle user input.

If A4 or A5 had one or two "example" demos like this (think along the lines of the AngryBots demo for Unity) where a new user can immediately see "how simple it is" to get something up and running, where you actually tie a bunch of those previous demos/examples together (hint hint), I think it would vastly help me to adopt it.

@Fishcake:

Thanks for trying to help out! It will be easiest to help work on allegro if you clone Allego's git repository, so you can make a patch easily with git diff or git format-patch. The Allegro Git repository is explained here:

http://alleg.sourceforge.net/git.html

First try to get allegro compiling for your platforms, try all the examples and look for things that you feel are not working well. If you find something like that report it and we can look into fixing it together. If someone else adds a feature to allegro, or makes a change, get it from git again and try it out for your platform(s). That's basically what maintenance is about. If all seems fine and no maintenance work seems needed, then try to think of a feature you'd like to add and propose that. Then we can look into implementing it. The road map may give you some ideas on what other people would like to add to Allegro:

https://wiki.allegro.cc/index.php?title=Allegro_roadmap

@SiegeLord

I agree a few extra functions to flesh out the "simple" audio API would be nice. I guess the documentation also needs to be enhanced. While the "complex" audio API isn't really that complex, it may be scary to beginning programmers and that's something we can improve on.

But aren't you also giving up the whole point of JIT compiled code? Running across many architectures and taking advantage of a variety of CPUs? Then again, Android only runs ARM*... so why the hell is anyone bothering with JIT?

*There exists an unofficial x86 port of Android, but it can't run very much at all.

@OnlineCop

Allegro 5 already has over 100 examples. Basically every Allegro 5 feature is covered by one or more examples. So I think that's plenty, the problem there is to get people to actually try and read them.

We could use a few more impressive demo games though. The current demos are OK but not really give much of a "wow!" effect. What could be also interesting would be, next to the kit idea, an Allegro 5 "blank slate" that already has the basics written, and which beginners can use to start their own game off.

I also guess the step up from the examples to the demo games might be too big. So perhaps, a set of "tutorial demos" that improve the same game step by step would be a nice idea?

Whether A4, or A5, I've almost never read examples except for a quick glance. I'd much prefer a few, well-written tutorials. And IIRC, those already exist.

If we're talking about "Allegro" as a brand, the biggest thing it actually needs is (relatively) high-profile games actually using it. For example, what was that one popular game with the jump/platforming lizard that emulated a gameboy screen?

I'm trying to grok the shader stuff, and the four examples provided don't seem nearly enough to keep my brain from overheating trying to figure it all out from scratch.

JIT compilation isn't just meant to be optimized for the machine hardware. You can do that already with static compilation using open source software (e.g., see the Gentoo project, which allows you to effectively recompile the entire OS for your specific hardware and software configuration).

I'd be lying if I said I understood how JIT can run faster than native code, but maybe start here.

In any case, I don't think too many of the Allegro developers are Java programmers (at least, not by choice). I don't think we have the personnel to propose a purely Java-based Android implementation (if that's even feasible).

What's the point if the user code is still in C/C++/compiled language? Making the user write Java would make the entire port pointless.

Also, ^ this.

That hasn't been true for a while. Intel has ported to the newer Atoms. It's as official as the ARM port. I think there are also RISC ports

But yeah, you want the native code to get around the slow ass jvm. the newer one coming is supposed to be better because all apps are pre-jit'ed, where as dalvik is runtime jit-ed. It's still not going to be quite as speedy as native code.

But also, what they said. the idea is to make the porting as simple as possible.

This thread has made me want to install Allegro GIT alongside the latest 5.1 release. Are there any caveats?

You will probably have a hard time maintaining both. You're probably better off just installing the latest Git. That way it forces you to use it, and if you have any problems you can report them and help improve Allegro.

You could manage an alternative copy, but you would have to take care installing it and use environment settings to keep things straight. It's easier to just maintain one.

Which OS?

Eh, you persuaded me. I'll go Git-only. It'll be nice to finally be able to submit patches.

... Suddenly I find myself questioning the reason for the 5.odd branch's existence in the first place. Allegro may be spreading itself thin with 4.4, 5.even, 5.odd, and Git.

Odd and even are purely names, although I'm all for implementing the 4.X API as some sort of addon and just dropping the actual 4.x branches. I mean, once that is done properly, there's no real need to continue to support 4.X.

Wasn't there an addon made by somebody?

Maintenance releases.

When we all move to 48-bit color, for example, who knows what Allegro 4 is going to do.

Git isn't a branch. Git is the repository for the whole of Allegro 5, which has branches for 5.0 and 5.1 releases, which is where the actual release builds come from (at whatever arbitrary point where the developers feel there have been enough changes and they're stable enough to warrant a new official release). Working directly from Git is essentially using the code in development before it's really ready for release.

You'll probably want to fetch, fast-forward, and rebuild Allegro every day you use it to keep getting fixes and new features. Unless you yourself are working on changes in which case you're better off staying where you are unless you know through communication that what you're doing will need to be done differently with changes from upstream.

There are fundamental differences to the internals of Allegro 5 and Allegro 4 so even though somebody did write an interface layer there's no way it will perform exactly the same as Allegro 4 did. Some things may be better, but others will be worse, and I bet several things just aren't even implemented (e.g., the sound layer stuff people are complaining about).

I don't really know what the big deal is about supporting 4.x. Are we seriously getting regular bug reports to that branch still? Maybe 4.4 because it was released around the same time as 5.0, IIRC... Sort of silly on the developers' part.

What, exactly is the point of 48-bit color? I can't tell 24-bit color apart without a hex editor! 48-bit color had better support 3D!

Chicks dig guys with bulky legacy systems.

Srsly, though... I got a lot of contracts running, plus undergrad to finish, and student orgs to run. I have not, however forgotten the community that had to deal with my shit when I was first learning how to program. I also haven't forgotten about my first game library: Allegro 4.2! As soon as my load lightens, I'll offer some help and some free beer.

{"name":"SEnndPs.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/8\/f857a6d2f4c7c1a49f9fc6c5f57e28aa.png","w":1280,"h":1280,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/8\/f857a6d2f4c7c1a49f9fc6c5f57e28aa"}

http://i.imgur.com/SEnndPs.png

Can you see circular banding near the dark area? That's why. You don't need to be able to tell a single color apart next to each other to be able to see a smoother transition on gradients.

There's literally no good reason not to increase the color depth. It's like asking why go from 100 Ethernet to gigabit.

It's also a solution to this, the color space problem:

http://en.wikipedia.org/wiki/RGB_color_model#mediaviewer/File:CIExy1931_sRGB_gamut_D65.png

The grey background is all of the color space our eyes are capable of perceiving. The triangle is what RGB actually gets you.

The fact that red + green + blue doesn't actually yield all colors is the reason gold doesn't look anything like gold on a TV.

Floating-point colors also allow us to mathematically demonstrate super bright white (such as looking into the sun and over-saturating your vision), and perfect black.

There's a good reason why HDMI already supports deep color spaces (as well as Windows 7 onward) and that SGI/Mac workstations were running 30-bit (not 24-bit padded) color back in the 90's.

Floating point color also allows us to do modifications to images with a guard band. That means we can increase/decrease, or stretch image intensity and not have that be a lossy operation. We can undo it. We can have a shader play with it in real-time. Even if we can't "see" 48-bit color, it allows us to transform images inside it in the same way that 24-bit audio allows use to master soundtracks without damaging them before we print it to the final consumer copy.

[edit] Why is the preview black. Everyone viewing must not have a high enough color depth to see it!

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.

The only thing i miss from Allegro 4 is 256 color display mode and its fast memory bitmaps. Otherwise i find Allegro 5 vastly superior to its predecessor.
Unfortunately my programming skills are not that good to add what i miss, nor do i know if its even a viable option to add 256 color display mode on hardware we have today.

RIP Allegro 4, we will never forget you.
All hail to Allegro 5.

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

256 color could probably be done with a shader?

Yes, ex_palette is 256-color mode for example.

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

It's actually super easy once you play around with it for simple stuff (read: NOT bump mapping). You just can't debug as easily since we're talking about millions of bytes floating around inside the GPU, far away from main memory.

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.

To lower the barrier, as has been suggested before iirc, it might be a good idea to have a downloadable standalone virtual machine image.

That image should probably run some Linux variant (Ubuntu?) and have Allegro5 alongside an IDE already pre-installed, so people can fire up the VM and just start writing code.

Also, the VM should include a project template and ideally, that template should have multiple compilation targets pre-configured for cross-compilation to different platforms.

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.

There's a reason for that. Android is linux, and the SDK and especially the NDK was made to use on linux. Trying to get it all to work on windows is like pulling teeth.

A wild virtual machine appeared!

It used boot Linux!

It is super-effective!

A virtual machine image sounds absurd to me. I hate that idea. The Perl Catalyst framework offers that, IIRC, and it completely turned me off. It shouldn't be that fucking hard to get up and running that it's easier for you to load a virtual operating system that has already had the components installed for you.

Computers are wondrous things! They follow instructions exactly! Automatically! If we can tell a human how to do something, we can tell a computer how to do something even more precisely! It should not be extreme for us to provide a simple installer package for Windows.

Let's face it, that is the main barrier. The developers care less about Windows than ever before. It has become the red-headed step-child. Which would be fine if it wasn't also the predominant operating system used by beginners. Having an easy installation in Windows is important for the quantified measure of success for the project.

Fuck a virtual machine because a beginner probably won't know how to use Linux so the learning curve would still be too much to just start coding. You need an up-to-date Windows installer package. Something that will install the library and its dependencies, perhaps with the option of also installing a bundled copy of MSYS, and perhaps even a graphical IDE like Code::Blocks.

* Allegro Library *
[X] Allegro 5 library run-time (plus dependencies) (Required)
    (*) Monolithic (includes all the addons in one library)
    ( ) Separate addons
[*] Allegro 5 development files (e.g., header files) (Optional)
[*] Allegro 5 examples (source and executables) (Optional)
[*] Allegro 5 documentation (HTML format) (Optional)

* Bundled Development Environment *
[*] MinGW vX.Y.Z (GNU environment sufficient for development) (Optional)
[*] Makefile template (Optional)

* Bundled Graphical Development Environment *
[ ] Code::Blocks vX.Y.Z (integrated development environment) (Optional)
[ ] Code::Blocks project template (Optional)

Protip: That is a LOT of work to accomplish, let alone maintain, but if you really want to make Allegro accessible to n00bs that is the way to do it.

I remember when I was still in college and Sam introduced me to this community I had no idea how to install the library. He basically had to walk me through it. We didn't learn any of those skills in college, and learning by searching the forums, etc., is a lot of work. That is not a friendly invitation. Maybe we could get away with it back then because it wasn't overly easy to just pick up anything, but these days there are much more friendly options so if you expect to make Allegro friendly you need to match them.

For Android development, I say fuck it, in that case people should be booting into Linux. The Android platform is a Linux-based platform. They are already targeting Linux. They should not have a problem with booting into Linux. It's no different for iOS: AFAIK, you need to have a Mac (or a Hashintosh) to develop for that.

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.

You mean, my current development environment? Wherein I run Windows on the host for compatibility with 99% of all software and fastest drivers, and Linux in a VM for access to some of the best development tools ever created? Your loss.

So it's okay to not know how to install it in windows, but installing it in Linux is absurd?

Enjoy your metro interface.

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.

Them's fighting words...

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

I install VM's just for one game at a time.

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.

No one* uses the library that doesn't have lots of tutorials.

Tutorials = usage.

*comparatively

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.

Is the to-do-list on the Wiki for 5.2 an "official" one reflecting the thoughts of the core devs? Ie. is there a master-plan of what 5.2 should look like?
Maybe more people would be willing to help out if tasks were more clearly stated?
For example, the todo-list mentions multiple instances of API-reviewing, which seems to be a bit vague to me, I mean, it's not a specific task.

It shouldn't be too difficult to get more people to test all the examples on their available systems.

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.

This could be a bit of a problem, or just suicide.

{"name":"os-2014-02.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/8\/2855c88eba610d3cf9a267dbf9f10a8e.png","w":853,"h":640,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/8\/2855c88eba610d3cf9a267dbf9f10a8e"}

Now do the same graph titled:

"Allegro Contributor Operating System Market Share"

If Allegro was sold, or had a subscription model, the devs would tolerate Windows more to make the $$$.

If I had a product that used allegro, I'd find time to work on the windows port

It's all about itch scratching.

If we all take fewer showers, there'll be a lot more itch to scratch .

Programmers bathe?

I take a shower every month, whether I need it or not!

I'm not sure what that graph represents, but the sales are shifting drastically towards mobile and tablets^[1] where Android and iOS are the only real players^[2], and Windows is being hedged out.

How many toolchains do we support on Linux? One, GCC. How many toolchains on Mac? One, whatever the hell they use (GCC based, probably). Adroid? One, GCC based. iOS? One. WinTel? Like 5 or more!

Windows is not that important. The focus should be on Android and iOS, where indie games are livelier than ever.

I think Windows and Android are both imporant, since for a library like Allegro, portability is a key feature. And that's why we need people to help out with those platforms in the first place. So I'd encourage everyone here to make less complaints, and more contributions. If you want better Windows or Android support then please help us out.

Who said developers have to work in the operating system they target? Has cross-compiling been entirely forgotten, or is everyone writing C++ on their Android phones?

Any open source and give-away-for-free software written by volunteers is going to be driven by the need of those developers. Why should it be any other way?

The real question isn't why do the existing developers not work on Windows as much, but why don't developers who use Windows care about having a library like Allegro?

Probably because they're afraid of losing performance, and want to use DirectX directly. I suppose I should be less vehement, and try to remember that on Windows there's no point in anyone profiling their code. The OS will waste whatever resources that you don't waste.

Or Unity.

But what if it's maxing out the CPU and still only gets 10FPS?

Then your computer needs upgraded; there's no way it could be the programmer's fault!

@Chris, of course I try to port as much as I can with a Windows VM. Unfortunately windows tends to be is much harder to program for, so there I could use all the help I can get.

It's as Matt says. We need more capable Windows developers who use Allegro to also contribute to it, or at least to test it and make tutorials, etc. I guess the problem is that windows developers care less about portability...

Because novice developers don't go for C/C++ much any more (now that we have RPG Maker, Unity, Flash and HTML5) and a lot of experienced developers prefer to roll their own libraries, because they actually prefer writing libraries to creating games (do I know a few of such people...)

Let's face it, Allegro is mostly for old-time guard like me who just can't let go of C++.

As for driving new developers to Allegro, I think Allegro need a "killer product" kind of game that's made with it. The one that will make people ask "hey, what did they use to make it?!". We have some nice commercial games, but nothing of that class.

What are Allegro poster-boys, what could be listed with pride on "made with Allegro" page? CEGUI, for example, has the first Torchlight, and even though, by all accounts, it's not a very good GUI library, being used for a very successful commercial game counts for something (not to mention that during game's development, developers almost certainly fixed some bugs and added features to it because they needed it).

For Allegro, I'd probably nominate the first Eador game, but unfortunately it's relatively little-know outside of Russia even though it became successful enough to spawn a sequel that was sold on Steam (but wasn't made with Allegro)! Also unfortunately, that sequel sucked, but that's beside the point

So, while streamlining API and installation and expanding documentation and tutorials are all very important, someone should really go and make A GREAT GAME with Allegro. Before you ask, yes, I'd like to do that myself, but so far, I hadn't had a lot of success

Well, I do all my stuff with Allegro, so when one of my killer products come out, all of our problems will be solved!

I use a portable version of A5, is just Orwell DevCpp (portable) and A5 devpack. It would be nice to have an official A5 portable bundled pack like this for starters without installations at all

DevKitPro has a bash script for linux and a Windows installer.

All those really do though, is download the latest stable and put everything in the proper folders. For APT-based platforms we could easily check for existing packages and install them if necessary. I'll try to remember to look at CrunchBang's first-run script; as they do something similar.

Windows is a bit more complicated; you might need to edit the path and we'd expect the user to know which compiler they are using. Sadly, a lot of people (read n00bs) probably won't so they'll either install the wrong one or overload your mirrors by downloading A5 for every compiler on the market. I'm familiar with making installers, so I'd be willing to help with that.

Keep in mind, that making an installer just makes it so that more n00bish people can get started, which creates the aforementioned problem.

Thats what i am preaching since years.

Striker: then practise what you preach. We could use the help of a windows installer developer/maintainer.

Really? You want an installer in broken english?

Yes.

Hell yes, I want an installer in broken English. Didn't you make that huge tutorial last year? It was good. I used it.

Even if the installer starts in broken english, that doesn't mean other people can't help translate it

And what kind of installer do you want? I have seen ready made installers, if you know exactly which files to put where it seems to be a work of a few hours...

I've seen Inno Setup mentioned here several times, I'd bet the hard part would be sorting out what directories go where for different windows versions.

Yeah. If possible you'd want to try and find the users compiler or let them select it... Or if its an all in one side setup then you'd just install it all.

The most convenient "installer" is a .zip imho, something you just extract wherever you want and then run it from there. All tools (compiler/ide/project templates/etc.) inside that zip will have to use relative paths in all their configuration files.

Run what? It's a zip.

And most newbies would disagree. An installer is by far simpler. double click, and wham, it installs the headers and libs to the proper compiler paths, or maybe installs to some shared dir, and adds those paths to the compiler's/IDE's global paths.

I agree with Dennis.

I'm still not sure how extracting the dlls and headers to a random directory, is better than an installer figuring things out.

What they're really getting at is that Windows installers are evil bastards that make a mess of your file system and registry and don't clean up after themselves properly. What's better about a run-in-place tree is that the user can easily get rid of it if they don't like it.

Albeit, zip files tend to not have top-level directories, which is just evil Windows n00b shit. But by all means include one and it's fine. If the package includes a full MinGW environment, etc., then it's not terrible. However, the problem with Windows is that there is no good command shell, and by extension no good command shell languages to script things in... You end up making users launch goddamn ugly .bat or .cmd files with rudimentary functionality fit only for the 1940s. I digress.

Another advantage to the tree distribution method is that the user doesn't need elevated privileges on the computer to use the software.

If somebody trustworth wants to make a loose archive available of binaries for Allegro and its dependencies, as well as the header files, myself (and anyone else that wants to) can try to fool around with it and fill in the blanks for a suitable package... I imagine the hardest part will be manually assembling a minimal set of MinGW packages needed... Alternatively, attempting to integrate the MinGW installer into your own reliably (if you go with the GUI installer route).

I will personally only bother testing Windows 7 most likely. XP is old and unsupported, Vista is basically Windows 7, and I don't want anything to do with Windows 8. Still, I imagine if it works in Windows 7 then it'll probably work in Vista and Windows 8 with a little care...

Append:

I see no reason why you can't compromise and bundle an installer program that will embed a bundled run-in-place tree into the operating system for the user.

* allegro-5.1_git-abcdef.zip/
`-* allegro-5.1_git-abcdef/
  `-* INSTALL
  `-* README
  `-* bin/
  `-* env.cmd
  `-* include/
  `-* lib/
  `-* setup.exe

That has some possibilities. Gives you options. I don't like a run in place config or project file as that limits the user to one project...they'd then have the same problem when starting a different project... An installer is supposed to make it so the ide or compiler is setup for use. Imo.

For just Allegro itself, the best thing would be to maintain an msys2 package.

But I think the main point of an installer is that it comes with an IDE, which is set up to compile/run and has syntax highlighting and documentation and so on already setup. So basically, run the installer, and now the start menu has an icon which opens the IDE. And inside the IDE you find a simple example program and when you click the run button it compiles and runs it.

Any in-between solutions where just Allegro binaries are installed but you still have to figure out how to use it from your editor/IDE are less desirable I think. Someone who already knows how to use MSVC should be able to figure out how to use Michal's binaries already.

Not if the project template(s) are configured with relative paths to all tools/libs/includes/etc.

e.g. (expanding bambams example):

* allegro-5.1_git-abcdef.zip/
`-* allegro-5.1_git-abcdef/
  `-* INSTALL
  `-* README
  `-* bin/
  `-* env.cmd
  `-* include/
  `-* lib/
  `-* projects/
      `-* templateA5project/
          `-* templateConfig(*)
  `-* setup.exe

(*)templateConfig is represantative for whatever configuration file(s) are necessary for the toolchain used in the bundle.

Inside those files, relative paths must be used for the toolchain(whatever compiler/IDE ends up being supplied in the package) to find stuff, e.g. ../../bin/ , ../../include/, ../../lib/.

Starting a new (A5)project in an in-place structure like that is straightforward and easy, just copy the template folder, rename the copy, open it and start hacking.

Keep in mind, this package would be meant for complete newbie users. Experts will always know/have better options for their own stuff and a package like the one proposed does not and should not keep in mind the special needs of experts who use their own already installed tools (they can just grab the source and compile/setup everything themselves).

There's a big gap between a complete newbie and an expert who can set everything up easily... it's fine to have a newbie project, but there should be a simple package for 'experts' as well.

Imagine you've just heard of Allegro on a forum or something and you want to check it out. You land on http://alleg.sourceforge.net/ and then... I think it's missing something as an experience.

Re. packages - I've used the Homebrew package for OS X, and the .deb for Ubuntu, both work very nicely. I don't use Msys/MingW but if the MSYS2 package works like the others then that will be a big step forward. Visual Studio users have NuGet packages, I have no experience with those, do people even use VC for Allegro these days?

Re. installers. In the past I have used WiX and I found it very easy and robust. WiX is (sort of) blessed by Microsoft so I'm sure it does the right thing w.r.t not messing up the registry etc etc.

Pete

Sadly, quite a few do.

I found a good default installation folder on all Windows, is in the My Documents folder, the environment variable HOMEPATH points to it. You can also simply set the root directory like C:\ as the default and let them choose. I prefer the UserProfile folder because it is easier for most people to find as there is usually an icon that points to it on your desktop. I used to then use appdata to store the program save files but that is a big headache when people need to find everything so now it ALL goes into the game folder in UserProfile\MyGame by default (see script below), plus I like to keep everything together so it can be put on a thumbdrive etc.
You could also provide it in a ZIP as well as an install, I see no reason why one has to be preferred over the other.

Something along this line is good. I also prefer InnoSetup.

For my Deluxe Pacman 1 game, this is the Inno Setup script I use to create an install...

; -- Deluxe Pacman.iss --
;   A simple script for now, I will expand on it later.

[Setup]
UsePreviousAppDir=no
;changed the next two from yes to no
DisableStartupPrompt=no
DisableDirPage=no
AppName=Deluxe Pacman
AppVerName=Deluxe Pacman version 1.98c
AppVersion=1.98c
OutputBaseFilename=Deluxe_Pacman_setup
OutputDir=Setup
DefaultDirName={%userprofile}\Deluxe Pacman
DefaultGroupName=Deluxe Pacman
SetupIconFile=Deluxe_Pacman.ico

[Files]
Source: "bin\Deluxe_Pacman.exe"; DestDir: "{app}"
Source: "bin\PACEdit.exe"; DestDir: "{app}"
Source: "bin\Deluxe_Pacman.dat"; DestDir: "{app}"
Source: "bin\keyboard.dat"; DestDir: "{app}"
Source: "bin\language.dat"; DestDir: "{app}"
Source: "docs\license.txt"; DestDir: "{app}\docs"; Flags: isreadme
Source: "docs\manual.txt"; DestDir: "{app}\docs"
Source: "docs\troubleshooting.txt"; DestDir: "{app}\docs"
Source: "docs\journal.txt"; DestDir: "{app}\docs"
Source: "docs\old log.txt"; DestDir: "{app}\docs"

[Icons]
Name: "{group}\Deluxe Pacman"; Filename: "{app}\Deluxe_Pacman.exe"; WorkingDir: "{app}"
Name: "{group}\Level Editor"; Filename: "{app}\PACEdit.exe"; WorkingDir: "{app}"
Name: "{group}\Uninstall"; Filename: "{uninstallexe}"
Name: "{group}\Documentation\Manual"; Filename: "{app}\docs\manual.txt"
Name: "{group}\Documentation\Troubleshooting"; Filename: "{app}\docs\troubleshooting.txt"
Name: "{group}\Documentation\Journal"; Filename: "{app}\docs\journal.txt"
Name: "{group}\Documentation\Old Log"; Filename: "{app}\docs\old log.txt"
Name: "{group}\Documentation\Licence"; Filename: "{app}\docs\license.txt"
Name: "{group}\Deluxe Pacman website"; Filename: "http://home.cogeco.ca/~nroy15/games_index.html"
Name: "{userdesktop}\Deluxe Pacman"; Filename: "{app}\Deluxe_Pacman.exe"; WorkingDir: "{app}"

Does MinGW still barf on embedded spaces?

I've had no problems with this, and have had no reports of problems (and this game has had several million downloads now). Tested it personally on Windows XP, Windows 7 and Windows 8.

The stuff you make never had that issue, but the compiler did. I haven't used it in a long time though (Vista and up uses c:\users\username by default, so that might be something to keep in mind) so I'm not sure if they fixed it or not. Depending on why it barfed, you can use quotes around your own paths.

Thats fine for installing a game. But not necessarily for installing development tools, libs or projects.

Nice to see people are thinking about how to actually make and installer or a fully-featured binary zip file!

I think on Windows we probably need both approaches, the installer for the total newbie, the zip file for the advanced user. And we also need an msys2 package, for the experts. The more options, the better.

The installers and zip file would be great on the allegro web page, with some recordings and text tutorials on how to use these install methods.

I kinda like the idea of the zip with the files bare, AND an included installer that'll point an IDE to those files, or copy them into the IDEs paths.

append: ooh. Or make it a simple project creator wizard. It will ask you where to save a new project, what IDE you're using (or cmake..), and save a project file to that directory, with the path to allegro pre-set in the project.

I like that far more than a monolithic automagic IDE detector installer.

My main point about my own installer script for my game is that it is very customizable and much more can be added to it fairly easily.

But when it comes to the library, I have to be honest, if you don't know where to put libs, headers etc... than, maybe you should take up another hobby.

There could be some help files included which gives some general tips on where to find the proper locations for various IDEs. But honestly, how much of this goes beyond what a library should be doing? Shouldn't one understand the basics of how to operate their IDE beforehand?

A lot of us old fogies will agree with you there nitehackr. But a lot of newer people will appreciate a simple way to check allegro out before spending a boat load of time on it.

Oh, and I did test this with Windows XP which still uses "MY DOCUMENTS" and I have no problem installing it and using it there. Trust me, I have definitely tested this extensively.

Oh yeah, I totally understand. Perhaps some text files, like visual_studio.txt, codeblocks.txt etc... with instructions on finding the proper locations. That would probably be easy enough to do if people didn't want to tackle trying to get an installer set up to do it. Though if an installer approach was used, it certainly would be unique in the library community and could set Allegro apart as being more friendly. (or as I said, use BOTH approaches)

Or what goes beyond my own skill, software you download where you select the package you need, and then it downloads and installs the appropriate libs, examples for you and creates some links.

I think SDL or SFML has a wizard/installer. I think it'd be pretty useful.

I really like the idea of a project creation wizard that just generates a project or cmake file depending on the IDE/Editor selected, and points the project files to the location where you put the allegro lib/include files. It has possibilities. It's not a super complex installer that has to know how to find installed IDEs, just has to have a template for a few IDE's project files, and modifies them slightly when generating.

I've been using mingw (through msys1 then msys2) with spaces in the path for many years and never hit a problem... however I guess only my own projects where in paths with spaces, not msys/mingw itself.

Maybe I was thinking of DJGPP with the spaces.

It depends. make tends to have issues with spaces, so does bash/sh? And I think I've heard of issues with MSVC installed in a path with spaces?

Oh, wow, the WiX installer is horribly user-unfriendly. That's not at all a good sign...

That's why I suggested NSIS. (http://nsis.sourceforge.net/Main_Page) It's been years since I last used it but it worked well then . NSIS is fuly scriptable and the installer generated has been ported to Linux so you can make an installer for cross compiled Windows software there too.

Edit : looks like there are CMake scripts to generate NSIS installers as well: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS