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.
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.
Comments
Even if I would maybe want something beefier for server, it would be perfect for clients (and making a truly portable bridge )
Pi2 might be suitable replacements. But the screens I use are VGA. Still, with some investment, it would make the whole setup very clean...
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.
I stopped Xorg (
sudo systemctl stop lightdm
) and ran it withxinit ./EmptyEpsilon
. I ran it will all the consoles from 6/5 player crew. CPU was at ~95%. Ran it at fullscreen (1362x753) withdisable_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.
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)
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 enabled the VC4 driver with raspi-config. And then it was pretty much a straight compile and run.
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.
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.
https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/
I've ordered 2, so when they come in, I'll do some testing.
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.
ldd 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.
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 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.
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.
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'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 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 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.
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.