Tag Archives: android

Floating Point in Haxe on Android

Posted on by tjkopena

haxeOne thing I discovered recently is that Haxe, via hxcpp, by default builds to a fairly old Android target platform. A consequence of this is that it uses software floating point emulation. But any Android device from ARM v7 on supports hardware floating point. Switching to this produces a dramatic speedup, assuming you’re ok with that requirement. To do so, use the HXCPP_ARMV7 option, something like so:

openfl build -DHXCPP_M64 -DHXCPP_ARMV7 android

The HXCPP_M64 flag is to build correctly on a 64bit machine; details here.

However, there’s apparently a bug somewhere in the hxcpp toolchain. Enabling the ARM v7 target adds a `-7` prefix to a variable denoting the target library extension (`.so`). Seemingly some part of the toolchain doesn’t use this extension variable, so you get a warning like this:

Error: Source path "export/android/obj/libApplicationMain.so" does not exist

NOTE that if you had previously built under the default architecture, the toolchain will blithely continue on using that old version and you’ll be left confused as to why none of your code updates are being applied. You have to delete that file or your Android build folder, typically export/android/.

I haven’t looked into how to really fix this problem, but it seems to be enough for now to simply not add that extension prefix. In your haxelib folder, edit hxcpp/3,0,2/build-tool/android-toolchain.xml and comment out this line:

<set name="ARCH" value ="-7" if="HXCPP_ARMV7" />

Everything should now build correctly and run speedier. Huzzah!

Haxe 3, OpenFL, Arch, Android

Posted on by tjkopena

haxeTom and I went through and installed Haxe 3 and OpenFL on our machines today.  OpenFL is the updated Haxe 3 version of NME.  These are a few notes, updating from my Haxe 2 comments, some of which are still applicable. All in all, the process seems smoother than it was for Haxe 2/NME on Arch… I’m excited!

Haxe

First install Neko out of the AUR:

sudo packer -S neko

Then Haxe 3:

sudo packer -S haxe

Note that you can do those two steps at once. If you receive an error about an incorrect Neko package version, it’s because the Haxe package doesn’t denote the version dependency. Running them separately as above will force Neko to be updated first, and then Haxe.

At this point you should setup haxelib:

haxelib setup

Tom sets the haxelib location to be in his home directory, which is most proper. I leave it in the default /usr/lib/haxe, for no good reason. In that case you need to modify the install directory to be owned by your user:

cd /usr/lib/haxe
sudo chown -R joe .

OpenFL

Next, install OpenFL following their instructions:

haxelib install openfl && haxelib run openfl setup

When it asks for sudo permission, it’s installing a simple script aliasing haxelib run openfl to just openfl, so you can skip it if you wish.

Now set HAXE_STD_PATH:

export HAXE_STD_PATH=/opt/haxe/std

After that you should be able to create and run a demo:

openfl create DisplayingABitmap
cd DisplayingABitmap
openfl test linux
openfl test flash
Success!

Success!

Android

Next, try to set up OpenFL’s Android support:

openfl setup android

That script will pull down the Android NDK, SDK, Apache Ant, and Java, but if you already have all that installed simply say no to each download request and enter the path manually.  You can then try to build a sample:

openfl create DisplayingABitmap
cd DisplayingABitmap
openfl test android

If you’re using a recent 64 bit android NDK, that will fail with a root cause of not finding g++:

sh: arm-linux-androideabi-g++: command not found

To begin with, in your haxelib directory, edit build-tool/BuildTool.hx. Specifically, the Linux parameter by line 1355 in the Android block should be altered from just the value linux-x86 to the following:

m64 ? "linux-x86_64" : "linux-x86"

The block will then look like:

      else if (defines.exists("android"))
      {
         defines.set("toolchain","android");
         defines.set("android","android");
         defines.set("BINDIR","Android");
         if (!defines.exists("ANDROID_HOST"))
         {
            if ( (new EReg("mac","i")).match(os) )
               defines.set("ANDROID_HOST","darwin-x86");
            else if ( (new EReg("window","i")).match(os) )
               defines.set("ANDROID_HOST","windows");
            else if ( (new EReg("linux","i")).match(os) )
              defines.set("ANDROID_HOST",
                          m64 ? "linux-x86_64" : "linux-x86");
            else
               throw "Unknown android host:" + os;
         }
      }

That last ANDROID_HOST setting is what matters; as shipped, it does not point to the 64 bit toolchain correctly.

Then in build-tool/android-toolchain.xml, edit the toolchain version to 4.6. Edit line 7 setting TOOLCHAIN_VERSION as follows:

<set name="TOOLCHAIN_VERSION" value="4.6" unless="TOOLCHAIN_VERSION" />

In build-tool/ then run:

haxe Compile.hxml

OpenFL, specifically openfl-tools, defaults to Android API 8. If you have that installed, you should then be able to build the OpenFL samples for Android. You will though need to stipulate 64 bit hxcpp:

openfl test -DHXCPP_M64 android

To change the target Android API, in your haxelib directory edit openfl-native/1,0,6/templates/android/template/build.xml and change the target property on line 7, e.g., from:

  <property name="target" value="android-::ANDROID_TARGET_SDK_VERSION::"/>

To:

  <property name="target" value="android-16"/>

OpenFL should then build, push, and run the target on your phone using this API version, stipulating the 64 bit toolchain as above. Hooray!

Success on my S3!

Success on my S3!