Ok next up: trying to build an example.
I’m pretty sure I’ll run into some more issues.
I’ve made a pull request which should allow to use the tools on a rpi without either of the two flags, if you could confirm it works.
The changes are easy to manually add,
Ok I added the changes from the pull-request.
removed the lime command from /usr/bin
and ran haxelib run lime setup -rpi
but it still complained unless I added the -rpi option.
I then realized that the raspberry pi 2 is an ARMV7 architecture and not an ARMV6.
So I added
|| PlatformHelper.hostArchitecture == Architecture.ARMV7
to your changes in CommandLineTools.hx
and
else if (output.indexOf (“armv7”) > -1) {
_hostArchitecture = Architecture.ARMV7;
}
to PlatformHelper.hx:
then ran lime rebuild tools -rpi
and now I can run lime without the -rpi option
I then created an tested and example project:
openfl create DisplayingABitmap
openfl test neko
but it trows an error:
./DisplayingABitmap: 1: ./DisplayingABitmap: Syntax error: “)” unexpected
I was surprised to find a linux64-rpi folder under Export
any ideas?
if it helps: this is the contents of final.hxml that is created in my projectfolder
/home/pi/openfl/DisplayingABitmap/Export/linux64-rpi/neko/haxe/
-main ApplicationMain
-cp /usr/lib/haxe/lib/openfl/3,2,2
-D openfl=3.2.2
-cp /home/pi/software/lime
-D lime=2.5.2
-cp Source
-D lime-openal
-D openfl-next
-D tools=2.5.2
-D lime-cairo
-D no-compilation
-D lime-opengl
-D native
-D rpi=1
-D lime-native
-D lime-curl
-D openfl-native
-D linux
-D desktop
–remap flash:openfl
-cp Export/linux64-rpi/neko/haxe
-neko Export/linux64-rpi/neko/obj/ApplicationMain.n
–macro keep(“Main”)
-D final
Is that a compile time or run time error? Looks werid for both,
decomposing the test in build then run may make it easier to see.
It’s a runtime error.
There’s no errors building openfl build neko
But running any project openfl run neko , even an empty HelloWorld example results in
./HelloWorld: 1: ./HelloWorld: Syntax error: “)” unexpected
I’m trying to understand the toolchain (I’m completely new to haxe and neko)
so I can figure out what is building/creating the linux64-rpi
cause it looks like there’s some other part not finding the right architecture…
If you can build the Lime tools and run them, that’s a good sign – it means Haxe and Neko are working properly, at least to a point 
Could you do openfl test neko -verbose and see what you get?
EDIT: Oh, sorry, runtime error. What happens if you do a C++ build? openfl test linux -rpi -verbose
below is the output of openfl test linux -rpi -verbose
the line
PlatformHelper.hx:69: Detected host architecture: ARMV7
in the gist comes from a line added by me ,trying to see if scripts detect the right architecture
Ok, interesting, the haxelib run hxcpp command is being called with the -DHXCPP_M64=1 option.
If I manually call this command but exchange M64 with M32 it appears to compile without errors.
Ok that kinda worked…
I tried openfl test linux -rpi -verbose
then manually ran
haxe Export/linux64-rpi/cpp/haxe/release.hxml -D HXCPP_M32
and
haxelib run hxcpp Build.xml -DHXCPP_M32="1" -Ddesktop="1" -Dhaxe3="1" -Dhaxe_ver="3.103" -Dhxcpp_api_level="311" -Dlime="2.5.2" -Dlime-cairo="1" -Dlime-curl="1" -Dlime-native="1" -Dlime-openal="1" -Dlime-opengl="1" -Dlime_cairo="1" -Dlime_curl="1" -Dlime_native="1" -Dlime_openal="1" -Dlime_opengl="1" -Dlinux="1" -Dnative="1" -Dopenfl="3.2.2" -Dopenfl-native="1" -Dopenfl-next="1" -Dopenfl_native="1" -Dopenfl_next="1" -Drpi="1" -Dtools="2.5.2" -DHXCPP_M32 -verbose
in the DisplayingABitmap/Export/linux64-rpi/cpp/obj dir
and then waited a long time
then copied the ApplicationMain over to the bin directory, started xwindows and doubleclicked ApplicationMain
I found a line in RunScript.hx in Lime Tools that I think needs to be updated:
line 84:
if (PlatformHelper.hostPlatform == LINUX && PlatformHelper.hostArchitecture == X86) {
I think that should be:
if (PlatformHelper.hostPlatform == LINUX && ( PlatformHelper.hostArchitecture == X86 || PlatformHelper.hostArchitecture == ARMV6 || PlatformHelper.hostArchitecture == ARMV7)) {
and then
lime rebuild tools
now I can run
openfl test linux -rpi
without errors.
I have started on a fresh raspbian installation, but I’m stuck again with 64bit errors. Guess I did something else that I have forgotten about. Will elaborate soon
It might also work if both hxcpp m32/m64 defines are omitted, might be an issue with the HXCPP tools?
I got it running again.
I am writing down what I did and will run through it one more time from a fresh install of Raspbian.
( feel free to comment )
here is the preliminary gist link:
https://gist.github.com/gepatto/3e7c00c0d437cc783e5d
I am using dev versions from git. (except for format and the openfl-samples and lime-sample packages)
There are 4 files in the lime package that need to be replaced.
I had a problem where I had to copy the hxcpp/lib/linux/ dir and rename it to hxcpp/lib/RPi
I’m gonna see if that’s now still the case
I can confirm that for me the instructions on my Gist page are working.
at first I thought hxcpp wasn’t creating the ndll files in it’s lib directory, but I’ve tried it 3 times now and all seems well.
I’m able to compile the DisplayingABitmap example.
I can also compile the PiratePig example, but it’s reeeally slow.
unfortunately anything that uses a textfield (and is added to the stage) will just make the app crash on startup
with a segmentation fault, even the AddingText example
Built with openfl build linux -rpi -debug
gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x7411d8c4 in INT_cairo_set_font_options (cr=0x0, options=0x71c46d48) at ./lib/cairo/src/cairo.c:2929
2929 if (unlikely (cr->status))
Is that using haxelib or dev OpenFL?
I was pretty sure that I had the latest git version.
But I threw away my dev openfl folder and did a new clone of the openfl master.
Now it’s working 
!! ( at 3FPS 
)
I’ll continue testing the other examples., and write about my findings.
Thanks again for all the help…
Edit: I now see there have been a bunch of text fixes in the repo the last two days, guess they fixed my problem too.
the revision I had was from 6 aug.
Which project is running at 3 FPS? Can you tell if it uses hardware, or software rendering?
I added the Openfl.display.fps to the stage on the DrawingABitmap Example and the AddingText Example they both ran at 3fps
Can you tell me how I would be able to see if it’s doing hardware-rendering or not?
I’m more than happy to do the testing.
I am not sure if a good way to tell if hardware is for sure working (perhaps trying an OpenGLView or HerokuShaders sample) but you can force software like openfl test linux --window-hardware=false