Suggestion: OpenRA on Raspberry Pi 4

[Metadorius]

We now have experimental OpenGL driver for Raspberry Pi, so maybe we also can launch OpenRA on Raspberry Pi 3 (as it's the most powerful Pi for now)?

[pchote]

I had an experimental OpenRA / GL ES branch back before the pi3/gl support, and the game struggled to reach even 2 FPS. I doubt that the pi3 would give the 15–20x improvement that we would need with our current rendering architecture.

[Metadorius]

https://www.raspberrypi.org/blog/another-new-raspbian-release/

The thing is that previously software rendering was used, but this experimental driver brings hardware acceleration, which is much faster, and the Pi 3 itself is more powerful thatn Pi 2.

I'm not pretending that it'll run as good as on PC, but I'll be very happy if it will run playable at all :)

[Micr0Bit]

i did test this , you can actually run OpenRA on a RaspberryPi 3 ... but it is not playable.
Turning gpu_mem to 512 didnt do much of a difference

@Metadorius : you can do the steps explained here : https://github.com/OpenRA/OpenRA/wiki/OpenRA-on-RaspberryPi#how-to-set-up-a-dedicated-server in order to run OpenRA afterwards

[svein83]

@Micr0Bit : Uhhhh... Why the h*ll would you set gpu_mem to 512MB? :P That would STARVE the rest of the system, and forcing it to swap to a SLOOOOW SD card :') I'd bet big bucks that lowering the resolution to something like 1366x768, 1280x720 or even 720x480, and limiting GPU RAM to max 64MB would boost the performance a lot... If it needs a lot of RAM, maybe use a faster storage device than the SD card for swap. Try an old SSD on an USB2SATA interface

[yaaaaa]

Hmmm... Pi use ARM CPU, and what about execute Openra on ARM laptops, wich work on more powerfull Smapdragon 835 CPU and Windows 10 ARM based images builds?

[svein83]

If it builds, and if the hardware is powerful enough, it will probably run. 17. feb. 2018 11:43 skrev "yaaaaa" <notifications@github.com>: Hmmm... Pi use ARM Processor, and what about execute Openra on ARM laptops, wich work on Smapdragon 835 and Windows 10 ARM based images builds? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12231 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYSiDEIHaH6O8aewpfsR65o8Zkjm6v3Pks5tVq1mgaJpZM4KXs1L> .

[pchote]

I've been able to get the RA mod running on the new 3b+ at 25-30 FPS. This required invasive changes that can't be merged upstream in their current form, but it proves that it is feasible to optimize OpenRA to run well enough on this platform.

[pchote]

A comparison of release-20180307 vs what I expect for the next playtest (not including my invasive changes):

A significant improvement, and there are still several areas that we haven't looked at yet where I expect we can win more.

[clowrey]

Would be really cool to have an RTS like this running on the Pi! When it is a downloadable binary I will try :)

[svein83]

Well... No wonder this is not running well on the pi... I tried building and running this on my x86_64 laptop in Arch Linux, and even an i5@3ghz with HT and 12 GBs RAM is struggling... It just about maxes the CPU, and even freezes completely for ~1 second every now and then...

There's clearly something terribly wrong in the codebase.

The original game ran VERY well on an i486DX2@66Mhz with 16MBs of RAM and a 1MB VGA card... If this re-make was done well, even a pi2 should NOT have any problems running it since that has around 50 times the CPU power, and 64 times the amount of RAM of said i486 machine.

[pchote]

@svein83: the behaviour you describe is obviously not normal. If that really was the status quo, then the game would not be playable for anybody. Something about your system must be triggering an issue, but this is not the right issue to diagnose that.

[svein83]

OpenRA has some improvements over the original games, but those improvements clearly come at a cost...

Running the original game in dosbox is faster on my RPi3.

That is a clear indicator of something gone wrong. Dosbox has to emulate the intel architecture (cpu, chipset, graphics and sound), and then run everything on top of the emulation.

A port/re-make SHOULD imho be more optimized than emulating another architecture plus running the original game in that emulator.

[pchote]

