Raspberry Pi

Get PiratePig Running on a Raspberry Pi 2 with Raspbian Jessie


[ THIS POST is outdated, There are newer versions of OpenFL. Go here: ]

[ UPDATE 20-03-2106:  This guide also works on Ubuntu Mate 15.10.3 ]

A while ago I wrote an article on how to use hardware accelerated openfl  on the rassberry pi 2.
Since then there’s been some changes to openfl and lime as they are now using haxe 3.2.1and work has been done on how things are rendered.

So here is write up on how to get version 3.2.1 of haxe and the git-versions of openfl and lime running on your Raspberry Pi 2. I’m pulling in lime and openfl from github because we need to make some changes to the source at the moment.
Hopefully in the near future we can build some binaries.

I will show you how to build everything from source, but give an alternative for neko

Grab yourself a thermos with coffee and a couple of hours, this is going to take a while!

I am assuming you are using Raspbian Jessie, I tested everything below on a fresh raspbian image with release date 2016-02-09

First of all I like to have all my stuff in a Development directory in the home directory so let’s create it along with some directories inside it.

this creates the following structure in /home/pi/:
— haxe
—- dev
—- lib
—- source

before we grab neko and haxe, let’s install some dependencies that you will need to compile them.

Now let’s grab neko, you can either build from source or use a binary from openfl.
If you would like to use the binary do the following

or you can build from source.
you can skip libraries when it asks you to, I’m not using the neko apache and gtk and mysql4 modules on the Pi

you can test if neko was installed by running

Now lets get the haxe-3.2.1 source
We will checkout out a specific branch

You should now have a working version of haxe and haxelib
so we’ll setup haxelib next
Earlier we made directories for haxelib libraries (/home/pi/Develeopment/haxe/lib) and libraries you build yourself or checkout from git (/home/pi/Develeopment/haxe/) this is how I do it but feel free to do otherwise

now to make things easer further along the road we will install and setup openfl eventhough it will not work right away
it will install some libraries we’ll need anyway. Maybe in the future this WILL be all you need to do.

(choose yes to install the openfl command)

you should now be able to run the openfl command and the lime command
but we’ll be checking out the source versions of both lime and openfl now in the dev directory

Because the Raspberry Pi has it’s OpenGLES2 libraries in a different place from other linux-distributions
adding paths to these libraries in the Build.xml file of lime/project and submitting to the repository will crash the buildserver that is based on linux but doesn’t have these paths. So we will have to do this manually for now.

edit the file lime/project/Build.xml, for instance with nano

now uncomment line 357 (approximately) so that it reads:

And add the following line after line 361 (approximately)

and add this section right after line 190 (approximately) : the closing section xml tag for the emscripten section

or you can use this patch file for Build.xml
[ or alternatively here’s a GIST with the contents of my Build.xml ]

[IMPORTANT UPDATE:  the patch and GIST do not work with the latest commit of lime (anything later then Feb 20, 2016 ),
because in that commit the Build.xml file was modified
So it’s better to manually edit the existing Build.xml as described above ]

Now you should almost be able to compile lime but there’s still a few bugs in SDL for the raspberry pi.
I have tried to come up with a fix and have made a clone of the SDL-submodule within limeThe master  just fixes SDL-config file so that it uses the correct video-driver and fixes the mouse-cursor.
There’s also a branch that has experimental support for the raspberry pi touchscreen.

So we are going to replace the sdl directory in the lime source (we’ll rename the old sdl directory)
unfortunately these changes will break the ability to pull changes from the repo
I will use the branch that has the support for the touchscreen (mouse support should work even without a touchscreen)
and then we’ll rebuild lime

before we can rebuild lime we have to rebuild hxcpp normal and static
Note: the first line may give an error: g++: error: unrecognized command line option ‘-m32’
if it does just run the first line again.

