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.
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.
1 2 3 4 5 6 7 |
sudo apt-get install -y libgc-dev libpcre3-dev sudo apt-get install -y build-essential git cmake sudo apt-get install -y libudev-dev sudo apt-get install -y ocaml ocaml-native-compilers libpcre-ocaml-dev sudo apt-get install -y sqlite3 libsqlite3-dev sudo apt-get install -y libmysqlclient-dev sudo apt-get install -y libasound2-dev |
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.
}
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
wget -c http://builds.openfl.org.s3-us-east-2.amazonaws.com/neko/neko-2.0.0-rpi.zip sudo mkdir -p /usr/lib/neko sudo rm -rf /usr/lib/neko/neko sudo rm -rf /usr/lib/neko/nekotools sudo unzip -o neko-2.0.0-rpi.zip -d /usr/lib/neko/ sudo cp -r /usr/lib/neko/bin/* /usr/lib/neko sudo rm -rf /usr/lib/neko/bin sudo rm -rf /usr/bin/neko sudo rm -rf /usr/bin/nekoc sudo rm -rf /usr/bin/nekotools sudo rm -rf /usr/lib/libneko.so sudo ln -s /usr/lib/neko/libneko.so /usr/lib/libneko.so sudo ln -s /usr/lib/neko/neko /usr/bin/neko sudo ln -s /usr/lib/neko/nekoc /usr/bin/nekoc sudo ln -s /usr/lib/neko/nekotools /usr/bin/nekotools rm neko-2.0.0-rpi.zip |
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
1 2 3 4 5 |
git clone --recursive https://github.com/HaxeFoundation/haxe -b 3.4.4 cd haxe make make tools sudo make install install_tools |
At this point you should be able to run haxelib and install openfl and some dependencies:
1 2 3 4 5 |
haxelib setup path/to/haxelib haxelib install format haxelib install hxcpp haxelib install openfl haxelib run openfl setup |
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
1 2 |
git clone --recursive https://github.com/openfl/lime haxelib dev lime lime |
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
1 2 |
lime rebuild hxcpp linux -rpi -v lime rebuild hxcpp linux -rpi -static -v |
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.
[update]
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
1 |
openfl test rpi |
[end update]
Now you can compile Lime:
1 2 |
lime rebuild tools rpi -v lime rebuild lime rpi -v |
You should now be able to run openfl and make or compile a project!
And install haxeflixel the usual way.
https://haxeflixel.com/documentation/install-haxeflixel/
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
1 2 3 4 5 6 7 8 9 |
<?xml version="1.0" encoding="utf-8"?> <xml> <section id="vars"> <set name="rpi" value="1"/> <set name="HXCPP_COMPILE_CACHE" value="/home/pi/Development/.hxcpp_compilecache"/> <!-- change to your own path --> </section> <section id="exes"> </section> </xml> |
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
1 2 3 4 5 6 |
<?xml version="1.0" encoding="utf-8"?> <xml> <section id="defines"> <set name="rpi" value="1"/> </section> </xml> |
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 1920x1080.
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
1 2 3 |
tvservice --explicit="DMT 4 HDMI" fbset -depth 8 fbset -g 640 480 640 480 16 |
This gets me an upscaled 640x480 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!