HaxeFlixel and OpenFL 8.x on a Raspberry Pi running Stretch

[ Deprecated ]

Good News,

With the release of HaxeFlixel 4.4.0 it now supports the new OpenFL 8.x.
And that means that it should now run on a Raspberry Pi as well.

So in this post I’ll show you what you need to do to get haxe/lime/openfl/haxeflixel Running and
I’ll talk a bit about what to expect from  haxeflixel/openFL running on a Raspberry Pi.

Let’s start by giving you the link to a gist I made to quickly get haxe and openfl running on a fresh Raspbian Stretch (or an up to date Jessie)

[update: with the latest lime version from github , the manual step is no longer necessary] 
Beware that there’s one manual step in this script! Read all about it below.

You should know that installing OpenFL on a Raspberry Pi is a bit less straightforward then installing it on other platforms.
Raspbian is a linux distribution but it has some (custom) libraries that are in different path then distributions like ubuntu and debian.
As a result having the Raspberry Pi as a target in ‘continuous integration tests’ on github will Fail testing.
So there’s no no automated builds for the Raspberry Pi and you will need to compile Lime yourself.

So let’s start compiling

All steps are in the (updated) gist

I’ll highlight some of them, but remember to look at the gist and not just type over the sections you see below!

The first thing to do is compile haxe 3.4.4 itself. I recommend building it from source.
You will need some dependencies for building haxe first.

Then download and install neko:
// there’s a newer version 2.2.0 but you need to compile that one from source.
// Don’t use the one in the apt repository though, it has been producing segmentation faults for me.

now you are ready to clone haxe from git and compile it:
// I will try and see if 3.4.7 works as well, soon

At this point you should be able to run haxelib and install openfl and some dependencies:

This will also install the latest version of Lime, but that version won’t work since that’s a regular linux version.
You will need to get Lime from Github and configure haxelib to use this version

Before you can build Lime you will  need to recompile HXCPP.
c++ is the only target you can use on the Raspberry Pi, and you will need to compile hxcpp to run on 32bit ARM

Now you’re almost ready to compile Lime.

But there is one MANUAL step that I haven’t been able to automate in the gist script.

With the latest version of lime on github, there is no more manual step.
After creating an sd-card with the last version of Jessie (the previous version of Raspbian)
I found that if you run all the updates with sudo apt-get update && sudo apt-get upgrade
you will get the renamed versions of the GLES libraries that now come by default on Stretch.
This means we don’t need a manual replace of the correct linker flags for these libraries.

With the latest version in git, rpi has now become a build target. (thanks Joshua!)
So you can compile and test an openfl app with

[end update]

Now you can compile Lime:

You should now be able to run openfl and make or compile a project!
And install haxeflixel the usual way.

To make compiling on the Raspberry Pi a bit more enjoyable I recommend that you enable the haxe compiler cache.
This way it won’t try and compile OpenFL everytime!
Do so by creating a ~/.hxcpp_config.xml with the following contents

I also have a Lime config file in ~/.lime/config.xml  ( not sure if this is still needed )
that I create in the gist installer file

That’s it. Now let’s talk about what you can expect from OpenFL on the Raspberry Pi.
It is important to know that on the Raspberry Pi the opengles context renders directly to screen instead of in a window.
At the moment the SDL library (that lime is using) will always create a rendersurface that’s the same size as your screen!
Changing width and height in project.xml will do NOTHING!
this is something I will look into when I have the time.

So what that means is that on a regular HD monitor it will try to render to the full 1920×1080.
Quickly bringing down the framerate to below 30fps on even a fairly simple demo using tilemaps.
At the moment the only way to render to some other dimensions is to change the screen resolution from outside your openfl app.
You can do this from the desktop ( if your running one) or from the commandline with the tvservice command.
This is a bit  complex because you will need to know which modes your monitor supports.
You will also have to reconfigure the framebuffer.
For my monitor this means I have to do the following from the commandline

This gets me an upscaled 640×480 screen.
But you don’t want an end-user having to do this, so we really should try and see if we can solve this in SDL.

Now if I run a simple OpenFL or HaxeFlixel demo on this resolution it reaches  60fps (or just below).
But there’s a couple of things that will quickly kill your fps:

  • Using vectors graphics: they will first be rendered in software by the Cairo library.
  • Using things like Nape (physics)
  • Multiple Tilemap layers
  • too many drawcalls

So It’s best to keep things as simple as possible on a Raspberry Pi.

But using the GPIO on the Pi you can easily make your own custom controllers!!! 🙂

I think it’s wonderful achievement..
So many thanks to everyone involved!