Now let’s go make a minor change to the DefaultShader in openfl.
Don’t forget to set haxelib dev to the openfl folder in dev!! (I just did while making this post 😉
For reasons still unknown the alpha-component in the defaultShader is crashing on the Raspberry Pi.
A temporary fix is to add a tiny fraction to the alpha component in the Vertex-Shader.

now change line 28 to

now it’s time to compile Pirate-pig
I’ll make a directory for openfl projects and create the PiratePig Example here.
Then we’ll make a small change to the PiratePig Example.
This is because the application is not show in a window and therefore you have no way to close the application.
We’ll just add a keydown EventListener on the stage, choose a key combo and issue the quit command

now add the eventlistener to the ‘public function new () ‘ function right after the onResize listener

add an import statement for the Keyboard constants (after line 8 i.e.)

and add the callback after the onResize Callback

now you will be able to quit the app with f4

Then there is just one thing left to do
time for another coffee and maybe eat something!

I think you should be looking at pirate-pigs, pandas and more!

game_panda game_piratePig

ow, and you should be able to use your fingers if you own a raspberry touchscreen !

Raspberry Pi

Using the Raspberry Pi Touch Display with OpenFL

I really like the new Raspberry pi display.

One of the things I was really looking forward to was using it with OpenFL.
But out of the box SDL2 wasn’t supporting the display in the mode I am running OpenFL namely without x11.

So I decided to do a little digging.
I found that mouse and keyboard devices are being handled in sdl_udev and sdl_evdev.
Basically udev was looking for and identifying input devices and evdev was handling incoming events from identified devices.

I could see that udev was finding an ID_INPUT_TOUCHSCREEN device, but there was nothing more than a comment after that.
So I decided to try and trick udev by identifying the touchscreen as a combined mouse and keyboard device.

Immediately I could move the mouse pointer but a touch triggered a key-event with an unhandled value of 330.
( later I found that this key is defined in linux/input.h as BTN_TOUCH )
So I added the button to the if statement that was catching the mousebutton values in SDL_evdev.c
and cheated a bit by changing it to mouse-button 0

I thought that it was working until I noticed something strange. It felt like the mousedown event was out of sync.
So I opened the utility evtest on an ssh session to see what was going on.
If found that the touchscreen was firing 2 unhandled events before the BTN_TOUCH event:

the code was only handling the ABS_X events so indeed the Touch event came before the x en y positions where handled.
So I added these 2 new events:

Et Voila!, the touch screen is working as a mouse.

For proper multitouch a different approach is needed.
But for testing this hack works quite well.



Raspberry Pi

Using the GPIO ports with OpenFL

Over the last few weeks I have been exploring OpenFL and Haxe.
I was particularly interested in getting OpenFL to run on the Raspberry Pi.
One of the cool things about the Raspberry Pi of course is the GPIO-ports.
So after I got a version of OpenFL running on the Pi it was time to take the next step and look into the development of native extensions for OpenFL.

I don’t really have a background in c or c++, but I’m able to read through other people’s code if it’s not to complicated.
I had a look at the hxSerial extension and for the most part was able to see what was going on.

I had already been playing around with the wiringPi library and the c-examples that came with it, and I knew how to blink an led and how to read from a digital input port.
I had also looked at the wiringPi wrapper for nodejs and I saw that is was mainly just translating javascript types to native c++ types.
Last but not least I had a look at a post on
So by combining the things I saw in these examples I took the first step towards creating my hxPiGpio extension.

I’ll probably make a separate post in the near future on how to create an openfl c++ extension. But for now I’m focusing on how to use my Extension.

I wrapped the wiringPi setup functions , the digitalRead and digitalWrite functions and some static inline vars for the pinmodes.

If you would like to try out the extension follow these steps: (WARNING EXPERIMENTAL CODE)

First of all you need to run Raspbian Jessie! if you want to be able to test using the ‘openfl test linux’ command.
This is because on Wheezy the gpio ports require the use of the sudo command, while on Jessie you can access them without the sudo command if you add a file to /etc/dev/rules.d/

Next of course get openfl working through the steps of my earlier post.

If that’s working go ahead and install wiringPi and make sure you are using version 2.29 following the steps on this page
do not forget to add the file to /etc/dev/rules.d/ as mentioned and shutdown your pi.

While your pi is off it’s a good time to connect an led and button in the following fashion and restart your pi.
( at your own risk of course, I am not responsible for any damage to your pi )


Checkout the extension from my github page to the directory where you keep the development haxelib modules
( I keep the ones I get from ‘haxelib install ..’, separate from the ones I compile from source)
Now compile the extension

now you checkout the testProject in the directory where you keep your projects, and compile

hopefully, if I didn’t miss any steps, you’ll see something like this:
and you will be able to click on the led on screen and have it turn on the actual led, and press the button to toggle the color-version of the raspi logo.

the latest version of this testproject is trying to connect to SPI so it might not work if you have not enabled it in raspi-config.
( haven’t tried this yet with spi disabled)
You can probably also comment out the line in Main.hx that says

This is all still experimental / proof of concept. I’m not concerned with coding conventions or even proper code at the moment.
That will happen if I decide to put the extension up on haxelib and my c++ skills have improved.

Feel free to fork and improve the code if you have more experience in c++



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.