�ݺ�ߣ

Porting C++ based Apps to Flash
using FLASCC
Pavel Nakaznenko, 2013
p.nakaznenko@gmail.com

This presentation is about

Adobe Flash AlchemyFLASCC technology

Porting application to Flash with FLASCC

Problems I've faced

Adobe Flash

Cross-platform multimedia technology

Vast userbase, broad platforms coverage

Flash Player – standalone or plug-in

AVM2 – ES4 based JIT VM

AVM2 executes SWF bytecode

Adobe Flash 11.4

3D Hardware acceleration

Shader support

Multi-threading

C++ to Flash – How?

Porting manually = very long and resource
demanding process

Converting logic code to AS3 (CodeGen) +
Flash Wrapper = very error prone

Other ways?

LLVM – low level virtual machine

RISC-like language independent instruction set
and type system

Link time optimization, Compile time
optimization

Plenty of back-ends: x86, x86_64, AMD64,
PowerPC, MIPS, partially ARM

Many front-ends: C++, ObjC, Fortran, Ada,
Haskell, Java, Python, Ruby, AS3, GLSL, D,
Rust and more is coming

Adobe FLASCC (Alchemy)

Compiling C++ code into low level virtual
machine (LLVM) bytecode

Performing LLVM compile- and link-time
optimization

Compiling LLVM bytecode into AVM2
bytecode

Processing resulting files with Flash
Compilation Pipeline as usual.

Porting to flash in 7 steps
1) Download FLASCC sdk
2) Follow ReadMe installation
instructions
3) Use tutorials to setup basic I/O,
threading and rendering
4) Create makefile
5) Use Scout to profile
6) Use GDB to debug
…
Profit!

FLASCC features at glance

GCC based toolset + Cygwin in redist

Some libs have been already ported: SDL, zlib, vorbis ogg, box2d,
libqren, Bullet, Lua, etc.
See Adobe website for details

Hardware accelerated 3D via Stage3D calls

GLS3D – OpenGL-like wrapper for Stage3D API

AGAL - HLSLGLSL like shading language

P-threads, OpenMP supported

GDB for debugging

Scout for code, memory, Stage3d profiling

Not as good as it looks

Very raw technology stack

Tools fall out with OutOfMemoryException when
trying to build debug version of big project (the size of
UE3).

One line of code change in .cpp = 15 minutes build for
big projects. Think carefully before you build!

Profiling tool wasn't working till the very end of
integration

Not as good as it looks – part two

Growing Pains – claimed functionality doesn't always
work

No AVM2 low-level multi-threading support

Significant overhead for threads and memory sharing

Still have to convert content yourself

Have to write a lot of wrappers (RHI, I/O, Net etc)

VFS
or speaking of wrappers

VFS – Virtual File System, unified way to load
files and stay POSIX compliant

Part of FLASCC sdk guidelines

Flash is not permited to perform arbitrary I/O

You decide how to populate it: embed data or
load run-time

FLASCC provides implementation for common
cases (Web storage, Local Shared Object,
Embedded storage)

ES2API
or speaking of wrappers pt. 2

Wraps Stage3D API around GLES1.0 API

Part of Adobe in-house codebase (not available
for public)

Still WIP

Adobe Flash Threading
Implementation Specifics

Back-end: Bytecode is compiled into separate blob, which runs
on new instance of AVM2 in the background.

Front-end C++ : POSIX compliant thread functionality
(pthreads)

Available atomic operations: __sync_*** family

Front-end AS3: Worker, Mutex, Condition classes
(flash.concurrent package)

The Flash Player runs on UI (Primordial) thread

Game code entry point could be reached two different ways:
startBackground and startAsync

Problems I've faced

Worker can not access Stage3d

Worker can not perform IO with filesystem, due to
sandbox restrictions

Entry point can not be called with startBackground
due to the bug with static object construction.

Memory sharing comes via messaging = have to
serialize your object and de-serialize it every time you
want to change the data

Memory copy and access impersonation are only
viable options

Problems I've faced – pt. 2

Start application with startAsync, spawn game thread in entry point
(workaround for startBackground problem)

Every call for an impersonation gives overhead of 16ms avg.

while (true); on UI thread locks the whole Flash Player

To impersonate call you have to wrap the function you would like to
be executed on behalf of another thread as
void* function(void *args);

Severe memory fragmentation due to small allocation and
Flash Player GC (Mark & Sweep)

Low memory limit – approx 600 Mb for app, 1.4Gb for Player
(Windows)

No memory page protection. This will work:
*((int*)0) = 100;

Debugging (general)

GDB support only for small-scale projects

No debugging possible for big codebase. So no
breakpoints, step-by-step, etc

Tons of inline_as3(“trace((new Error()).getStackTrace());n”);

Use your brain. Because any build takes at least
15 minutes.

Watch flash log with “tail” like programs, i.e.
“Baretail”

Debugging (rendering)

Flash Stage3D uses DirectX driver on Windows
platform

Stage3D API calls ≈ DirectX API calls

AGAL ≈ HLSL

Windows Standalone Flash Player is an
ordinary DirectX based application

Use PIX to debug rendering!

Profiling

Adobe Scout profiling tool

Requires -advanced-telemetry flag to be passed
to compiler (will be supported in later drops)

Python script is used to add telemetry flag.

Allows rendering, memory, calls, display lists
profiling.

Supports threads.

Sometimes may be used for debugging

Bonus links

http://www.adobe.com/devnet/games/articles/compiling-opengl-games.html

http://gaming.adobe.com/technologies/flascc/

http://blogs.adobe.com/flascc/

https://github.com/alexmac/alcexamples

https://github.com/alexmac/alcextra

https://github.com/adamcath/telemetry-utils

https://github.com/alexmac/

http://www.baremetalsoft.com/baretail/

�ݺ�ߣ

Porting C++ apps to FLASCC

More Related Content

Porting C++ apps to FLASCC