Sorry for late answers, everyone, I've been busy for a while.

I wrote about this before, but I'll repeat it here: because of nature of JavaScript, you can't write endless loops.

Most Allegro games are structured like that (simplified):

main()
{
    init();
    while( !exit )
    {
         do_game_stuff();
    }
    cleanup();
}

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:

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:

Oh, yes, indeed it can't initialize OpenGL. Windows laptops aren't known for good OpenGL support, unfortunately.

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

The only way I found was to completely remove this checks from ./configure. As you may know, editing a ./configure script by hand is not a job for weak of heart. Anyway, I've done it and it didn't help me much. Now I had a Makefile, but it was a broken one. I suppose that was because it was generated by MinGW, but used by Emscripten's Python scripts, and they couldn't agree on slashes/backward slashes. Or something. At this point, I gave up on compiling FreeType on Windows and decided to try to compile in under Linux instead (here's a magic of JavaScript: I could easily use resulting file under Windows!).

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.

Nah, just let's put it into git, that's what it is for. We're very far away from 5.2 after all, at least a few years.

But only if the code is clean of course. Last thing we need is any more code where someone just made something work quickly instead of doing it properly and at least documenting what everything is for.

I'll get the patch ready anyway, so it could be applied now or later. I'll need to clean up code some, and fix build system. But I was hoping that maybe if it was in git other people would help to fix things I don't know how to fix (like usage of vertex arrays and newly-discovered absence of support for mipmap generation - which SHOULD be there, so there is a problem with detection of OpenGL extensions somewhere, I think). Of course, I'll defer to community judgement on the exact moment of inclusion into git.

Thanks!

I actually agree that this is not for 5.2. As far as I understand, the main focus for 5.2 was support for mobile platforms (especially Android), and there is no need to take away manpower from it (such as it is). Emscripten support certainly isn't ready for prime-time right now.

As for 5.2... Could anyone point me to List Of Things That Absolutely Have To Be Done For 5.2? I've checked out some bugs in tracker, but I'm not sure how to help.

I'm quite good at debugging things, no so good at architecture.

I rebooted to Mint, FF28 worked ok (video noticeably choppy but not irritating, sound choppy, 30'ish FPS, used about 20Mb memory), then I tried Chrome 34. Chrome took a minute to actually start downloading, then the download rate became rather sparse and erratic. I noticed both cores were just about maxed out, one was Chrome itself and the other didn't associate to a process so it was some kernel thing. Killing Chrome left one core still grinding, killing FF brought CPU down to normal. Then starting up Chrome to try it without FF running brought up a "He's dead, Jim" out of memory error even though the system monitor thing said I was only using ~1 of the 2 gigs memory I have. I tried it one more time in FF without Chrome and the CPU went back down to normal after closing the skater tab.

TL;DR Chrome ran out of memory.