EE on a Raspberry Pi 2

With the new version of Raspbian for the Raspberry Pi supporting the new experimental OpenGL driver (VC4), I was easily able to get EE running on the Raspberry Pi 2. No code changes, just some apt-getting, compiling SFML, then EE.

Here's some pictures of it running. Haven't played with it very much yet. Think I need a better power supply, as the screen likes to blink.

image

image

image
«1

Comments

  • Awesome ! :smiley:
    Even if I would maybe want something beefier for server, it would be perfect for clients (and making a truly portable bridge :smile: )
  • How does it perform on stations? One of the laptops I use has performance issues.

    Pi2 might be suitable replacements. But the screens I use are VGA. Still, with some investment, it would make the whole setup very clean...
  • It's using ~100% of one of the CPU cores for regular consoles. Sound was breaking up & screen flashes, but I think it has to do with my USB power supply. It did that on other OpenGL games as well.
    Haven't sat down and got CPU info for Main Screen. But so far it's pretty smooth.

    I have some HDMI to VGA converters that I use for my Intel Atom based Compute Sticks. Might try to get some more. I think they run about $10-$15 USD on Amazon.

    I want to see how the RPi B/B+ works. Might be too much for those though.
  • Did some actual play testing. The server was running on a PC, the client was the RPi 2. Had a crash when playing around in "Empty space". Not sure why. I then ran a Basic Scenario and had a crash. Played for a good 15 minutes or so. I did have some popping from the speakers on my TV, usually when the screen blanked for less than a second. My guess is the video driver is still buggy. Once the driver has matured, I think the RPi 2 would be suitable for regular play.

    I stopped Xorg (sudo systemctl stop lightdm) and ran it with xinit ./EmptyEpsilon. I ran it will all the consoles from 6/5 player crew. CPU was at ~95%. Ran it at fullscreen (1362x753) with disable_shaders=1.

    I also tested it running it as a Server & Main Screen (with disable_shaders=0). It did drop frames & audio dropped out on the Main Screen, but the CPU usage was actually sometimes less than as it was as a console.

    Ran it as a server with all the consoles from 6/5 player crew @ ~102% CPU, 4% RAM. Main Screen ran on the PC. Audio dropped out on the RPi here too with some occasional screen flashes.
  • Just a heads up. This will not work on the RPi B/B+/A/A+/Zero. It doesn't have support for the OpenGL driver.
  • It could work on the B/B+/A/A+/Zero. But you need to compile SFML for OpenGL ES support. As well as set the FEATURE_3D_RENDERING in featureDefs.h to 0. (This will disable mainscreen support, same as on Android)
  • kwadroke, what is your power supply ? If I recall correctly, a 2A power supply should be more than enough for the RPi.
  • daid said:

    It could work on the B/B+/A/A+/Zero. But you need to compile SFML for OpenGL ES support. As well as set the FEATURE_3D_RENDERING in featureDefs.h to 0. (This will disable mainscreen support, same as on Android)

    Actually, I started work on that last night after my post. I did compile SFML for OpenGL ES support and edited featureDefs.h. Took a while to compile and this morning I saw some linking errors.
    Fouindor said:

    kwadroke, what is your power supply ? If I recall correctly, a 2A power supply should be more than enough for the RPi.

    I was using a 1A power supply. Picked up another 2A Power Supply yesterday and used it. I also disabled warnings so the Rainbow Square doesn't show up as with this new driver it fills the screen.
  • The B/B+/A/A+/Zero linker problems are due to SFML. I'm working on fixing this.
  • Just replicated your results on the RPi2.

    Noticed the following things:
    * Got a bunch of crashes, most likely related to the experimental state of the 3D driver.
    * Relay station did not display properly, displayed everything as black.
    * When running as server, science did not seem to run at full speed. (Not a huge issue when you are a client)
  • Good to know the issues I saw wasn't just me/my Pi setup.

    If a solution for the the sfml-graphics compiling/linking problem can be found, it should work on the standard GLES driver for the Pi2 as well. This should hold us for clients until the GL driver matures a little. I've solved the xcb linking issue (mostly just an include), but it's having issues with GL/GLES calls.
    Pidora might have the fixes in it as it's in their repos, but haven't seen or tested it myself. Although rather see it work with Raspbian.

    I'm hoping to have this done before March 12 as it's our local Raspberry Pi event. Wanting to have a bridge setup using RPi B's as clients for EE.
  • I couldn't find how to install the closed source GPU driver on Raspbian. Any docs on that?

    I enabled the VC4 driver with raspi-config. And then it was pretty much a straight compile and run.
  • I've only used raspi-config to enable the "GL Driver" (aka VC4).
  • Found some info on the closed source drivers here:
    http://elinux.org/Raspberry_Pi_VideoCore_APIs

    Just putting it here for reference so I can find it later. Might try if I can get this to work on Thursday.
  • It supports OpenGL ES only, not OpenGL. The VC4 open source driver supports OpenGL.
    I've had problems getting SFML (sfml-graphics) to work properly with OpenGL ES. I've been able to get it to compile fine, but it's not linking properly, even though make completes successfully.
    I've got my Pi with me, so I'll get the output in an hour or two.
  • edited February 2016
    There's a new Pi coming out; the Raspberry Pi 3. Faster CPU, 64bit, Wifi & Bluetooth. Still $35.
    https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/

    I've ordered 2, so when they come in, I'll do some testing.
  • In theory, it should be able to work with the OpenGL ES, as that's what we have on Android.

    Only reason I care for checking out that option is because the VC3 driver is crashing and causes rendering problems with the science and relay stations.

    We'll see on the Pi3 when it hits. It has the same graphics chip, so I kinda expect the same output.
  • Here''s the issue I'm having with SFML using OpenGL ES. It's not a problem with EE as its before I even get that far. I know you where having some issues with Android & SFML. Is this something related to that?

    ldd libsfml-graphics.so
    undefined symbol: glFramebufferTexture2DOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glGenRenderbuffersOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glCheckFramebufferStatusOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glBlendEquationSeparateOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glBindFramebufferOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glRenderbufferStorageOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glDeleteRenderbuffersOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glFramebufferRenderbufferOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glBindRenderbufferOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glDeleteFramebuffersOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glGenFramebuffersOES	(/usr/local/lib/libsfml-graphics.so)
    undefined symbol: glBlendFuncSeparateOES	(/usr/local/lib/libsfml-graphics.so)



    Yeah, the issues should be the same with the Pi 3. I know there's some updates for Raspbian that you have to get that makes it work on the new System-On-A-Chip. Not sure if that will effect it or not.
  • You might need a customized version of SFML for the Pi

    There are some commits related to the Pi at:
    https://github.com/mickelson/SFML/tree/rpi
    As well as some custom compile options at:
    https://github.com/mickelson/attract/wiki/Compiling-on-the-Raspberry-Pi-(Raspbian-Wheezy)

    However, that version of SFML looks dated and might cause other problems.
  • I've tried that repo, but , now I'm not sure I was using the right cmake flags. Will try again.
  • edited March 2016
    The repo is too old but I got it to work with 2.3 after some changes. Compiling EE now to see if it will work.
  • EE compiled, but, I didn't get it to run on my Pi 1. Only had a few seconds to test on the way out of the house this morning.
    I know there was a message about the texture size not being powers of 2 (think OpenGL ES likes textures being that size). Not sure if that's the problem, but I know it Seg Faulted.

    Will hookup and run again to get the output in a few hours.
  • Just wanted to say this is all sounding pretty awesome! I keep trying with the idea of having some dedicated hardware for stations (currently pretty much playing BYOD when I get a bridge together) and this could make that much more achievable.

    Sounds like this seems to have the same sort of limitations as Android regarding builds? I keep promising myself I'll make time to figure out how to roll my own .apk for EE.
  • The VC4 build of EE does not have the limitations that Android has. The "closed source GPU driver" version would have the same limitations.

    Note that I also have a Olimex Lime2: https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2/open-source-hardware
    Bit more expensive then a Pi. But as it has a different (more common) GPU, I might get better results on that one.
  • I'm going to do some more testing tonight & tomorrow as I'm hoping to have a RPi bridge running this Saturday at the Raspberry Pi Bake Off event.

    I've got a Banana Pi & a BeagleBone Black I want to try out when I have time. My RPi 3 should hopefully be in soon. I'd love to see this working on a RPi Zero.
  • I just ordered a RPi Zero a few minutes ago, but I doubt I'll be able to get it in time for this weekend. My Pi3 is on backorder so no telling when it will come in.
  • The Pi Zero is a Pi1 at it's core. So expect the same performance, and problems. Also, getting one has proven difficult, as they have long lead-times everywhere. Lack of ethernet is a bit of deal-breaker for me. But, you could set them up with an Ethernet over USB connections to a central machine. If you power them with the same USB cable, you can have a very "low wire" setup.
  • I figured if I could get it working on the Pi1 it would just take a bit more to get it working on the Zero. Actually once it works on the Pi 1 it should work across all the Pis.

    I figured I'd use Ethernet over USB with USB2Go on the Zeros and use GPIO for input. I've had good luck so far with my Intel Compute Sticks with wireless & EE, so that could be an option too.
    I'm trying to squeeze out much as I can with all of the Pis. Especially since I have so many.

    If for some reason the regular clients don't work, I can always use them to access the httpserver. I planned on doing that anyway for the LARP.
  • I just did an OS & Firmware upgrade on the Pi 2 and still had the same screen blanking issue. The TV I use displays the screen resolution when it does it, so I figured it could be the TV itself having problems with the GL Graphics driver. I swapped it over to another TV and the blanking problem seems to have stopped when using this other TV. At least so far.
    I did disable the shader, but I did that when it was blinking on the other TV.

    Going to try this out on some DVI monitors with a adapter cable to see if the result is the same. If so I'll be setting up a few stations at the Raspberry Pi event tomorrow.
  • A couple of pictures from the Raspberry Pi Bake Off yesterday. Clients running on Pi2, mainscreen & server on Windows Laptop.

    image


    image

    Had some crashing issues when the ship was destroyed. They occasionally Seg Fault. I've seen the same issue on Windows XP. Will have to grab the RPT files from XP machines.
Sign In or Register to comment.