Categorie: General

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.

[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

[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.

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

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!

So It’s a year since I had the time to play with OpenFL on a Raspberry Pi.
In this year The Raspberry Pi 3 came out and OpenFL went up a major version.
I was curious to see if this new version would still work on a Pi.

Well, it does and you need less tweaking.
Unfortunately the needed changes can’t be built automatically on the Travis built server
that is testing the Lime an OpenFL repositories. So you will (probably always) need to manually build lime.

So here’s the steps I went through, part of it is the same as the steps from my previous post.
you will still need to get neko2 and build haxe 3.2.1

If you just want to get it running you can try my setup script at this gist

I am assuming you are using the latest Raspbian Jessie. I’m using the 2017-01-11 version.

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/:
Development
— 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)

gist for the steps so far is here:

install_haxe_rpi.sh

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

You can get OpenFL from git too, but for me it wasn’t nescesary

[UPDATE:]

lime’s  commit:4dc184f337154219355d9ec5ed228e61aa826317 already has the changes I’m describing below.
And the raspberry pi target has been taken out of travis ci.
So from the next official lime version you will only have rebuild hxcpp and lime and won’t have to make manual changes

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

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 have haxelib use the GitHub version of lime

I have to force a setting in ~/.hxcpp_config.xml by adding the following line
right after   <section id=”vars”>

And I find I useful  to have the same  setting in ~/.lime/config.xml in the ‘defines’ section,
so thet you can have specific rpi conditionals in your project.xml

Before we’re ready to build Lime we need to make some changes to the SDL.config.h file.

We need to uncomment LINE 83:

so that it becomes:

change line 291 to

and comment out all lines that reference X11 defines (because X11 won’t work!)

[lines: 290,292,293, 306,308,311]

Now SDL should build with udev enabled (for input events)
and raspberry pi specific opengles display drivers.

So let’s build lime

You should now have a working lime for your Raspberry Pi

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!

Here are the steps I made to compile Visual Studio Code on a Raspberry Pi 3
rpi 2 should work too I guess
Compiling takes some time, but only has to be done once of course.

It works on Ubuntu Mate 15.10.3 although it is slow.
It takes somewhere between 40 – 50 seconds to start  on a Pi 3.
I will try it on Raspbian soon.
[edit] Yes it works on Raspbian too!

You can install the haxe plugin by checking out the git repo at https://github.com/jcward/vscode-haxe

then quit en restart vscode. I am getting warnings that the haxe extension is taking (too) long to start.
But it will get there eventually..

I am also trying to get the vscode-hxcpp-debug extension to work. But no luck so far.
I can compile the debugger-binary by using the build-linux.hxml and adding the -D noM32 flag.But it won’t run, so I guess something more is needed. I will update this post when it’s working.

Install node on a Raspberry Pi 2

curl -sL <a class="postlink" href="https://deb.nodesource.com/setup">https://deb.nodesource.com/setup</a> | sudo bash -
sudo apt-get install -y build-essential python-dev python-rpi.gpio nodejs

check:

Today I finished my midi footcontroller for my ipad.

I think it feels a bit weird swiping my ipad on stage,
and since I’m also holding a guitar I found the need for a footcontroller.
I mainly use an app called SetListMaker on stage. This app can be controlled via midi.
Of course I could have used my Behringer FCB1010 midi-footcontroller
but I wanted something that looked a bit more lo-tech.

So I milled a piece of tree trunk (actually Bas did this.. thnx Bas)
and fitted some single throw momentary footswitches that I had lying around.
Next I soldered them to a Teensy 2 and stuffed everything nicely under a piece of sheetmetal.

Since the Teensy can be programmed to act as a midi-device,
al that was left was to connect it via ‘the camera connection kit’.
A custom cable would have been nice, but that’s far more complicated.
(maybe the next version)

No let’s see if it survives the first real gig.

I have been hard at work at the STRP Biennial the last two and a half weeks.
(last week of February and first week of March)
There we exhibited ,or rather performed, ‘The New Machine Era‘.
A Large Machine loosely based on the Rube Goldberg Machine.

Six teams individually built their own ‘cracking contraption’ to be assembled last week into one large machine on the floor of a building called ‘Het Klokgebouw’ in Eindhoven, the Netherlands.