Sorry for late answers, everyone, I've been busy for a while.
EDIT: I'm researching this some more, and ya, it is kind of cool. You said games can't be ported as-is, what does that mean? What kind of changes are involved?
Most Allegro games are structured like that (simplified):
while( !exit )
In JS, you'll have to replace endless loop with a call to emscripten_set_main_loop, which will set it up so browser will call your frame function whenever it's going to draw a frame. The code, therefore, will look like this:
10 // if the last argument is 1, this call will not be finished until
11 // the game stops (via call to emscripten_cancel_main_loop), so the
12 // cleanup code after it won't be executed too early.
13 emscripten_set_main_loop( frame_func, 0, 1 );
If your game is set up in this way, it will be very easy to port it, only a small change required. But if you have multiple nested endless loops, like Cosmic Protector demo, for example, then you're in trouble. Such code would be very troublesome to port:
4 while( !exitMenu )
6 al_wait_next_event( &queue, &event );
13 // A lot of other nested stuff.
18 if ( doMenu() )
29 while( !exitGame )
Max, here's the console output when I run it on my laptop :
Oh, yes, indeed it can't initialize OpenGL. Windows laptops aren't known for good OpenGL support, unfortunately.
For the last few days, I've been busy with one task only: compiling FreeType for Esmcripten. This was the worst piece of experience with a combination of open-source software I've had in a long while. Anyway, I have a result. Namely, ex_ttf running in browser. Take your time to enjoy, I've sweated for it
If you want some details (and even if you don't), I'll oblige. What went wrong: everything. For one, FreeType is the only Allegro dependency I know that absolutely HAS to use ./configure and does not have even a 3rd-party CMake file (this saved me with Ogg/Vorbis and libpng).
You can't run ./configure script in Windows, of course, unless you use MinGW or cygwin. Unfortunately, they do not help in this case, because we're cross-compiling for a system that is unknown to ./configure (and therefore we can't easily specify it via --host=tiple). This leads to a problem whenever ./configure tries to compile a native executable and run it (for FreeType, there are around 3 such calls).
I had two distros installed in VirtualBox: Mint 12 and Mageia 2. Both quite old, from my previous attempts at compiling pet projects for Linux (successful, but ultimately abandoned). I've downloaded and compiled all necessary tools... And hit a brick wall. In both distros, clang compiler was broken! It could not find some gcc libraries (libgcc.a and some others), because it tried to use hard-coded paths or something like that. There were bugs filled in both distros' trackers, but they weren't conclusively resolved.
To cut the story short, I've deleted both VMs and installed one with KUbuntu. After that, it was only a matter of few hours to compile Clang with fastcomp support (which is needed for emscripten, but isn't in upstream Clang yet) and then finally compile FreeType.
So there you have my story of woe and troubles.
Game Jam I was porting Allegro for begins tomorrow, so I do not expect to have much free time to post new examples here or port features, or for anything, really, but I promise to be back after that with sources and a patch for GIT version of Allegro.