Gaming Your Way

May contain nuts.

Lead to gold

So I'm a little behind the times with this post, but to be fair I've had other things on.

Adobe have released Alchemy, which is a c/c++ compiler that outputs to Flash byte-code. Sweet.

I guess most people reading this remember when news of F10 broke and there was a video clip of Flash playing a native version of Quake that blew everyone anyway ( Better font rendering in FP10 ? Who gives a shit, that's Quake dude! ). At the time there were very few details about it, and it seemed to just disappear from view.

Well it's back and has a new poster boy, Doom. Runs a little dog rough for me when there are a couple of baddies on screen but hell, it's Doom ( I think it's the sign of a platforms maturity when someone ports Doom to it ).

How does this all work then ? Basically it relies on LLVM ( Low Level Virtual Machine ). This takes your source code, or "Front-end", currently  c/c++ but there's support coming for other languages, and compiles it down to a very simple byte-code.
With the byte-code in place you can then add your own "Back-end" which converts that code to run on your cpu of choice. Basically it's converting a high/mid-level language to an ultra low-level language ( RISC like ) which is then easier to port.

Because Flash uses a virtual machine model a back-end has been written to support that, so it goes c++ > RISC code > AVM2 byte-code and we're left with either a swc to include or a standalone swf ( Not sure how much use that'll be in real life though ).

My first thoughts ( Even after seeing the Quake demo ) was that anything written using this is going to run like poo. I mean as3 isn't the fastest language in the world. But there's a couple of reasons why it works and works well.

Firstly the LLVM compiler is really good. It optimises the pants out of the code, which reduces some of the percieved overhead.

Next up, the system works by allocating a byte-array in memory which the alchemy code uses for pointers / stacks etc. as well as storing it's own byte-code in there. In FP10 additional byte-codes have been added to the avm2 to deal with byte-arrays much quicker ( Allowing this to work at a good speed ), the haXe guys have done some amazingly quick work to figure these out.

Finally 'cause the alchemy converted code ( Is there a proper name for that yet ? Something catchy and slightly rude sounding ? ACC will do for now ) runs in it's own little byte-array "enclosure" it can access memory ( ie a location in it's own enclosure ) and call functions really quickly ( It's like coding in assembler on the old 8-bit machines ).

You lose performance when your action-script has to call / recieve data from the ACC ( Known as "
Marshaling" ), but such is life. If you plan so you pass as much code as possible outside of the mainloop then hopefully it shouldn't be too harsh.

Byte-Arrays are F9/F10's bitmap methods in terms of a new feature offering a huge leap forward in how we work with Flash. They offer up so much scope for some really cool stuff, from mod-players to things like

It's looking like it's possible to finally in-line byte-code thanks to the avm2 back-end for LLVM, which has a lot of possibilities for speed enhancements. Also take things like box2D, natively written in c++ ( That is currently being converted, although there have been some teething problems ), or a* pathfinders taking advantage of the much quicker memory access, or engines like Coco3D which could be ported over and solve issues in existing 3D engines, or self-modifying code, or things I can't even hope to think of yet.


Comments are closed