thank you all for great work,
my peote-view lib renders 1000 000 tiles onto that at 0.3fps … below 8K its fast like 
-> http://gfxl.de/lounge/haxe-raspberry-pi-2
without X it runs cool 
1 Like
Great @maitag good to see people are enjoying haxe/openfl/lime on the pi!
I’m working on getting the latest versions of openfl, lime and haxe 3.2.1 to work on raspbian jessie.
I’ll start a new thread once this is working.
If there are people that would like to help out, please let me know.
Hey Guys,
I’m stuck getting the latest versions of openfl and lime running with haxe 3.2.1 on the Raspberry Pi.
If there’s anyone else who would like to help out and could we maybe create a Raspberry Pi focus group?
Maybe outside this forum , but with reporting back progress we make.
Or a separate thread?
I know the Raspberry Pi (with raspbian) is a bit different from the other targets because you won’t be able to run from a desktop environment ( maybe in the future ) But it would be awesome to be able to create User Interfaces and Games without having to resort to python or c++.
I have been successful with older versions of openfl and lime as you can see in this thread.
But now it’s time to adapt to the newer versions.
Here’s my progress so far:
Right now, it is possible to compile Haxe 3.2.1 on Raspbian Jessie because you can install the required ocaml 4.x libs.
I have neko, haxe, haxelib compiled and can run all of them
I can get the latest openfl and lime from git and compile them.
The SimpleImage lime-sample works ( other demos throw segmentation faults)
But OpenFL doesn’t work at the moment:
As soon as you use addChild the app Freezes.
There’s no more events (i.e. enterframe), the mouse doesn’t move and the keyboard doesn’t work anymore.
And it seems I even have to reboot the Pi before I can get an openfl-app to run with a working mouse and keyboard again.
At the moment I’m doing all the work using SublimeText (via samba on a mac) and that’s very cumbersome.
If any of you has any tips for a better workflow, they are more than welcome…
( my other computer is a mac )
Regards
Can you share how do you compiled haxe 3.2.1? I have here a older version of the rpi (not 2), I don’t know if this has a affect. I’m interested in the rpi, but I’m planning to port Kha (or at least help Robert when he have time…). But I can help with openfl too.
Is that because ocaml isn’t available at all or because that specific version hasn’t yet been added to Jessie or any other reason why?
The ocaml 4 libs are in the jessie repository, but not in wheezy . So It’s easy to install on Jessie.
On wheezy I had to compile from source and did not succeed.
On a fresh Jessie however I did ( not everything is needed, i.e. samba )
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install samba samba-common-bin
sudo apt-get install libgc-dev libpcre3-dev
sudo apt-get install libudev-dev
sudo apt-get install build-essential git cmake
sudo apt-get install ocaml ocaml-native-compilers libpcre-ocaml-dev
sudo apt-get install sqlite3 libsqlite3-dev
sudo apt-get install libmysqlclient-dev
sudo apt-get install libasound2-dev
[EDIT: don’t get neko from git , use the archive, but don’t forget the symlinks ]
wget http://nekovm.org/media/neko-2.0.0.tar.gz
tar zxf neko-2.0.0.tar.gz
cd neko-2.0.0
make all
sudo make install
sudo ln -s /usr/lib/neko/libneko.so /usr/lib/libneko.so
sudo ln -s /usr/lib/neko/neko /usr/bin/neko
sudo ln -s /usr/lib/neko/nekoc /usr/bin/nekoc
sudo ln -s /usr/lib/neko/nekotools /usr/bin/nekotools
now get haxe
git clone --recursive git://github.com/HaxeFoundation/haxe.git -b haxe-3.2.1
cd haxe
make all
make tools
sudo make install
sudo make install_tools
I think this was all that was needed to get haxe and haxelib compiled.
( should we do this in a new thread on this forum?)
That would be great if you could help!
There is a difference in architecture though. The Raspberry pi 2 is an armv7
while older versions are arm6. I know that there are checks in the code for the armv7 architecture
so older versions might not work.
Could it work thru neko 2.0.0? Haxe and Lime are still on it
Yes, neko 2.0.0 is the one I’m using now. so the [download from the neko site] ( http://nekovm.org/download ) wil probably work. I’ll Check and edit this post with the result.
[edit]
Yes it compiles…
I remember at one point it didn’t but I never went back to check.
So just grab it from the neko site.
but don’t forget to make symlinks ( I edited the post above )
You will need to get openfl and lime from git if you want to try hardware acceleration.
Here’s what to do to get to the point where I am:
There are some library and linker paths missing in the lime/project/build.xml because they trip up the ubuntu build-server my working version is here.
you need to add a line to the exit function in lime/lime/_backend/native/NativeApplication.hx to have sdl return your keyboard to the console when you quit your app (you will need to build a quit function yourself in openfl because there are no window-close buttons )
public function exit ():Void {
AudioManager.shutdown ();
lime_application_quit(handle); // this line shuts down sdl properly
}
and there are a few bugs in sdl. You can just rename the sdl dir in /lime/project/lib and then check out one of my branches from github in this directory and rename or symlink it to sdl
you should now be able to rebuild lime…
I hope I didn’t miss any steps
update: Still stuck with openfl 3.6.0 and lime 2.8.3.
It seems that once I add something to the stage, the application loop freezes.
(although it does seem to run for 2 or 3 more frames, nothing is displayed!)
I have to force quit the app.
When I try to run it again, it won’t even get to the construction of the GLRenderer.
( I have some trace statements in place in GLRenderer.hx )
So I think the problem must lie in Lime…
Here’s the very simple app I’m testing
package;
import openfl.display.Sprite;
import openfl.display.Bitmap;
import openfl.events.Event;
import openfl.events.MouseEvent;
import openfl.events.KeyboardEvent;
import openfl.ui.Keyboard;
import openfl.ui.Mouse;
import openfl.Assets;
import openfl.display.FPS;
import openfl.text.Font;
import openfl.text.TextField;
import openfl.text.TextFormat;
class Main extends Sprite {
private var count:Int = 0;
private var logo:Bitmap;
private var Fps:FPS;
private var format:TextFormat;
public function new () {
trace("Main new");
super ();
logo = new Bitmap (Assets.getBitmapData ("assets/openfl.png"));
trace("loaded logo: assets/openfl.png");
stage.addEventListener( Event.ENTER_FRAME, update );
stage.addEventListener( KeyboardEvent.KEY_DOWN, stage_onKeyDown );
trace("added event listeners");
}
function update(e:Event){
count++;
trace("frame", count);
}
private function stage_onKeyDown (event:KeyboardEvent):Void
{
switch (event.keyCode) {
case Keyboard.A:
trace("add logo to stage");
addChild (logo);
case Keyboard.F:
trace("add fps to stage");
addFPS();
case Keyboard.F4:
openfl.system.System.exit(0);
}
}
private function addFPS(){
var font = Assets.getFont ("fonts/Ostrich Black.ttf");
format = new TextFormat (font.fontName, 24, 0x24AfC4);
Fps = new FPS(10, 10, 0x000000);
Fps.defaultTextFormat = format;
addChild(Fps);
}
}Neko compiled here (with some libs skiped like mod_neko), but sudo make install installed it in /usr/local/lib and /usr/local/lib/neko folders. Is there a way to force it to install in usr/lib and usr/lib/neko? the symlinks dont worked because of this.
Ooops, that might be a copy paste error mistake by me.
I was lazy and copied the symlinks lines from an older haxe install script
that downloads binaries, while I compiled from source and did the symlinks by hand because I was getting permisions errors. (but now I see my symlinks are pointing nowhere!!)
Is neko working without symlinks? or are you getting permission errors too?
The neko make file does install to /usr/local/ by default.
INSTALL_PREFIX = /usr/local
I have neko running from /usr/local/…
I removed the neko binaries and used the one that is provided in the openfl install script for linux. I had problems when I used the command ‘make tools’ when was compiling haxe. It wasn’t finding neko. After that everything was ok, I installed hxcpp and compiled a hello world. I will continue later.
this is the script:
wget -c http://www.openfl.org/builds/neko/neko-2.0.0-rpi.zip
sudo mkdir -p /usr/lib/neko
sudo rm -rf /usr/lib/neko/neko
sudo rm -rf /usr/lib/neko/nekotools
sudo unzip -o neko-2.0.0-rpi.zip -d /usr/lib/neko/
sudo cp -r /usr/lib/neko/bin/* /usr/lib/neko
sudo rm -rf /usr/lib/neko/bin
sudo rm -rf /usr/bin/neko
sudo rm -rf /usr/bin/nekoc
sudo rm -rf /usr/bin/nekotools
sudo rm -rf /usr/lib/libneko.so
sudo ln -s /usr/lib/neko/libneko.so /usr/lib/libneko.so
sudo ln -s /usr/lib/neko/neko /usr/bin/neko
sudo ln -s /usr/lib/neko/nekoc /usr/bin/nekoc
sudo ln -s /usr/lib/neko/nekotools /usr/bin/nekotools
rm neko-2.0.0-rpi.zip
Ah good to see you have the neko part solved.
Using the binary is less complicated so that’s a good way to go.
Next up getting lime to compile with gles2… 
I still haven’t found why nothing is rendering anymore.
I wish I knew a way to trace the last executed function before the app freezes. I need better debugging skills…
If you’re using lldb or gdb you should be able to do a bt to see the backtrace and then move up through the call stack with the up command.
Thanks Tanis,
I’ll look into using gdb and try that right away
I ran my test app with gdb,
When I add something to the stage the app freezes.
I then hit ctrl+c and gdb always reports:
Program received signal SIGINT, Interrupt.
0x76f8ca40 in do_futex_wait (isem=isem@entry=0x765dca40 <khrn_queue+76>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48
48 ../nptl/sysdeps/unix/sysv/linux/sem_wait.c: No such file or directory.
(gdb) up
#1 0x76f8caf4 in __new_sem_wait (sem=0x765dca40 <khrn_queue+76>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:69
69 in ../nptl/sysdeps/unix/sysv/linux/sem_wait.cCan you get a backtrace of that? It looks like it’s stuck waiting for a mutex.
Here’s the backtrace:
#0 0x76f8ca40 in do_futex_wait (isem=isem@entry=0x76138b74 <pool_mem+1444>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48
#1 0x76f8caf4 in __new_sem_wait (sem=0x76138b74 <pool_mem+1444>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:69
#2 0x76152538 in eglSwapBuffers () from /opt/vc/lib/libEGL.so
#3 0x768d42e0 in SDL_EGL_SwapBuffers (_this=0xb337f8, egl_surface=0x1) at ./lib/sdl/src/video/SDL_egl.c:570
#4 0x768de064 in RPI_GLES_SwapWindow (_this=0xb337f8, window=0xb32f48) at ./lib/sdl/src/video/raspberry/SDL_rpiopengles.c:36
#5 0x768a7bf4 in SDL_GL_SwapWindow_REAL (window=0xb32f48) at ./lib/sdl/src/video/SDL_video.c:3191
#6 0x768dc2c4 in GLES2_RenderPresent (renderer=0xb32740) at ./lib/sdl/src/render/opengles2/SDL_render_gles2.c:1872
#7 0x768326f4 in SDL_RenderPresent_REAL (renderer=0xb32740) at ./lib/sdl/src/render/SDL_render.c:1837
#8 0x76810d10 in SDL_RenderPresent (a=0xb32740) at ./lib/sdl/src/dynapi/SDL_dynapi_procs.h:381
#9 0x7623e5f0 in lime::SDLRenderer::Flip (this=0xb31e10) at ./src/backend/sdl/SDLRenderer.cpp:118
#10 0x76202200 in lime::lime_renderer_flip (renderer=0x76bf3afc) at ./src/ExternalInterface.cpp:1061
#11 0x007e310c in lime::_backend::native::NativeRenderer_obj::flip (this=0x76bf32dc) at ./src/lime/_backend/native/NativeRenderer.cpp:185
#12 0x006b511c in lime::graphics::Renderer_obj::flip (this=0x76bf3198) at ./src/lime/graphics/Renderer.cpp:98
#13 0x007fd848 in lime::_backend::native::NativeApplication_obj::handleRenderEvent (this=0x76bf11f0) at ./src/lime/_backend/native/NativeApplication.cpp:939
#14 0x007fdad0 in lime::_backend::native::__NativeApplication_objhandleRenderEvent (inObj=0x76bf11f0) at ./src/lime/_backend/native/NativeApplication.cpp:980
#15 0x00950294 in hx::CMemberFunction0::__run (this=0x76c03f28) at /home/pi/Development/haxe/dev/hxcpp/include/hx/DynamicImpl.h:50
#16 0x008d26e8 in val_call0 (arg1=0x76c03f28) at /home/pi/Development/haxe/dev/hxcpp/src/hx/CFFI.cpp:585
#17 0x76249a5c in lime::RenderEvent::Dispatch (event=0xb330f8) at ./src/graphics/RenderEvent.cpp:36
#18 0x76238f8c in lime::SDLApplication::HandleEvent (this=0xb33040, event=0x7efff2a0) at ./src/backend/sdl/SDLApplication.cpp:128
#19 0x7623a2e0 in lime::SDLApplication::Update (this=0xb33040) at ./src/backend/sdl/SDLApplication.cpp:731
#20 0x76238db4 in lime::SDLApplication::Exec (this=0xb33040) at ./src/backend/sdl/SDLApplication.cpp:97
#21 0x761ffcfc in lime::lime_application_exec (application=0x76bf1b14) at ./src/ExternalInterface.cpp:117
#22 0x007fac74 in lime::_backend::native::NativeApplication_obj::exec (this=0x76bf11f0) at ./src/lime/_backend/native/NativeApplication.cpp:274
#23 0x007bcda8 in lime::app::Application_obj::exec (this=0x76bf10a8) at ./src/lime/app/Application.cpp:1325
#24 0x008cc310 in ApplicationMain_obj::create () at ./src/ApplicationMain.cpp:149
#25 0x008cd794 in ApplicationMain_obj::main () at ./src/ApplicationMain.cpp:264
#26 0x008cff08 in __hxcpp_main () at ./src/__main__.cpp:18
#27 0x008cfe38 in main (argc=1, argv=0x7efff714) at /home/pi/Development/haxe/dev/hxcpp/include/hx/HxcppMain.h:86
this is a version that adds a bitmap child to the stage after 1 frame…
It looks like a problem with the way OpenGL ES buffers are being swapped between the display and the surface. This sounds like a hard one to debug. I do not know if the RPi implementation of the OpenGL driver needs something to be done before swapping buffers. Your best bet is to get in touch with someone over at SDL and check with them.