OpenRA does not a project that directly reverse engineers and adapts the original executable code. Take a look at RedAlert++ for a project that follows that approach.

OpenRA comes at the problem from the other end - starting from scratch, build a game engine that leverages modern computer's capabilities that performs well enough on 2010+ era computers, but otherwise prioritizes flexibility and ease of use (for developers/modders). If you want something that can run on a 486, then this is the wrong project for you. You are welcome to disagree with this philosophy, but please stop asserting that this is somehow wrong or a failure of the project.

[svein83]

If I would want something to run on an i486, I would install the original game, and not wait for an open source re-implementation that isn't yet available to the public.

I'm not saying your philosophy is wrong or a failure.

I'm not saying what you should, or shouldn't do.

I'm only trying to illustrate the massive amount of raw cpu power and system resources you are wasting on god knows what.

I'm sorry if I offended anyone in doing so.

[pchote]

Something is very wrong if the system you described above is struggling. Please file a new issue if you would like some help diagnosing and fixing that.

[svein83]

Thanks, but no thanks. I'll wait for something that runs on a Pi. And that doesn't require .NET/mono.

[kneekoo]

@svein83, I just tested the AppImage 20181215 release of the game on my old laptop with a Core 2 Duo T9550 2.66 GHz CPU, 4 GB RAM (DDR2) and a Radeon HD 3470 GPU. The game runs smoothly. There's a minor visible lag, but it's so small that it doesn't ruin the game experience - no freezes and no frame drops. The framerate occasionally drops to 26-28, but normally it's between 30-34 FPS.

I use an SSD (Samsung 850 Pro 256GB), so that certainly helps, but the CPU and GPU are clearly enough for the game's requirements. Running in full screen at 1280x800, the CPU usage goes up to 45-50%, which is great for this PC, considering I have around 10% CPU usage before I start the game. Your hardware is a monster compared to my old laptop, so the issue you encountered obviously doesn't affect everyone and it would help if you'd run a few tests and share more details with the developers.

P.S. My OS is Linux Mint 19.1 64-bit, Cinnamon.

[ghost]

@pchote , could you open a new branw with the things have you changed. I like to test it. 25-30 fps its a playable spot.

[ghost]

@pchote could you send me the changes at least??

[ghost]

I am talking about your invasive changes

[ghost]

Ive tried some of your forked braches and they wont work on my rpi3 , ive tried gles2 and the pitest ones. Could you guide me a bit on what branch I need to checkout @pchote ??

[pchote]

My different pitest branches were trying out various experiments - some that worked, others that didn't, and one that depends on external hardware - and really aren't suitable for others to experiment with. Sorry, but I can't help with those. I still plan on trying to integrate the remaining performance improvements upstream at some point, but right now i'm focusing on other areas of OpenRA.

[ghost]

Ok, keep on it. Best luck.

[pchote]

OpenRA runs reasonably well on the new Raspberry Pi 4 - out of the box (current bleed with no custom changes) a RA skirmish game at 1024 x 768 held stable at 25-30 FPS.

The standard OpenGL support remains limited to 2.1 in the current driver, but GL ES 3.0 is available. This is great news because we can now move ahead with modernizing the renderer and raise the minimum requirements to GL / GL ES 3 while keeping support for the Pi 4.

[clowrey]

can you add a compiled copy into the future releases? and maybe into the Raspbian package manager
eventually?

[ghost]

@pchote Ive compiled it today. How to force to use opengl 2.1??? because the actual state of opengl 3.0 ES is not good at all!! it would be wonderful if you use cmake on future development, because I dont know how to change any variable here.

[ghost]

Okay, when you changed that so I could do a hard reset

solved ...91c6303
https://youtu.be/R9ZJlERSrhs

[quicksilver7837]

Now that the pi 4 fully supports openGL ES 3.1 is it possible to get openra up and running? Are their build instructions I could follow?

[pchote]

The general Linux build instructions should just work on the Pi 4 - I make sure that this remains functional whenever we change something that might affect it.

[quicksilver7837]

Thank you! I will try it out. :)

[bggardner]

