How OpenFL Works

OpenFL, as I shared earlier, combines years of development to bring you a fast and stable implementation of the industry-standard Flash development API, free and open-source, ready to provide a backbone for mobile, desktop and web projects.

How does it work? At first, it may seem to be a mystery, but I know that some of you (most of you?) like knowing how things are put together, so let’s dive into it.

Run script

OpenFL begins with a run script. The source is located here:

https://github.com/openfl/openfl/tree/master/script

When you execute “haxelib run openfl” (or run the “openfl” alias for the same command), this script is being executed.

It is similar to a simple boot loader. It is enough to run the full command-line tool script, or it can do some things we need internally during development, such as easily recompiling the command-line tools.

Command-line tools

The next step are the full command-line tools. This is handled under the “openfl-tools” project:

https://github.com/openfl/openfl-tools

By separating the tools into their own project, it means that the tools can be updated (or rolled back) independently from the framework. It also means the tools can be used, potentially, for more projects than just OpenFL. It might also make it simpler to work on the tools (if you are improving them) in isolation, leaving the rest of OpenFL in a stable, release version.

include.xml

When a project includes either an <include /> or a <haxelib /> tag, the tools also look for an “include.xml” in that target directory. If this file is found, the contents included with the user’s project. This gives the ability to automatically extend what <haxelib name=”openfl” /> means, for example. This is how OpenFL loads its additional libraries:

https://github.com/openfl/openfl/blob/master/include.xml

openfl-native

If you are targeting a native platform (Windows, Mac, Linux, iOS, Android, BlackBerry, webOS, Emscripten) then a library called “openfl-native” is included after “openfl.” The “openfl” library includes classes that act more like headers. They define the code completion for the API, but they do not have an implementation. “openfl-native” is the implementation for native targets.

The “include.xml” for “openfl-native” includes a few things:

https://github.com/openfl/openfl-native/blob/master/include.xml

It includes some native dependency libraries, as well as a template path.

Template paths

During the build process, the command-line tools look for (and populate) a few different kinds of template files. This based on the target platform, but in general they are Haxe compile scripts, a little of boot code for projects, as well as platform specifics, such as application manifests, meta-data, or in some cases, template projects (such as in Xcode)

These paths cascade, so multiple projects (including your own) can include a template path, in order to override the content of these files. All of these files are processed as Haxe templates, which allows variable expansion, such as “::WIN_WIDTH::” becoming “800” after the file is copied.

openfl-html5

If you are targeting HTML5, the “openfl-html5” project is included to provide an implementation of the API for HTML5. This code gets compiled to JavaScript.

Similar to “openfl-native”, the “openfl-html5” library also includes a template path, defining the “index.html” and other supporting files for running in the browser.

  • Pieter Bonne

    An interesting read.. thanks!

  • Dennis Adriansyah Ganda

    Hi, about the native platform , specifically android.
    can it build to x86 compatible code?

  • The native platform definitely can. We currently support x86 for Windows, Mac, Linux, iOS and BlackBerry. There did not used to be support for x86 (emulator or otherwise) for Android. Now that this has become standard, we may look at adding support, or I would be glad to help if someone was interested in implementing it themselves.

  • Dennis Adriansyah Ganda

    well I don’t know if there’s some processor specific code , but compiling C++ code to x86 for android is just a matter of changing some flag in Android.mk . but till now I can’t found where’s the make file on the build process or how haxe convert to android so I can’t really help here. 😐

  • All the compiling is handled by HXCPP, which has a helpful XML format to handle the compile process for all supported platforms. This has been much simpler than managing make, and trying to work across Windows, Mac and Linux consistently.

    You could experiment by modifying the “build-tool/android-toolchain.xml” file in HXCPP, but we may want to create a new toolchain file… it depends on whether it is for a completely different target (like a simulator on other platforms) or whether it is designed for device hardware, and just uses a slightly different flag.

  • Peter Reitsma

    Hi, really interesting. I am looking at using this to convert a large set of Flash games (animated puzzles) to HTML5/Js and later on, to iOs and Android.
    Could anybody comment on the possibilities to reuse assets from the original SWF files in the converted solution? Thanks ahead!

  • Kalevi

    How NME and OpenFL are related now? Thing are very unclear on this front. It may be obvious for someone who knows the code, but not for the end-users. Can you explain the relation between NME and OpenFL? Is OpenFL a rebranded NME? Are they dependent on each other? If yes, which part does what?

  • Is OpenFL a rebranded NME? -> Yes, for Haxe 3 and future Haxe releases.

  • I apologize for the confusion.

    NME used to be a native backend for Haxe projects. We expanded NME to include command-line tools, conveniences for clean and consistent code completion, we merged HTML5 support, and made many other improvements to target a single API across web, mobile and desktop platform targets. This is OpenFL now. NME is back to being a focused native backend. “openfl-native” uses the NME backend to target C++ and Neko. I would recommend using OpenFL. There has been continued effort to make it a stable, consistent, enjoyable API to target all platforms.

  • We have an older SWF library that worked quite well, but had a few limitations (most notably, it probably could not have worked on HTML5). There is new alpha-quality SWF library that does have support for HTML5 so far. I’m interested in advancing the library, and would be more than happy to help you if I can. Obviously there are other methods that work fine as well, such as spritesheet exporting 🙂

  • techs

    can you javascript to develop with openfl