Experiments Raspberry Pi

Getting OpenFL to run with hardware acceleration on a Raspberry Pi 2

This is an old post! There are newer versions of haxe, openfl and lime than this post is describing.
New post is Here.

First of all Kudos to the Haxe and OpenFL teams for their ongoing efforts.

The last couple of weeks I have been trying to get OpenFL to running on the Raspberry Pi 2 with the latest Debian Wheezy ( 2015-05-05)

I was researching if the rpi2 could be added to the list of platforms.
It has my special interest because I do a lot of work for museums where there’s usually a tight budget.
It would be wonderful if I could use the RPi2 for relatively simple interactive installations:
I have been working with @singmajesty from OpenFL,

I’ll describe some of things I had to do but it won’t contain every detail.
[ blahblahblahblah šŸ˜‰ SKIP to installation steps already ]

The first thing to do was getting a working Haxe and Neko for the Raspberry Pi 2.
Although haxe is at version 3.2.0 there is no Binary for the Raspberry Pi for that version.But I found that there is a binary for the previous version 3.1.3
(I will list all the proper links at the end of this post)

Next up was Neko v2. I managed to compile this from source.
At first ‘make all’ was throwing all kinds of errors. Some of them we’re dependencies others were missing parts of Neko that were part of the compile process, clearly there was something wrong with the compile order in the makefile.
By compiling all the targets one by one and in the right order I was able to compile a Neko Binary
After a few days I saw a new commit that fixed all the problems and now ‘make all’ is working properly.

After moving Haxe and Neko to the proper locations, I could now run Haxelib.

we used this to create binaries that can now be downloaded, see instructions below

‘Haxelib install openfl’ failed unfortunately as there was no lime.ndll for the Raspberry Pi 2.
So the second hurdle was getting lime to compile. It was throwing a lot of errors because the compiler was adding the -m32 flag which doesn’t work on the armv7 architecture.
We fixed that and now I was able to compile both hxcpp, needed for compiling the cpp binary for the Raspberry Pi 2, and lime.

With a lime.ndll for RPi in place I was able to compile the PiratePig example.
There was a bug in the shader code leaving everything black. But after fixing that we finally had Pigs,Pandas and what not on screen. But it was terribly slow.
This was because it was doing software-rendering instead of hardware opengles.
I had to dig deep into SDL and Lime to figure this out.

By looking at other people that succeeded to compile SDL2 for the Raspberry Pi 2 I found out the minimum requirements for running and SDL-Example. One notable thing was that nobody was using X11. Instead they were rendering straight to the screen.
I brought these settings over the SDL_config.h file ( at first the linux version, but later a separate version for RPi ) and added the neededĀ  paths to the location of the EGL and GLES headers and libraries to Lime’s Build.xml.
With a tweak to NativeWindow and OpenglBindings in lime I was now able to use Hardware Accelerated OpenGL-ES.

But the mouse-pointer was behaving badly. When it reached the side or bottom of the screen, it started scaling up and then disappear for good. It took me a week to figure out that this was a bug in the SDL_rpimouse mouse code, that was calling a dispmanx method that was misbehaving. Unfortunately there is almost no documentation for dispmanx. But I was lucky enough to find an example that was doing something similar to a mouse pointer and I was able to fix it.

BUT: there was another problem with the mouse. As I moved my mouse over the edges of the screen the pointer would stay within the screen-rect. But when IĀ  moved the mouse further and then started to move back, the pointer would cling to the edge of the screen until I had moved the exact amount in the opposite direction. So behind the scenes it was still adding relative mouse changes to a buffered mouse position.
I was able to fix this in sdl_mouse.

So now I can run an OpenFL app from the command line, or from within X11.
The will both render fullscreen, there is no window in X11.
( I have read about Eric Anholt’s Pi VC4 driver so there may be hope )

There is is still a bug that sometimes doesn’t return the keyboard to the console when you quit your openfl app,
and you will have to write the exit routine yourself. If you don’tĀ  you won’t be able to quit your app, and will have to start an ssh-session from another machine to quit the process.

But it’s a start, and I’m happy.

Because there’s a bunch of hacks and Raspberry only statements I have put my changes to lime and sdl in 2 repositories of my own. If you would like to have a go with these, feel free , but you won’t get any fixes or features from the official Lime and Sdl repositories.

Don’t create any issues on these repositories. They are there so you can test this without having to use patches. It should eventually find it’s way back into the main repository.

[ installation steps ]

First of all get the haxe and neko install script from
and run it

sudo chmod +x
sudo ./

now get some dependencies: (I hope I didn’t miss any)

sudo apt-get install libx11-dev libasound2-dev libxext-dev libxi-dev libudev-dev

create a directory for the haxe libs, I keep mine in /home/pi/haxe/lib/
I also have a directory for the development libs: Ā  /home/pi/haxe/libdev/

mkdir -p /home/pi/haxe/{lib,libdev}
haxelib setup /home/pi/haxe/lib/
haxelib install format
haxelib install openfl
haxelib run openfl setup
lime rebuild hxcpp linux -rpi
lime rebuild hxcpp linux -rpi -static

At this point you should be able to compile an OpenFL example, but it will complain about OpenGL/GLES-libary
so go to your development library directory and checkout lime from my github repo.

!! I will be making changes to my repo soon so that I can create pull request to the official repo!!

cd /home/pi/haxe/libdev
git clone --recursive
haxelib dev lime lime

go into the directory project/lib/ and delete the sdl folder, and then check out my sdl repo
I had to do it this way because I couldn’t figure out how to point the sdl submodule to my repo. I tried but failed

cd lime/project/lib/
rm -Rf sdl
git clone

rebuild lime

lime rebuild lime linux -rpi -v

now create the piratePig Example

cd /home/pi/
mkdir openfl_projects
cd openfl_projects
openfl create PiratePig
cd PiratePig
openfl test linux -rpi

I think you should see this:


Now this is just the beginning, feel free to play around with the code, but don’t create any issues on the github repo. It’s just there so you can test this without having to use patches. It should eventually find it’s way back into the main repository.

Important Note:

If you are not starting from a clean Wheezy install, and you have installed the libgles2-mesa-dev package at
it’s not going to work cause it will try to use non-compatible drivers.Ā  I made that mistake and couldn’t recover and had to reinstall wheezy.