Just successfully compiled on an RPi4-4GB using the Linux build instructions. Note that Mono 5.18 did not have msbuild, so I had to upgrade to the latest (6.8). I'm getting more like 10-15 FPS with the current bleed. Any idea why it's so much slower that what you experience, @pchote? Maybe recent code changes? I wasn't able to successfully build older releases to compare.

[quicksilver7837]

I noticed that the display resolution greatly affects openra performance on the pi 4. What res are you running in? @bggardner

[bggardner]

I tried at 1440x900, then 1024x768 with a slight improvement. I was able to compile the 20200202 release and it was slightly faster, but not 20+FPS. Windowed/Fullscreen doesn't seem to make much difference either. In any case, it's still very playable.

[quicksilver7837]

Overclocking the CPU helps as well. I'm at 2050mhz.

[ghost]

@pchote you mention other open source projects on red alert than are lightweight than this one. Could you please post a link to them??

[pchote]

Chronoshift (previously known as RedAlert++, which I referenced above) aims to recreate the original game logic by reverse engineering the compiled binaries, and therefore has the same performance requirements as the original game. For the same reason, it will only run on Windows for the foreseeable future.

[bggardner]

I updated the wiki page for running on a Raspberry Pi, including a quick-start for the RPi 4.

Also, while trying to compile from the latest release using git checkout release-20200503 then make version, the version string was assigned to playtest-20200426, preventing multiplayer. It appears multiple tags were assigned to the same hash, or I'm doing something wrong. Let me know if I should open a ticket.

[quicksilver7837]

@bggardner are you running openra using desktop environment or window manager? When I attempt to run openra from the command line on raspbian buster lite (no desktop environment) I get an error message saying: "unable to init server: could not connect: connection refused (zenity:18040): Gtk-warning cannot open display.

I have gotten openra to boot launching the mods manually (with the help of pchote) but it seems I cannot get the default launcher to work right.

[bggardner]

I'm launching from a terminal window in the desktop environment. That probably explains my slow performance, but at least it runs. I'm not sure how to get it running without an X server (desktop environment). More info: I get a System.InvalidOperationException: No supported OpenGL profiles were found. error, which isn't surprising as glxgears can't open a display either, even aftert exporting a DISPLAY environment variable. We'll need some assistance with this. To run OpenRA without a desktop environment, try xinit /home/pi/OpenRA/launch-game.sh Game.Mod=ra -- :0 vt$XDG_VTNR.

[yoyojacky]

Just successfully compiled on an RPi4-4GB using the Linux build instructions. Note that Mono 5.18 did not have msbuild, so I had to upgrade to the latest (6.8). I'm getting more like 10-15 FPS with the current bleed. Any idea why it's so much slower that what you experience, @pchote? Maybe recent code changes? I wasn't able to successfully build older releases to compare.

[strike]Could you please tell me how to upgrade your Mono from 5.18 to 6.8 ? I met the same problem that msbuild is not found on my raspberry Pi 4B...[/strike]
I tried following steps:

1. sudo apt install apt-transport-https dirmngr gnupg ca-certificates
2. sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
3. echo "deb https://download.mono-project.com/repo/debian stable-raspbianbuster main" | sudo tee /etc/apt/sources.list.d/mono-official-stable.list
4. sudo apt update
5. sudo apt-get -y install mono-devel

It works now. thanks for your tips.

[bggardner]

@yoyojacky You will have to expand. Did Mono install properly? Do you get error messages, and if so, what steps are taken to reproduce them? I just updated Mono to the latest (6.10) and was still able to compile and run successfully.

[yoyojacky]

@yoyojacky You will have to expand. Did Mono install properly? Do you get error messages, and if so, what steps are taken to reproduce them? I just updated Mono to the latest (6.10) and was still able to compile and run successfully.

yes, it is my bad, I have already fixed it, I removed all of the mono* by :
sudo apt remove mono*
sudo apt-get clean all
sudo apt-get install -f
and then reinstall it again by using:
sudo apt install apt-transport-https dirmngr gnupg ca-certificates
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
echo "deb https://download.mono-project.com/repo/debian stable-raspbianbuster main" | sudo tee /etc/apt/sources.list.d/mono-official-stable.list
sudo apt update
sudo apt install mono-devel
and then according to the INSTALL.md to install the SDL and other liberaies.
it work fine now, thanks for your tips! have a nice day~

