I’ve been looking long and hard for a solution to the problem of creating high-performance games that are broadly portable across desktop, mobile, and in-browser platforms. Adobe Flash looks to be the closest solution to what I want, but FlasCC falls far short of offering the performance benefits it promises.
Flash’s cross-platform support is impressive. Naturally Flash applications run in browsers, but in recent years Adobe’s AIR technology has made it possible to make native-looking desktop and mobile applications as well. Flash’s mobile support offers many surprisingly useful features, including native deployment to connected devices, a handy mobile device simulator, and Scout support for profiling Flash applications running on a device.
Most recently Adobe released FlasCC, which lets you compile C/C++ code and embed the result into a cross-platform Flash file. This, I was sure, would be the magic bullet that would enable me to write high-performance game features in C++, while crafting the overall game interface in the Adobe Flash editor and deploy the resulting application anywhere, easily.
Alas, I discover today after a day of toiling that FlasCC does not compile to native code (contra Google Chrome Native Client, for example). Instead, FlasCC compiles to ActionScript bytecode, which executes with horrifying sloth, especially on mobile platforms. The Box2D example that comes with FlasCC simulates 500 colliding physical bodies with reasonable speed on a desktop, but can only simulate around 20 bodies at the same speed on my iPhone. That’s what happens when you execute ActionScript bytecode on a mobile device.
Therefore, if you’re making a game with no real CPU burden (something like Simon, perhaps?), Adobe Flash and FlasCC offers a great way to create cross-platform games using either ActionScript or C/C++. But if you’re making a game that needs to do some real computations—run physics, for example, or serious AI—FlasCC is useless.
Adobe should consider enabling a “universal native” mode in FlasCC—a switch that would cause FlasCC to compile to one or more native architectures, as selected by the user, and bundle the result into an executable SWF (or SWC). Alternatively, FlasCC could output LLVM bytecode, then run a JIT optimizer and linker on the native system when the app is first executed. That first run would have a long startup delay, but for many applications that would be a small price to pay for native SWF execution performance across all supported platforms.
5 Comments
Your solution of a jit phase wouldn’t be allowed on an iOS device. Your best bet would be to compile down the c++ into a shared library for each device that Flash could use.
I understand the desire for a silver bullet but it is really unlikely to ever happen. Better would be to look at a framework like Unreal Engine or Unity and build separate executables for each platform.
Given the myriad if security issues that Flash has plagued the world with I hope very much that they never start executing binary code in the flash plugin. I have zero faith in them executing that safely and securely. It would be a nightmare. I should note I have little faith in anyone being successful in that. Only thing is if adobe attempts it they can push it out to millions and millions of computers.
It’s time for flashers to use c++
What particular reason(s) for this assertion are you thinking of?
FlasCC is what you want to run C++ code on the browser. But if you want to run C++ on mobile, what you really want is Air Native Extensions (ANE). While FlasCC technically works on mobile, it’s really not the right tool.
I have a C++ library that I run in the browser with FlasCC and on mobile with ANE and its fine.