Raspberry Pi 2 anyone?

Help
#83

Is your setup gist still valid?

Thanks! :slight_smile:

#84

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

1 Like
#85

lime rebuild hxcpp linux -rpi -static

#86

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,

#87

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.

#88

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)

#89

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 :smile:

Next up compiling with x11 instead of rpi-driver

#90

I booted my Ubuntu install again, and tested the builds from the server. They work! :smile:

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

#91

GOT IT

A couple tweaks in SDL, and weā€™re in business :smile:

EDIT: now we just need to figure out why the Raspberry Pi is giving us slow performance

#92

:smile:

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?

#93

Just want to confirm that the haxe/neko install-script works fine for me! :smile:

#94

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 :wink:

#95

Great Work! :beer:
More than happy to keep testing.

[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

[edit]
I have just tried a pure cpp and sdl2 example, and get the exact same problem with the mousecursor and the pi-video-driver
So I have posted this in the SDL-Forum

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.

2 Likes
#96

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 );
    }
}

}

#97

How does the performance compare? Similar? Faster?

#98

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.

#99

:grinning: :tada:

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 :smile:

Here it is


(youtube link disapears) youtu.be/1HMr4egGwZI

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?

1 Like
#100

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 :wink: since all keyboard strokes will be sent to your appā€¦

Now for a well deserved :beer:

1 Like
#101

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! :smile:

#102

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?