I found this https://www.youtube.com/watch?v=1HMr4egGwZI @gepatto and couldn’t resist to tweet about it 
Yes that’s me… I was so happy I just had to show it 
I haven’t tested with x11 yet.
Not sure if in x11 it wil use gl-es rendering. (Last time it did software-gl)
But I will give it a go.
Yes it does!
with the alpha back at 0, the framerate is back up high in the 40’s without the lines commented out.
(sorry I the .3 in my post was one of the things I tried to see what was going on)
Awesome!
I think that using a window is probably ideal for Raspberry Pi by default, I wonder if we can use SDL set fullscreen to make that toggle fullscreen, so we get the experience (say, if you’re running on a RPi-powered gameboy )
There is something nice about the “close to the metal” nature of the other Raspberry Pi rendering method, but it feels jarring up against the other types of applications on the Pi. If someone ported Scratch to OpenFL (for example) you’d expect a window, not fullscreen 
I agree,
Being able to run in x11 in a window and optionally go to fullscreen, will be the best experience for non-developer users.
After reading in several places that sdl under x11 on the rpi was troublesome, i decided to first try from the console, because some people had tried that already.
Next week I will try and find out If sdl has hardware opengl-es under x11 implemented for the raspberry.
Then I’ll continue with the touch events for the raspi touch display.
Then there’s still the hxcpp issue from the binary from the build server.
I can work around it though.
I wasn’t able to install everything needed to compile haxe 3.2.0. I can’t get the ocaml installation right.
1 Like
So far everything points to X11 not being able to do hardware accelerated EGL/GLES ( for now).
I have searched a lot of sites and they all say the same.
I have tried various things and I can see that it loads the libEGL.so and libGLESv2.so libraries
(by adding a lot of printf statements) but is still complaining that it can’t create an EGL-display.
( which is exactly what I have been reading);
I see other libraries like openframeworks and allegro just create a ‘nativewindow’ on top and bypass x11.
But that means no window-handles etc. just a surface.
I have also seen that people have been trying to use wayland on the raspberry pi. Wayland does support EGL/GLES. But I think it will be a while before it comes available for the average RPi-user. https://www.raspberrypi.org/blog/preview-the-upcoming-maynard-desktop/
Does anybody now what window managers are ubuntu and archlinux using the pi?
by the way, with the mesa packages you can get a window but it will all be software and terribly slow.
So I’ll will focus now on forking lime and native-toolkit/sdl and put my changes for the windowless version in a repo, and then write a post on how to set it up on a clean install of raspbian.
This way more people can test and help improve it.
Ubuntu uses Unity (the WM).
Arch Linux has no default window manager. It fully depends on what the user installs.
So this means that the X11 setup is currently working, but the FPS is much lower than the fullscreen approach because it is not actually tapping into hardware properly?
Technically, it somehow needs to be possible if you take a look at Minecraft PI edition. It runs smoothly within X11 with OpenGLES. But you shouldn’t rely on my word or await anything constructive of me yet. Haven’t yet figured out how to get OpenFL running nor pure SDL with linc_sdl in my PI. 
@GagaPete
Ok so it looks like there is a special driver by Eric Anholt
https://www.raspberrypi.org/forums/viewtopic.php?f=81&t=115350
I’ll look into this.
@singmajesty
I had a version last week that was running in X11 but without hardware
it was doing software-gl , or cairo when you pass in --window-hardware=false
I kinda lost that setup hunting for an accelerated version.
But it should be close to what is in the repo’s right now.
[edit]
If you use --window-hardware=false the version from the normal lime repo will work.
If you use the code from my repo (mentioned in my blogpost, see below) both hardware-accelerated (fullscreen overlay) and --window-hardware=false (very slow) will work
1 Like
I have written a blog post on how I’m running openfl accelerated.
There are some instructions for people who would like to try.
This is just a test! and it won’t run in an x11 window
I hope that it’s ok to post the link here:
http://www.gepatto.nl/getting-openfl-to-run-with-hardware-acceleration-on-a-raspberry-pi-2/
Feel free to let me know about mistakes, coding errors or incomplete instructions.
cheers
3 Likes
Thanks for that. I followed your steps on Arch Linux ARM (I can provide the package list if someone needs it) and now the accelerated fullscreen option just works. I tried to compile the version from the lime repo before since I prefer a window over fullscreen for development but I can’t get it to work. So I’ll stick with fullscreen for the moment.
BTW, I started the first successful build with openfl test linux -rpi in a terminal and forgot about it while it compiled so I was pretty staggered when it started
Great job @gepatto and @singmajesty and the other people in this thread.
That’s good to hear!
It’s too bad that x11 doesn’t do opengl-es in it’s windows.
I had a look at the minecraft app, and I guess they have a standard x11-window for moving and resizing but there’s a native dispmanx surface on top.
Since this can not be done with sdl at the moment, windowed hw- accelerated openfl doesn’t seem to be an option.
So right now I’m gonna focus on other things like trying to get the pi-display to work, and research if I am capable enough to write an extension to access the gpio ports. On raspbian jessie access to gpio doesn’t require root priviliges anymore.
I’m still searching for a proper way to quit an openfl application from the command line on the Pi
When I start my app through an ssh-session, I can crtl+c the app and I can see that SDL is catching the event and does a proper shutdown of the subsystems
However on the pi itself all keyboard events are captured, so ctrl+c does not work.
When I call system.exit(0), the app shuts down but SDL_QUIT is not triggered and so the subsystems are not shut down, leaving evdev still capturing the keyboardevents. So then your command line is useless and you can only regain control via ssh.
Is there a handle back into the SDL_Application so we can manually call SQL_QUIT, or is there anothewr way?
This is propably very RPI-specific.
It sounds like System.exit should tell SDL to quit, instead of forcing the application to stop.
Perhaps System.exit should loop through all windows and tell them to close, SDL should quit once all windows are closed. After, it could call Sys.exit as it does. If SDL shuts down cleanly then it won’t hit the Sys.exit call, but if it does not for some reason, it will make sure it does close
I tried just calling close on the only window in my app
Lib.application.windows[0].close()
I can see that SDLWindow.close() is being called but it doesnt close/quit the SDL_Application.
I changed the NativeApplication.hx exit method to
public function exit ():Void {
AudioManager.shutdown ();
lime_application_quit(handle);
}
That does seem to do the trick, but I’m not sure this is a proper way to do it.
I now see UDEV_QUIT being called, and i’m getting my keyboard back in the console.
I have made a pull request for adding linker flags to lime project/build.xml in the rpi section
<lib name="-lbcm_host" />
<lib name="-L/opt/vc/lib"/>
Together with 2 extra defines in rpi/sdl_config.h
#define HAVE_LIBUDEV_H 1
#define SDL_VIDEO_DRIVER_RPI 1
these are now the 2 remaining requirements to be able to compile Lime with opengles2 en device input support.
With this you can still run in a window in x11 but only without HW-acceleration support and you will need to add the --window-hardware=false flag when compiling with openfl
b.t.w. I don’t think the changes to sdl_config.h are coming through on the pull-request
(maybe because of the detached head?)
If I am doing something wrong or there’s a better way to contribute my fixes please let me know
I have some fixes for proper mouse support for Rpi too.
And the fix I mentioned above for shutting down lime when exiting an openfl app on rpi.
But I want to make sure this is the right way to contribute my fixes.
Cheers
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.