Most of you will more than likely have heard about Alchemy by now, an Adobe project that allows C/C++ code to be cross-compiled to ActionScript. I was incredibly impressed to see an actual port of Doom running in the browser released into the wild just days after Alchemy hit labs.adobe.com.
I recently had the opportunity to do a quick interview with to the developer behind the Doom port. Its a fascinating read that I wanted to share with you.
Q. Can you introduce yourself and tell us a little bit about your background and how you got the idea to port Doom using Alchemy?
My name is Mike Welsh. I've been working for the past few years as a Flash developer for Newgrounds, where I spend a lot of time staying on top of new technology and developments in the Flash community. I also did some work for Castle Crashers. Doom is one of my favorite games, and id Software is nice enough to release the source. It was a good way for me to get familiar with Alchemy.
Q. When did you hear about Alchemy and how did you get started with it? I first heard about it from watching the sneak peak videos from Adobe MAX right on your site! Scott Petersen showed a very cool demo of Quake running inside the Flash Player. This was very impressive, but I remained skeptical. Was it actually cross-compiling C to ActionScript bytecode? Or was it just a trick to run native binary code? As more information was released, it became clear that it was compiling into AVM bytecode, and I was really intrigued. When Alchemy was initially released a few weeks ago, I downloaded it and plunked through the documentation. I figured that I'd use the Doom source to test it out.
Q. How long did it take you to get the Doom example cross-compiled from C/C++ to the Flash Player? It took about a week of hacking to get it going. It was thrilling to see the game slowly come to life. After I got Alchemy up and running, I spent a few hours ripping out all of Doom's OS-specific window and display code. Then, I could see Doom's debug output. It's pretty funny to see "DOOM is Shareware!!" in your trace window!
Some time later, I finally managed to get Doom's frame buffer to display inside Flash. Doom is 8-bit color, and I wasn't reading the palette data, so the display was in grayscale. At that point, the adrenaline kicked in, and I spent some late nights getting the palette, input, and sound rigged up.
The most frustrating part of the port was the most mundane: getting the preloader to work! It still baffles me that it's so difficult and poorly documented to get embedded assets and classes to work properly with a preloader.
Q. Are there any specific feature requests you have with regards to Alchemy or anything else planned to you would like to cross-compile? The main issues I've had with Alchemy are simply bugs and poor documentation. For example, Alchemy code currently doesn't work on PowerPC. This is all to be expected of a preview release, and Scott Petersen has said that these fixes are coming!
My big request isn't specific to Alchemy, but a general Flash request: more mouse control. Many people complained about the lack of mouse control in the Doom port, but it's still impossible to do correct Quake-style mouse control in Flash. This requires a way to "lock" the cursor to the Flash area in the browser. How many times have you been playing a web game, clicking madly, and accidentally clicked outside the window? I understand that there are usability and security concerns, but a ton of people would benefit from these features, so there has to be a solution!
To test the limits of Flash and Alchemy, I have been toying with the Quake 2 source code--who knows how far I'll get! A friend has also started a project to port the SDL library to Flash -- this is really exciting, because there are tons of apps and games that use SDL. They'd instantly be available to Flash!
Q. How do you see the future of Alchemy, will this become a common tool to use in Flash/Flex/AIR development or do you believe that ActionScript will remain the primary scripting language? Adobe seems to be pushing Alchemy as a means to port legacy libraries to Flash. Truthfully, I'm not sure if it will be widely used. Sure, it's nice to work off of an existing code base, and you might be able to get a library quickly running in Flash. Ideally, you'd make an AS3 wrapper around the Alchemy code so that you never need to know that it was cross-compiled. In the long run, though, it's probably much more clean, maintainable, and extensible to rewrite functionality straight into ActionScript by hand. Having to deal with an amalgam of C++ and AS in your project could get messy.
As far as performance benefits, you do get a bit of a performance boost from Alchemy. Flash 10 introduced some new AVM bytecodes for quickly reading and writing to ByteArrays, and Alchemy uses these extensively. Also, C code is very static and can be optimized well at compile-time. Alchemy is compiling to plain ActionScript bytecode, though, so it doesn't have any "special powers." It's subject to the same restrictions as standard ActionScript, and the Flash compiler should be able to make use of the same optimizations that Alchemy does. Ralph Hauwert and Joa Ebert have made good posts on this subject. Therefore, I don't see many people using Alchemy for performance reasons. Pixel Bender is probably better for number crunching.
Maybe I'm totally off-base, but I see a lot of people using Alchemy to port old games into Flash. Why? Because it's always fun to have classic games in your browser! In any case, it's a cool technology, and it'll be interesting to see how it gets used.
Thanks to Mike for taking the time to do this interview and I'm pretty sure we'll see many developers playing around with Alchemy over the holiday season!