Ok I know the heroku example runs ( does not crash) but shows nothing on screen .
I’ll try the other suggestions tomorrow ( I’m in the Netherlands)
So I Compiled the DrawingABitmapExample (with an added FPS) 2 times. Once with
--window-hardware=false
and once with
--window-hardware=true
the results are surprising. Below is a screenshot:
on the left is the one with --window-hardware=true running at 3fps
on the right the one with --window-hardware=false running at 33fps
so that’s the opposite of what I was expecting!
also I see that the cpu is only running at 50%
Main.hx:
package;
import openfl.display.FPS;
import openfl.display.Bitmap;
import openfl.display.BitmapData;
import openfl.display.Sprite;
import openfl.Assets;
import openfl.events.Event;
import openfl.system.System;
import openfl.text.TextField;
import openfl.text.TextFormat;
class Main extends Sprite {
public function new () {
super ();
var bitmap = new Bitmap (Assets.getBitmapData ("assets/openfl.png")); addChild (bitmap);
bitmap.x = (stage.stageWidth - bitmap.width) / 2; bitmap.y = (stage.stageHeight - bitmap.height) / 2;
var fps:FPS = new FPS(10, 100, 0x000000); addChild(fps); }
}
project.xml
<?xml version="1.0" encoding="utf-8"?>
<project>
<meta title="Displaying a Bitmap" package="org.openfl.samples.displayingabitmap" version="1.0.0" company="OpenFL" />
<app main="Main" path="Export" file="DisplayingABitmap" />
<source path="Source" />
<haxelib name="openfl" />
<assets path="Assets" rename="assets" />
<assets path="Assets/fonts" rename="fonts" />
<window background="#FFFFFF" fps="30" width="640" height="480"/>
</project>Same goes for the AddingShapes example, and there you can also see an artifact with textfield transparency
Could you try BunnyMark with software, and see how many bunnies you get?
Ah hah!
According to a forum thread, it appears that the Raspberry Pi falls back to a software OpenGL implementation if you use OpenGL code. That would explain how slow it is, and why Cairo would be so much more efficient. I think we can do OpenGL ES, though, and have that work properly. There’s a way to make SDL use an OpenGL ES context, if we could make that work, then I bet the performance would be ideal for the device 
Maybe something like this?
Ah software opengl , that makes sense. It sure didn’t feel like GPU
So we’ll try to get proper OpenGL-ES background running.
I did try this once by just compiling SDL2 and that did work.
I compiled it to run without X11 cause that’s mainly how my apps are used (musea and educational )
( would be awseome if we could get openfl to do the same, so you could boot straight into an app without x11 )
I tried forcing the SDL_GL_CONTEXT_PROFILE_ES ,
by commenting out the if statement and the SDL_Sethint line, in the block you mentioned
but then I get ( I did expect that to happen)
sdl not configured with egl support
So I guess we need separate compiler flags for sdl2 for raspberry pi.
maybe Raspberry Pi(2) should become a separate target ?
Oh yeah:
Maybe we can compile SDL on Linux to include both OpenGL and OpenGL ES support? I wonder if that would break other builds (maybe not)?
The simpler we can keep it, the better. The closer Raspberry Pi is to a Linux build that runs on a different processor architecture, the better, I think, since Ubuntu Touch and a whole host of other possibilities may stem from the same needs 
On that note, long-term, perhaps we should look at keeping the “Linux” NDLL directory, but adding a new suffix for the armhf architecture, or use “-v7” similar to Android binaries
Yes I have been trying whole day to see if I can enable opengl_es2 video and renderer in the sdl_config.h
( I see there’s even an SDL_VIDEO_DRIVER_RPI which probably should be used )
but so far no success.
I end up with what I think are linker-errors:
- Running command: arm-linux-gnueabihf-g++ -o …/ndll/RPi/lime.ndll -shared -fpic -fPIC -Xlinker --no-undefined @obj/linux-rpi-hfp//all_objs /home/pi/haxe/libdev/hxcpp/lib/RPi/liblinuxcompat.a -lpthread -lrt -ldl
obj/linux-rpi-hfp/3e48a037_SDL_render.o: In functionSDL_CreateRenderer_REAL': SDL_render.c:(.text+0x17d4): undefined reference toGLES2_RenderDriver’
obj/linux-rpi-hfp/3e48a037_SDL_render.o:(.data.rel.ro+0x0): undefined reference to `GLES2_RenderDriver’
collect2: ld returned 1 exit status
I also found that there’s a section in lime/projects/lid/sdl/files.xml called LIBSDL_RPI that doesn’t get included whatever I do.
If I force-include these (by taking them out of the section into the main part),
and define SDL_VIDEO_DRIVER_RPI in sdl_config.h
and append the needed include_paths for the rpi-specific headers in /opt/vc/include , /opt/vc/include/vmcs_host/linux/ (and 1 other that I have forgotten)
then in the end I get an additonal linker error
But I’m a bit out of my league here, I’m just fiddling around with some settings.**
Well, even without GLES, using software should be an alright workaround, enough to polish support for the device. So we need to 1.) zip up a Haxe install that we can use with the Linux installer script? 2.) do the same for Neko? 3.) make some changes so that using RPI works out of the box?
The more I think of it, the more I like the idea of using only ndll/Linux, but adding an additional suffix for v7, perhaps
For step 1 [ haxe ] I am using the 3.1.3 download from haxe.org
http://haxe.org/download/file/3.1.3/haxe-3.1.3-raspi.tar.gz
for some reason there’s no raspberry pi download link for v 3.2.0 but I will try and see if the linux32 version will work on rpi)
For step 2 [ neko ] there’s no download available , but I can compile a version, just need to know what bare minimum modules I should compile ( i.e I did not compile any apache modules, but did compile sqlite )
here’s a zip of the bin folder of the 2.0 version that I compiled from git and am using right now: https://db.tt/vtqZSiFk
For step 3 [ changes to lime ] in one of my above posts I have a link to 4 changed files in Lime. Although I can’t check them for a Raspberry pi Model B ( armv6) but I don’t think the model B is powerfull enough to run it anyway.
Maybe some can check my changes.
( or should I learn how to do a pull-request ? )
Hi again!
Sorry for the delay, I’ve just merged in your improvements for Raspberry Pi in Lime
No Worries,
I have started again from a new fresh debian wheezy trying to confirm
the steps I have provided above, but I think I there’s one small step I forgot to write down as I am getting errors compiling hxcpp because it is adding the -m32 flag that’s tripping up gcc on the armv7 architecture. I am now trying to find the differences with the sd-card that is working properly. Of course I can copy the hxcpp dir but I’d like others to be able to compile from source too.
I’m working my way through the entire toolchain right now, to see how everything ties together.
I’m also still trying getting hardware-acceleration via sdl and opengles2 to work.
I have copied a working SDL_config file from the latest SDL-source that is working for me outside of haxe, and is using the raspberry pi video and renderer classes. I have added a SDL_SetHint in SDL_Window.cpp and to force rendering via opengles2 and added the necessary lib flags to /opt/vc/include (and more) , but I am still only getting a black screen ( it’s not using x11 ) with some boxes but no textures and the framerate is not even 1fps and I am barely able to move the mouse. So there’s still a lot of work to do. I still might be missing something very obvious.
So If anyone can give me some pointers (not null 
they would be welcome…
Recompiling lime all the time just takes up a lot of time on the Pi …
Hi did you get any further on this? I have been working “unofficially” on getting the snõwkit tools snõw and luxe to work on the RPi2 and finally managed to compile a version that could do fullscreen + sound. (twitter.com/espenb/status/638117093930586112). I guess this would be similar to the lime layer in OpenFL.
I got stuff working after a lot of trial and error, and looking at the Net (the current OpenFL thread was very helpful - and also Joshua’s check-ins) - together with solarianprogrammer.com/2015/01/22/raspberry-pi-raspbian-getting-started-sdl-2/
I compiled with hxcpp and -DLIBSDL_RPI and included the necessary include/lib dirs from /opt/vc as you describe. The changes I made are included in my own fork of snõw on GitHub (the sdl and openal modules are also changed). At this point we are not focusing really hard at RPi, so I’m not sure when/if that would be included in snõw, also - the native layer are still undergoing changes since the libraries are still in alpha. -But at least it is an interesting excercise
There are some issues related to input (doesn’t work at all) and the luxe bitmap shader for now - and I do not have a good indication on framerate although the tests I have run so far seemed as “smooth as expected”.
You seem to have come a long way. One final issue for me was that I accidentaly linked to both the mesa GL library and the RPi GLESv2 library - this actually made the program run - but shaders etc. wouldn’t compile properly - with no real useful output. So that would be a tip from my side if you’re still struggling. 
OMG, can only put 2 links in the post 
Hey Dj Pale,
Actually I’m stuck at the moment.
Everything compiles but all I get are black rectangles and I have a problem with the cursor that can be moved offscreen and then only draws a white square.
I’m not sure what’s going wrong.
Maybe it’s an issue with alpha in DISPMANX or maybe it’s not loading textures or not ‘uploading’ textures to the gpu, or maybe It’s not really doing the native GLES2 calls
I can run a simple SDL-example in C (the one from solarianprogrammer)
So there’s no reason it shouldn’t work.
This is my first time doing anything with sdl and opengles so there’s a lot I need to figure out.
[ The SimpleOpenGLView example DOES work by the way ]
Oh, you have SimpleOpenGLView working, with hardware acceleration, not the software fallback?
Black textures could be non-PO2 support, or some other issue like that. Maybe try the “SimpleImage” sample from Lime, see if that works. I forget if the image is a power-of-two image, but if it looks black, try one that is
SimpleImage Works,
I added some printf statements througout the SDL classes and I can see SDL:
- using the RPI video driver
- using RPI_CreateCursor (which has some bugs)
- loading GLES_LoadLibrary
- Creating the GLES2_Renderer (render type opengles2)
- updating the Viewport (to fit fullscreen 1280x800: the size of my 10" hdmi screen)
btw I am running this from the command-line so no X11 ! I have disabled it in the SDL_config.h
I have Nativerenderer.hx Report that it’s using Opengl Context
and I see (because I added printf statements here too)
- 2 calls to lime_gl_attach_shader
- a call to lime_gl_create_texture
- a call to lime_gl_text_image_2d
If I swap the image in SimpleImage with the openfl.png from the openfl DisplayingImage example it still Works.
The lime example TextRendering also works
openfl’s DisplayingBitmap however still shows only the black Rectangle, even if I use the lime.png Image that IS working in the SimpleImage example.
I DO see the lime_gl_attach_shader and lime_gl_create_texture and lime_gl_tex_image_2d calls.
Feels like we are getting closer.
[ Edit ] Just tested the HerokuShaders Example and some of the Shaders are working while others Bring down the RPi2 to a complete stand still
So it seems most of the lime examples are working.
This is great,
With Lime samples working, it confirms that our stack (from a low-level) is operating. GL calls appear to be working, so now it is a logical issue – a bug in OpenGL support, or a tweak in how we need to (or should) attack platform support. SimpleOpenGLView also works, you said?
Yes it does,
Here’s a picture ( sorry about the moire, that’s the camera)
I have slightly modified the code so that the image is rotating every frame.
The black square is the FPS component I added to the example, that fails to render properly
in the same way that a openl.display.Bitmap is not rendering properly
I’m not able to test at the moment, but could you try this commit?
I think this might fix it
fingers crossed