Is your setup gist still valid?
Thanks!
Is your setup gist still valid?
Thanks!
I think so, I will check right now cause Iām starting on a fresh SD-card
the part of about haxe and neko is still valid
installing hxcpp , lime, and openfl has changed a bit.
basically Iām getting them all from Github and doing a haxelib dev
for all of them
Iāll write a new gist along the way.
[update]
getting hxcpp from github doesnāt seem to work because that version seems to rely on haxe 3.2.0 (which doesnāt have a rpi binary yet)
so you need to get it via haxelib install hxcpp
[update 2]
gist setup is not complete
you need to recompile hxcpp first to get an ndll for RPi
but I already forgot how I did it.
I think haxelib run lime rebuild hxcpp linux -rpi
and
haxelib run lime rebuild hxcpp linux -rpi static
lime rebuild hxcpp linux -rpi -static
Well, when you do a fresh install, and get lime from git, the lime command doesnāt exist yet.
So I manually created it in /usr/bin/lime (or you can use /usr/local/bin/ )
sudo nano /usr/bin/lime
then enter the following:
#!/bin/sh
haxelib run lime "$@"
and save
sudo chmod 775 /usr/bin/lime
now you do
lime rebuild hxcpp linux -rpi -static
for people following this thread
this will all be solved when we have proper binaries,
I was still wondering why this happened with the hxcpp binaries you posted.
Could it be that it is expecting the Haxe std lib in a particular location ,
I have mine in /usr/lib/haxe/std/
,
or is it something else.
maybe the binary is not compatible for some reason, I built it from Ubuntu 12.04 for armhf, itās possible that it has a newer glibc version than Raspbian, or that itās not fully compatible (and wouldnāt run even on an Ubuntu Pi install, I need to test the builds)
I have a version running now that is using the rpi-driver and gles2.
I missed the change to BitmapData.hx in the repo where it it sets the correct internal format and format for gl.texImage2D.
So I figured that out by myself (took me long enough) only to see itās already in the repo.
Ah well, now I know a bit more about gles2 and how openfl is rendering Bitmaps.
( so no more black textures )
So thereās still some trouble with the rpi-mouse cursor that is able to go offscreen and then turns into a white square.
The PiratePig example is still only running at 3FPS (on a 1280x800 screen)
And on a second PI2 at 1080p the app dies after a few seconds.
The BunnyMark (on a 1280x800 screen)
is running at 32fps with 500 Bunnies , 25 fps with 3000 Bunnies, and 17 fps with 5000,
with 12000 Bunnies it dives under 10fps
The DisplayingABitmap that I modifed to have an FPS and a rotating Rect runs at 32FPS.
So some progress
Next up compiling with x11 instead of rpi-driver
I booted my Ubuntu install again, and tested the builds from the server. They work!
Thatās good news for ongoing Raspberry Pi support
Iām now running a Raspbian install. I updated the Haxe Linux install script, now itās working here on the Pi:
https://gist.github.com/jgranick/8cc40e2e0f277146725f
After installing OpenFL and Lime from the server, I get this error:
Main.hx:15: Hello World
Could not create SDL window: Could not initialize OpenGL / GLES library.
Could not create SDL renderer: Invalid window.
This is good news, while I wish it worked, it means the C++ is executing. I think SDL2 is looking for libEGL (etc) in the wrong location ā it seems to be ā/opt/vc/libā and not ā/usr/libā on the Raspbian distribution, which is strange.
Iām trying another build of Lime with a few tweaks, weāll see how it goes
GOT IT
A couple tweaks in SDL, and weāre in business
EDIT: now we just need to figure out why the Raspberry Pi is giving us slow performance
Yes glesv2 lies in /opt/vc/lib on rapsbian thatās why I was adding the extra paths and compiler flag in the Build.xml.
Awesome that you got it streamlined now. Iāll try an new install again.
In the PiratePig example the audio is choppy as well. (before it dies)
Iām gonna check if maybe audio could be the cause.
Also do you think It would be possible to choose the RPI-DRiver or the X11-driver with a build-flag?
Just want to confirm that the haxe/neko install-script works fine for me!
Lime and OpenFL now have Raspberry Pi support included, with the Linux installer script and a recent HXCPP build from http://openfl.org/builds/hxcpp it should work
We can continue to profile where the performance is going and find more ways to speed things up
[edit]
using
haxelib install openfl
and
haxelib run openfl setup
and the hxcpp from http://www.openfl.org/builds/hxcpp/hxcpp-3.2.102-72-g018b4fe.zip
openfl test linux
Errors out with Could not load module std@sys_exit__1
should this method already be working?
Iāll also keep working on getting a version that runs without X11.
It runs ok, but thereās a bug with the mouse and mousepointer.
Iām using libudev ( define it in SDL_config.h ! )
When I reach the bottom and right screenborders, the mousercursor gets garbled. Also when you move the mouse past the screenborder, say you move it X pixels further ( where X is an estimate) and you start moving the mouse in the oposite direction, you will have to first move that same distance X before the mousepointer will move again.
So it feels like it keeps adding a Delta to the mouse position somewhere, eventhough in SDL_rpimouse::RPI_WarpMouseGlobal the x and y stay within the screenrect
When we have all things running ok, I would like to start planning a hxGpio library that could use the GPIO port on the rpi.
about the SDL_rpimouse problem:
Looks like
vc_dispmanx_element_change_attributes
is not working the way youād expect when using ELEMENT_CHANGE_DEST_RECT
.
changed some code (see below) and now my cursor doesnāt disappear.
Next up is preventing relative mouse-movement to keep adding up beyond the screen bounds
this is what my WarpMouseGlobal looks like now:
/* Warp the mouse to (x,y) */
static void
RPI_WarpMouseGlobal(int x, int y)
{
RPI_CursorData *curdata;
DISPMANX_UPDATE_HANDLE_T update;
int ret;
VC_RECT_T dst_rect;
VC_RECT_T src_rect;
SDL_Mouse *mouse = SDL_GetMouse();
if (mouse != NULL && mouse->cur_cursor != NULL && mouse->cur_cursor->driverdata != NULL) { curdata = (RPI_CursorData *) mouse->cur_cursor->driverdata; if (curdata->element != DISPMANX_NO_HANDLE) { update = vc_dispmanx_update_start( 10 ); SDL_assert( update ); src_rect.x = 0; src_rect.y = 0; src_rect.width = curdata->w << 16; src_rect.height = curdata->h << 16; dst_rect.x = x; dst_rect.y = y; dst_rect.width = curdata->w; dst_rect.height = curdata->h;
ret = vc_dispmanx_element_change_attributes( update, curdata->element, 0, 0, 0, &dst_rect, &src_rect, DISPMANX_NO_HANDLE, DISPMANX_NO_ROTATE); SDL_assert( ret == DISPMANX_SUCCESS ); /* Submit asynchronously, otherwise the peformance suffers a lot */ ret = vc_dispmanx_update_submit( update, 0, NULL ); SDL_assert( ret == DISPMANX_SUCCESS ); } }
}
How does the performance compare? Similar? Faster?
good question, I didnāt notice any difference in cursor movement, except that Now it doesnāt disappear. Iāll add an fps and look at deltatimes to see if thereās a difference.
I found this solution in the Allegro Game Library http://liballeg.org/
Iām still searching why pirate pig is so slow, while the bunnymark can reach 30fps, I disabled audio but that makes no difference.
I found the culprit in PiratePigā¦ If I comment out
graphics.beginFill (0x000000, .3);
graphics.drawRect (-5, -5, 66, 66);
in Tile.hx
I get back my performance. Running at 49fps on my new Raspi Touch Display
Here it is
I havenāt got Touch working yet. I havenāt figured out where in SDL it is supposed to trigger the touch events.
The touch-device is found in SDL_udev.c as a ; /* ID_INPUT_TOUCHSCREEN */
but then nothing else seems to happen with itā¦
Any thoughts anyone?
Note to others:
Itās wise to add an Stage Key Eventlistener (escape key) that calls openf.system.System.exit(0)
Otherwise you canāt stop you app since all keyboard strokes will be sent to your appā¦
Now for a well deserved
Excellent work!
I finally managed to make configure a 3.5 TFT screen to use with my Pi, canāt wait to install and test Haxe and OpenFL on it during the weekend.
Iāll try following your gist and this thread and see how it goes!
Thanks for your hard work on this!
The latest commit on OpenFL (I think) fixes this issue. The current version of the sample uses alpha 0, which is supposed to avoid rendering, but keep the bounds for processing hit tests. Also, have you tested using X windows, to see if the performance is similar when windowed like that?