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.



iPad Foot-controller update

I had a lot of fun with my midi foot controller for my iPad,
but I still felt it needed something extra, or rather something less!

So I got rid of the cable and turned it into a Bluetooth (BLE) rechargeable and reprogrammable foot controller.
It can act as a regular Bluetooth Keyboard including Special keys.
It’s powered by a  1250 ma Lipo and can be charged through a Mini-USB B connector.
On the back there’s a small push-button to unpair the device and on the side there’s an on/off switch.

This Saturday I’m gonna take it for a spin on a gig!



Fretboard prototype working

Let me explain what the Ukulele prototype is all about.
A long while ago I showed a breadboard with a bunch of leds that represented the fingerings of chords on a ukulele. Back then it was controlled through flash and java.

This time I took the measurements of a real ukulele’s fretboard and used a lasercutter to cut the shape of the fretboard and the holes for 3mm leds. I’m using a max7221 chip to drive the led matrix. Since this chip can only drive a 8×8 matrix (or so I think) and not a 16×4 I had to put rows 5 to 8 behind rows 1 to 4. I only used 6 colums in all rows. So row 1 and row 5 represent the frets of the first string and so on. It’s connected to an arduino (duemillanove).
I grabbed the schematics and library from the arduino site .
The sketch is reading from the serial port, and I’m sending 4 characters in hex representing the fretnumber for each string. Where a fret number is converted to the correct led.
So frets 1 to 6 on string 1 are led 1 to 6 on row 1, and frets 7 to 12 are less 1 to 6 on row 5..


I then started to build an html5 version of the wonderful Ukulele Playalong by my friend Marcel van der Zwet . It’s certainly not ready yet but it has the basic functionality of showing the chords to a song. The chords are timed to a video on youtube, and I’m using popcorn.js trigger the chords a the correct time. The events are routed through a websocket to a helper application ( a simple Cocoa app at the moment) that in turn sends it to the serial port after which the arduino does the rest.

So next up is version 2: building a custom pcb with smd components so that I can actually mount it onto the neck of a (soon to be sacrificed) ukulele.
But that means I have to learn to work with software like Eagle and doing multilayered pcb’s
which is all completely new to me. So I think this will take while….