I missed the Monday with a weekly update, didn’t I? Also, most of the rest of the week. Not that I’m really on a tight schedule here, since I guess I have about two regular readers. But it’ a slippery slope, which ends with only writing to this blog two times a year, and I’m hoping to avoid it. So, here’s the latest news.

We’ve made some more progress on UI, and now have a final variant. I’m now waiting for Oleg to create a texture atlas out of it, so I can finally begin programming.

Since there wasn’t much to do on coding front last week, I concentrated on two thing: making Return of Dr Destructo easier to compile and checking out a new feature of Emscripten called Asyncify.

The first endeavour went very well. I reorganized project’s directory structure to be more convenient for cross-platform development, and less “Visual Studio’s pig sty”. After that, it become possible to create a CMake project and get rid of old Visual Studio solutions and very outdated Linux makefile. Also, I added sources of Lua, Luabind and TinxXML to be built as a part of project. This is a bit controversial decision in terms of open-source development, because now you have to build them even if you already have them installed on your system, and you can’t easily substitute, say, a different fork of Luabind (of which there are several) instead of the one I use. But it makes it much easier for ME to build my project on different systems, so I decided to go with it. Now, Return of Dr. Destructo needs only one external dependency, Allegro. Mind you, it’s a huge one: Allegro itself depends on a score of other libraries, some of them standard, and some not. But there is nothing to be done here: I can provide Windows Allegro build along with my code, but I can’t do this for all the other platforms, so I won’t.

On the subject of CMake, I should say thay even though I like it far, FAR more than plain old unix makefiles or, god forbid, autotools, it’s still sometimes a pain. I know that many people dislike CMake because of its syntax, which leaves a lot of margin for errors, and staggering amount of commands, which make it seem bloated. But so far, I haven’t seen a better alternative. The only real problem I have with it, is that it’s quite hard to add a new generator to support a new type of project, even if it’s based on the old one. There is no scripting or templating, everything is in code.

On the bright side, CMake already support a great number of different project types. There is even a generator for NVidia NSight Tegra projects, which allows Android development in Visual Studio. I’m awaiting that one eagerly. The other Visual Studio-based generator, unfortunately, isn’t there: the one for Emscripten’s vs-tool. But I think that vs-android (on which NSight is based) and vs-tool should be similar enough that one should be add support for vs-tool based on changes made for vs-android.

So, anyway, I now have a CMake project for Return of Dr. Destructo. I have already used it to create a Visual Studio project and Linux makefile, which means I now (again) have Linux build! For some challenge, I used old CentOS 5 on VirtualBox to build it, and I’m hoping to make it possible to run pre-built binaries of my game to run on most modern Linux distributions. I’m not there yet, so there will be more reports on this theme.

As for Emscripten, last week’s effort was a continuation of my project to port Allegro to JavaScript using Mozilla’s cross-compiler. In build 1.22.0, Mozilla introduced a nifty new feature called Asyncify, which, in theory, should allow C++ programmer to make less changes to existing code, and still have it work in browser. As you may, or may not remember, one of the main problems with JavaScript, is you can’t have a endless loop in your program, or it will freeze the browser. You should draw your frame, calculate your logic, and then pass control back to browser. This made Allegro Emscripten port somewhat less useful than I expected, because it meant that your old games probably required too much change to be runnable in browser. Asyncify, however, provided some hope: it allowed to define a set of functions, which would pass control to browser implicitly. So when you call sleep( mesc ) in your program, it would actually let browser do its stuff for ‘msec’ milliseconds, and then return from that call back to your code, exactly where it left off.

Sounds good in theory. Unfortunately, Asyncify support in 1.22.0 was completely broken. The compiler simply generated broken JavaScript when you passed ‘-s ASYNCIFY=1’ to it, because there was one undefined variable, ‘___async_retval’. It wasn’t even used for anything, only stored in one object, but the file refused to run. You could replace it in generated file with something defined, and it would work then, but such workaround isn’t pleasant.

So, I switched to ‘master’ branch of Emscripten’s git, and tried the latest compiler. I was able to compile a simple test without any problems, and it worked just as expected! It was nice to see a simple looped Hello World running without any need for emscripten_set_main_loop. However, when I tried to compile Allegro’s skater game with the same arguments, the compiler simply crashed. Since then, I’ve tried this and that, but nothing helped. On Emscripten’s mailing list, it was discovered that such crash happens and an Asyncified functio is called from try/catch block. However, both Skater and Allegro itself are a strictly C code, without any exceptions. Still, I’m now waiting for a fix to this bug to be merged into ‘master’. Maybe my problem would go away then. However, if it won’t, then I’m in troubles, because I’ll need to provide a simplified example of code on which compiler crashes, but the problem seems to be with Allegro library. Compiler crashes whenever I link it. And I can see no way to simplify THAT.