[DanAE111]

I've got a PineBook Pro should that be helpful for testing in general on ARM devices. Gave it a quick shot but not able to compile anything at this stage. Looks like msbuild is missing.

OpenRA requires the 'msbuild -verbosity:m -nologo' tool provided by Mono >= 5.18. make: *** [Makefile:141: core] error 1

Compiled on another machine and gave running it a shot failed to initialize the renderer. Can get more in depth detail if anyway wants it.

OS: Manjaro Linux 20.10 aarch64
CPU: Rockchip RK3399 SOC
GPU: Mali T860 MP4

[Exarkuniv]

i followed the instatuctions on your Wiki page to build on the Pi.
i was able to build it fine once i figured out how to get .NET 5 to install
im running Retropie so i dont have a desktop. so i use xinit /home/pi/OpenRA/launch-game.sh Game.Mod=ra -- :0 vt$XDG_VTNR

and all i get it a pick mod window. i cant get it to start by picking anything since i have no mouse pointer. (i think its on my end for that part)

im just not sure why im getting the pick mod window since im telling it what mod to use

[quicksilver7837]

@Exarkuniv Try launching using: XINIT:/usr/bin/mono /home/pi/OpenRA/OpenRA.Game.exe Game.Mod=ra Game.LockMouseWindow=true

You can change out the game mod to cnc for command and conquer or d2k for Dune 2000

This is what I am using to run OpenRA and have no issues on my pi 4

[Exarkuniv]

@quicksilver7837 I have tryed that. it used to work, but i think they have changed things up a bit. as the OpenRA.Game.exe is not in the root dir anymore its in /home/pi/OpenRA/OpenRA.Launcher/obj/Release

they now i have a .sh file in the root dir
im using the current build.

if i knew what versions you used i could build it and use your way since i know it worked at some point

[quicksilver7837]

@Exarkuniv Ill have to check which version I'm using. It's probably about a year old at this point. Something to check into is the newish requirement of OpenGL 3.2, the pi 4 is only capable of OpenGL 2.1. I wonder if this is what is causing you issues with your latest build. I see that openra also supports OpenGLES 3 which the pi 4 is capable of but not while using xinit. Xinit uses full desktop OpenGL.

[Exarkuniv]

@quicksilver7837 Yeah i have no c;lue at this point on that. im not getting a crash when it starts. but ill try LockMouseWindow=true and see if i get the mouse to work and see if i can get the game to start.

when maybe someone with a bit more knowledge on this can give some pointers. since i am using their Wiki on how to build for the Pi

[bggardner]

For me, non-desktop launching only works if I run ./launch-game.sh from the current working directory using the relative path, otherwise it crashes. Using the absolute path results in your issue (pick mod window). So, per the instructions on the wiki, make sure you are in the OpenRA directory first, then run this exactly: xinit ./launch-game.sh Game.Mod=ra -- :0 vt$XDG_VTNR

OpenRA uses OpenGLES 3 on the Pi.

[Exarkuniv]

@bggardner that seems to be what i was doing wrong. once i did it from the working dir it started no issue

thanks

[padremayi]

Using xinit ./launch-game.sh Game.Mod=cnc -- :0 vt$XDG_VTNR. On Raspberry Pi 4 the performance are not good, tried to build a Power Plant, 12 seconds, and start a timer on my phone: game time is not the real time, conversely on my laptop it is ok.

Tried to play at 1024x768, better peformance but, again, the game is slow. For my point of view is not playable on Raspberry Pi 4

[darcyrush]

https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/

The new pi OS image officially supports a higher turbo clock speed for newer Pi4s. This might squeeze a few extra FPS for anyone who didnt overclock manually.

[Mailaender]

can you add a compiled copy into the future releases? and maybe into the Raspbian package manager eventually?

https://flathub.org/apps/details/net.openra.OpenRA provides aarch64 builds pre-packaged.

[Mailaender]

flatpak run --nodevice=dri --command=openra-server net.openra.OpenRA to run it headless.