I found my old sd-card which had the older openfl (3.3.6) and lime (2.6.6) versions I was using.
I copied them onto my raspbian jessie card, and haxelib dev to point to these versions.
Now the Test app runs without problems.
So I’m afraid it IS something in lime or openfl.
The search continues…
I found that moving from openfl-3.3.8 to openfl-3.3.9 introduces the freezing…
And moving back solves it 
Now to find out what changed between those versions.
Specifically it’s commit d3ee81cd0a1fd67c6a22ba587f55e3889d4bd8a7.
35 files were updated, and there’s a lot of work in the shaders there.
Continuing…
I now notice that not even the stage, with a window background color, is rendering…
That’s where the shaders were introduced in OpenFL. There are quite a lot of changes to go through in there.
You might want to drag @mrcdk into the discussion.
This might be some good news:
[another-new-raspbian-release] (https://www.raspberrypi.org/blog/another-new-raspbian-release)
quote:
In this release we are shipping an experimental OpenGL driver for the
desktop which uses the GPU to provide hardware acceleration. This is
turned off by default – if you want to enable it, you can find it in the
command-line version of raspi-config, under Advanced
Options->GL Driver. Due to memory requirements, this will not work on
Pi 1 or Pi Zero boards – it is solely for Pi 2. (raspi-config will only
allow it to be enabled on a Pi 2; be warned that if you enable it on a
Pi 2 and then move that SD card into a Pi 1 or Pi Zero, the Pi will not
boot.)
I found there’s a problem with the
vec4 colorTransform(const vec4 color, const vec4 tint, const vec4 multiplier, const vec4 offset)
function in the defaultShader.
I’m guessing it’s a division by zero in unmultiply = vec4(color.rgb / color.a, color.a);'
So color.a == 0.0 is not always catching 0 on the rpi?
or maybe color.a doesn’t have value (if that is at all possible)
hmm weird… in VERTEX_SRC of the DeaultShader
if I force color.a t be 0.0 there’s no problem.
' ${Varying.Color} = vec4( ${Attrib.Color}.bgr * ${Attrib.Color}.a, 0.0 );',
if I add a tiny fraction to * ${Attrib.Color}.a it’s ok
' ${Varying.Color} = vec4( ${Attrib.Color}.bgr * ${Attrib.Color}.a, ${Attrib.Color}.a + 0.00001 );',
but If I just use
' ${Varying.Color} = vec4( ${Attrib.Color}.bgr * ${Attrib.Color}.a, ${Attrib.Color}.a);',
it freezes…
great find! maybe we can make a little fix
for anyone here, wanna migrate glsl code to raspi,
-> take care of “modulo” math operator ;)=
So to sum it all up.
It’s possible to use the latest haxe (3.2.1) and openfl (3.6.0) an lime(2.9.0) with hardware acceleration on the raspberry pi 2 with raspbian Jessie. Support for running it in an x11 window may come in the near future if they continue the work on the experimental opengl driver.
At the moment you will need to modify lime manually because the required changes would break the buildserver. These modifications enable the raspberry-pi sdl videodriver and udev for deviceinput support. They will also fix some bugs that are still in sdl regarding the mousepointer.
At the moment you will also need to make a small modification to openfl , but a fix maybe added to the repo soon.
I’ll write a full article on how to 'Get Pirate Pig Running on a Raspberry Pi 2 with Raspbian Jessie" very soon so you don’t have to collect all the pieces from all the posts above.
make tools throws an error
/home/pi/Development/haxe/source/haxe/std/Reflect.hx:1: character 0 : Invalid character 0x80
Makefile:86: recipe for target ‘haxelib’ failed
Did you check out the 3.2.1 branch of haxe? I have had the same problems with the master branch
I’ll package the haxe binaries later on today and post a link
I’ve used "git clone --recursive https://github.com/HaxeFoundation/haxe -b 3.2.1"
I’ll wait for the binaries, thanks 
I have packaged my haxe directory, the one I got from the command:
git clone --recursive https://github.com/HaxeFoundation/haxe -b 3.2.1
You can download it here.
use
tar zxf haxe_321_rpi.tgz
to expand the archive and then run:
sudo make install install_tools
That should install the binaries and you should be able to run the haxe and haxelib commands
I didn’t filter out the source files because I’m curious whether
make && make tools
do work from this dir… If not you might be missing something else…
Then the question is: are you on the latest raspbian and did you install all the dependencies?
There is some discussion on the haxedev list about the haxe package. I was thinking, maybe the binaries could be submited by the community to show in the haxe download page. It could have the message, “Submited by the community, not tested by the Haxe Foundation” (or not supported).
https://groups.google.com/forum/?hl=pt-BR#!topic/haxedev/2F0SAbNXj0A
make and make tools work just fine from your dir thanks a lot
That’s good to know Mathew!
I have compiled haxe on 4 fresh installs of Raspbian (includuing raspbian lite) now without any problems.
So I don’t know what went wrong on your side, but am glad to know it’s working for you too now.
@RafaelOliveira Sharing the binaries would be absolutely fine with me.
Also: I’m ok with testing things on the raspberry if someone from the haxe-group needs it.
I’ll jump in on the thread over on google groups.
Now lime rebuild lime linux -rpi -v throws an error
I guess I messed up somewhere 
- Running command: arm-linux-gnueabihf-g++ -o ../ndll/RPi/lime.ndll -shared -fpic -fPIC -Xlinker --no-undefined @/home/pi/Development/haxe/dev/lime/project/obj/linux-rpi/all_objs /home/pi/Development/haxe/lib/hxcpp/3,2,205/lib/RPi/liblinuxcompat.a -lpthread -lrt -lbcm_host -ldl -lm -lGLESv2 -lEGL -L/opt/vc/lib -ldl
obj/linux-rpi/a38a0eb8_SDLApplication.o: In function `lime::SDLApplication::SDLApplication()':
SDLApplication.cpp:(.text+0x168): undefined reference to `lime::DropEvent::DropEvent()'
SDLApplication.cpp:(.text+0x220): undefined reference to `lime::DropEvent::DropEvent()'
obj/linux-rpi/a38a0eb8_SDLApplication.o: In function `lime::SDLApplication::ProcessDropEvent(SDL_Event*)':
SDLApplication.cpp:(.text+0x2d8): undefined reference to `lime::DropEvent::Dispatch(lime::DropEvent*)'
SDLApplication.cpp:(.text+0x2ec): undefined reference to `lime::DropEvent::callback'
obj/linux-rpi/58fa277f_ExternalInterface.o: In function `lime::lime_drop_event_manager_register(_value*, _value*)':
ExternalInterface.cpp:(.text+0x5038): undefined reference to `lime::DropEvent::callback'
ExternalInterface.cpp:(.text+0x5040): undefined reference to `lime::DropEvent::eventObject'
collect2: error: ld returned 1 exit status
Error: Error running: arm-linux-gnueabihf-g++ -o ../ndll/RPi/lime.ndll -shared -fpic -fPIC -Xlinker --no-undefined @/home/pi/Development/haxe/dev/lime/project/obj/linux-rpi/all_objs /home/pi/Development/haxe/lib/hxcpp/3,2,205/lib/RPi/liblinuxcompat.a -lpthread -lrt -lbcm_host -ldl -lm -lGLESv2 -lEGL -L/opt/vc/lib -ldl []
Hmm something definitely seems to be out of sync on your side.
But I see there was a new commit to lime yesterday , so that might also be the cause. I’ll check