SFML with hardware accelerated graphics on the raspberry pi

[raygun]

EDIT MAY 1, 2016: USE THIS INSTEAD: https://github.com/mickelson/sfml-pi

Hi all,

I've been playing around with SFML on my raspberry pi and I've managed to get SFML's openGL ES implementation working with the pi's graphics hardware.

I've look around a bit and haven't been able to find much about people successfully using SFML for graphics on the pi, so I thought I'd post what I've got in case it is useful for anyone else.

What I've got is fairly rough and only works for a fullscreen window.  The code is in the rpi branch of: https://github.com/mickelson/SFML

It's working for me on the most recent version of raspbian wheezy.  The cmake command should look something like this:

Code: [Select]

cmake -DEGL_INCLUDE_DIR=/opt/vc/include -DEGL_LIBRARY=/opt/vc/lib/libEGL.so -DFREETYPE_INCLUDE_DIR_freetype2=/usr/include -DFREETYPE_INCLUDE_DIR_ft2build=/usr/include/freetype2 -DGLES_INCLUDE_DIR=/opt/vc/include -DGLES_LIBRARY=/opt/vc/lib/libGLESv1_CM.so -DSFML_BCMHOST=1 .


[Hiura]

Pretty cool! 

I hope some other pi-user can confirm that.

[texus]

I can confirm that a full screen app works.

I tested on a recent raspbian too, but with a lot of packages from jessie installed.

I didn't have to set FREETYPE_INCLUDE_DIR_freetype2 and FREETYPE_INCLUDE_DIR_ft2build manually when calling cmake, but it might be because I have cmake 3.0. I do remember that I had to pass some directories for freetype when I still had a clean install last month.

[Mario]

Interesting. Looked into the Pi differences myself last year but didn't really bother to try it since it can get quite some PITA as you'd essentially have to manage the surface yourself, update/scale/move it with your window, etc.

Would be nice being able to omit X as a whole, considering it's not really used anyway.

Edit:
Why the "SFML_BCMHOST" define? Couldn't you hardcode it specific to the Raspberry Pi as a platform? I'm quite sure there's some CMake variable to check.

Edit 2:
According to Stack Exchange you should be able to use the following in CMake:

include(CheckIncludeFile)
CHECK_INCLUDE_FILE(/opt/vc/include/bcm_host.h BCMHOST)

[raygun]

Interesting. Looked into the Pi differences myself last year but didn't really bother to try it since it can get quite some PITA as you'd essentially have to manage the surface yourself, update/scale/move it with your window, etc.

Would be nice being able to omit X as a whole, considering it's not really used anyway.

Edit:
Why the "SFML_BCMHOST" define? Couldn't you hardcode it specific to the Raspberry Pi as a platform? I'm quite sure there's some CMake variable to check.

Edit 2:
According to Stack Exchange you should be able to use the following in CMake:

include(CheckIncludeFile)
CHECK_INCLUDE_FILE(/opt/vc/include/bcm_host.h BCMHOST)

Hi Mario, I agree that it looks like it would be a pain to implement this much further.  Plus there seems to be next to no documentation available for dispmanx!  Luckily I only need a fullscreen window 

I thought about having an automatic check for the Pi, but decided to do the define because I didn't want to prevent people from building the software rendered version on the pi if they wanted to (seems possible given the limitations on this atm).

check_include_file doesn't seem to pick up a full absolute path like what you linked from stack exchange.  I'm pretty green when it comes to cmake but I think you need to do something like "if (EXISTS /opt/vc/include/bcm_host.h)" but I'm not sure whether that would work for cross compiles, etc.

cheers

[StDH]

i began to use SFML on rpi last year, my project was about recognizing simple shapes/faces on video-stream/camera/photos.

[Mario]

So an unmodified SFML would run with software renderer right now? Last time I tried it would only crash since X not providing any context (for obvious reasons).

[raygun]

I haven't tried lately.

A while ago when I was first experimenting I loaded the mesa egl packages that are available in rasbian and linked against those.

It worked but the speed was unusable for what I wanted

[natinusala]

So is that usable for a project (mainly graphics and sounds) or absolutely not because of the latency ?

[Mario]

I'd say try it. From what I understood (still haven't found time to try it, yet alone get some branch up in the main project), this should allow you to run hardware accelerated, i.e. no lag/slowdowns (as fast as the Raspberry Pi runs whatever you write).

[natinusala]

I'll give it a try, I'll let you know the results

[natinusala]

I confirm that it works for a fullscreen app, I only tried a moving rectangle for now so I don't know how the performances are, I'll try to compile my true project as soon as I can get a working Qt SDK on the rasp.

[raygun]

In case anyone out there is actually using this, I've redone the implementation of sfml on the raspberry pi to bring it up to sfml's current master branch and to completely remove the X dependency.

I'm able to use this new version to run my fullscreen sfml application right from the rpi command prompt.

The code and instructions are here: https://github.com/mickelson/sfml-pi

cheers