Here’s a tiny “post-mortem” on porting Freesynd to the latest Native Client SDK. This was about a days worth of tinkering and covers one of the most troublesome issues when moving a traditional application to a locked-down browser environment – mandatorily asynchronous file access, usually involving threading hilarity. All those blocking fopen()s won’t work here, matey.

This work was done on Windows, so it also covers the fiddles requires to get printf-debugging working and the joy of cygwin when working with naclports packages. If you want to just port a natty little SDL app without going near cygwin, a download of the patched SDL libraries pre-built for use in NaCl 0.5 is available from my space on GitHub - source available via naclports.

(more…)

Flash, Java, HTML5, WebGL, Mono, Unity… for the game developers out there not programming in C/C++, it seems there are ever increasingly powerful ways to write-once and deploy-everywhere. I’ve been playing Project Zomboid recently – a charming 2D zombie survival RPG, written in Java and thus playable in a web browser on any reasonably capable platform. It’s an approach used to great effect by the wonderfully popular Minecraft, offering players a near zero-wait-time, no-installation path to playing. This kind of low barrier to engagement is increasingly more essential as users’ expectations rise and attention-spans fall; plus, as an indie developer, you get your game infront of as many players as possible without having to worry about porting to a handful of different OSes yourself.

So what do us suckers still using lower-level languages get to play with? Google offer Native Client (NaCl), a project that aims to offer secure execution of ‘universal’ executables atop a browser process. The browser becomes the “OS” (quite literally, in the case of ChromeOS), providing key system services, abstracting away platform-specifics yet allowing near-native runtime performance. Compile once, run on many, you don’t have to learn JavaScript. That’s the theory, at least. Does it work?

Well, yes it does. In fact it’s pretty damn slick.

Browser game portability meets C/C++ in an <embed> tag.

A recent distraction has been Clang/LLVM, the compiler infrastructure and C/ObjC/C++ front-end that powers many of the fancy new features of Apple’s XCode 4, as well as being the first real potential successor to the almighty GCC toolchain.

One of Clang’s many redeeming features (for me) is that it can be compiled effortlessly on Windows, in about 20 minutes, into a single monolithic executable. A well-written, customizable, hackable, production-class C++ compiler checked out and debuggable under half an hour? Sign me up.

To help try it out on existing projects, I’ve put together ClangVSx – an add-in for Visual Studio 2010 that emulates the VC build pipeline, swapping in Clang to compile C/C++ code on the fly, translating project settings as it goes. It also offers context-menu options in the code window for sending code to the Clang static analyser, as well as viewing disassembly or preprocessor output (I always liked being able to do that in CodeWarrior)

The vanilla check-out of Clang requires some patches to play nicely with the MSVC linker and not freak out when you show it <windows.h>. I’ll post up my own set of patches to the GitHub page, should they not find their way into the master codeline. Support for various Microsoft-specific extensions and keywords is patchy and occasionally things will be silently ignored, so tread carefully – I was worried to find an old DX9 graphics demo produced a black screen after being fed through ClangVSx, before finding that Clang was ignoring all the inline assembly, resulting in no geometry being generated. Doops.

MSVC 10 vs Clang 3 in smallpt, 256 samples/pixel. Clang is much faster - suspiciously so, at 22 seconds quicker in Release / -O3, but has a strange intersection artefact at the top edge. More investigation required.

Still, there is fun to be had, especially if you like hacking up compilers without having to revert to makefiles.