Raspberry Pi 2 anyone?


Too bad, still getting black textures.
even in the drawingShapes example, except for the 2 first shapes:
could it be something in blending?

Maybe I shoudl start outlining the changes I made to get things working, cause I’m still working in a local copy of both lime and openfl, so I can’t pull changes. ( Recent pulls of both lime and openfl give me more compile errors )

The most important thing are
changes in Lime in Build.xml:

  • forcing it to load a differnt SDL_config.h for rpi (since I’m adding an rpi-specific videodriver and removing x11 for now )
  • adding proper include paths for compiling and linking
  • adding compiler flags for rpi


  • compiler flags in files.xml in the native-toolkit/sdl submodule
    maybe they are not needed here and can be added just in build.xml
    I’m still not completely familiar with the toolchain
    [edit] tested this but It won’t compile if I remove them here


Here’s a zip file with the files I changed in Lime (and native-toolkit/sdl submodule).

I have added the ndll’s that are working for me for the SimpleOpenGLView Example

I’m sure I might be doing some redundant compiler flags here and there, but this is how it’s working for me at the moment.

Sorry I haven’t put these changes in a fork just yet.


Between having a Pi of my own, the upcoming RaspberryJam, and (relatedly) the Gamekid kickstarter, I’m watching this topic with a certain amount of eagerness. Right now the only option for 2d games (short of writing custom OpenGL code) is something like PyGame, and I’d really rather not use Python ever again in my life.



Is that on a RPI2 ??


Thank you @gepatto for sharing your working files. I was able to merge most of your changes, plus additional changes that have made the Raspberry Pi work better.

I fixed lime rebuild to force HXCPP to use an “RPi” binary folder for now. With Haxe and Neko installed (I’m using the links you shared earlier):

lime rebuild hxcpp linux -rpi
lime rebuild hxcpp linux -rpi -static

As usual, you need to rebuild Lime as well:

lime rebuild linux -rpi

Then you can try a sample:

lime test neko

(similar to the -64 flag, the -rpi flag is implied if you run on a Pi)


A few nuances:

I am running on Ubuntu 14.04 on the Raspberry Pi 2, this has a different (standard) file layout. There’s a possibility that things might not build on Raspbian out of the box. I also set SDL2 to use X11 instead of the Raspberry Pi video driver, because I did not want it to be fullscreen, and it didn’t appear to work right with Ubuntu (I had a black screen and could not move the mouse… window size of 0?)

However, I’m not sure if this is hurting/impacting performance. The Pi is slow on XFCE as-is, so I’m not certain if the speed I’m getting is related to that or if it is because I’m using X11.

It would be nice to stay windowed for consistency, but also because I think it’s a good user experience


That’s great,

I’ll go ahead and checkout the latest versions from git and see how they work for me.
Do I need to checkout special branches or just the master?
I’ll try this on a fresh SD-card


When I ran with ordinary GL, there were some strange things with parts of textures that should have been fully transparent being fully visible and white. I’m not sure what this was, so the above screenshot is using --window-hardware=false

Yep, this is the latest Lime and OpenFL, so run openfl upgrade and rebuild :slight_smile:


By the way, I have our build server doing cross-compilation builds for HXCPP for Raspberry Pi now. I can add Raspberry Pi to the standard Lime install if we can get the build working for Lime.

All the files compile, but it can’t find -lEGL, -lGLESv2 or -lbcm_host at the end. Not sure if there’s a solution for this that’s nice or if I should steal from these from a Pi and stick them on the server somewhere so it can finish the build


I agree that using x11 probably should be the default.
For me I like being able to boot straight into an app without loading a desktop because I do a lot of museum installations.
It would be nice of we could specify to use the RPI-video-driver or the X11 driver with a flag maybe, something like
window-driver=X11 or window-driver=rpi

I haven’t tested the performance of apps built with Python’s PyGame, but since it’s using SDL (maybe sdl1) I think we should at least be able to get the same performance.

I haven’t tried doing cross-compilation yet. If cross-compilation should be possible on a mac, I could set up my macmini-server to do this.


Just tested it on a new wheezy install.

lime rebuild hxcpp linux -rpi
lime rebuild hxcpp linux -rpi -static

both work.


lime rebuild linux -rpi

throws an error about not being able to find GLES2/gl2.h
I see that the Build.xml from the latest git-commit does not yet have the paths to

  • /opt/vc/include
  • /opt/vc/include/interface/vcos/pthreads
  • /opt/vc/include/interface/vmcs_host/linux

like mine did. That’s why it’s compaining.


did you install libgles2-mesa-dev?

You might also need libasound2-dev libx11-dev libxext-dev libxi-dev


We have builds!


We should double-check that these work, but (I believe) these both include working RPi binaries :slight_smile:


Ah you were right, I did not have libgles2-mesa-dev.
Now it compiles without the extra copiler flags.

[edit 2]
Seems like installing libgles2-mesa-dev introduced more problems… see reply further down

I’ll go ahead and test the binaries on wheezy

I was wrong, it still needs one small update even when I installed ligbles2-mesa-dev
in the linker section of Build.xml It really needs:
<lib name="-L/opt/vc/lib" />
otherwise the -lbcm_host will can’t be found


I can not get a working executable with the lime and hxcpp versions posted above.
I get an error when starting any example:
Could not load module std@sys_exit__1

I’m now reverting to the previous hxcpp I had installed and will try again

Yes it does work with hxcpp from git.
There seems to be something wrong with the version from
at least for debian wheezy


Although lime compiles, I can no longer run the SimpleOpenGLView example.
I’m getting:
LibEGL warning: DRI2: failed to authenticate
and after that
Error Compiling Vertex Shader

I am reading that libgles2-mesa-dev is not compatible with the Raspberry (or at least Debian Wheezy on rpi2)

so I have put back the include paths in build.xml for now so that I can go on testing why I get the black textures.


Check the shader code, it needs the precision mediump code at the top of the shader, the sample probably uses #if !desktop but needs #if (!desktop || rpi)


I don’t think we need libbcm_host if we don’t use the Raspberry Pi render driver, I think, so I almost left that out, but I figured I would leave it for now. The kids removed the SD card from their Pi and I’d rather keep my Ubuntu installation intact, but I’d like to Raspbian soon and see if we can’t have things a bit more polished



In the mean-time I’m doing a fresh start again, cause now I’m not getting past
LibEGL warning: DRI2: failed to authenticate
anymore (app exits immediately)
and I was also getting errors like:
Could not find primitive lime_update_event_manager_register__2.