Fufluns binaries for the Raspberry Pi

Talk about things that are not making games here. But you should also make games!

Moderators: Bob the Hamster, marionline, SDHawk

Post Reply
lennyhome
Slime Knight
Posts: 115
Joined: Fri Feb 14, 2020 6:07 am

Fufluns binaries for the Raspberry Pi

Post by lennyhome »

Compiled in release mode with sdl video and sdl audio.

To install, download the official source package from the wiki, unzip it, then download this into the same folder and uncompress it as well.

I was able to play and edit many games I've also tried to re-compile and re-import game scripts whenever possible. Everything seems to work and as a game engine, it really suits the Rapberry Pi.

In the process, I've also bootstrapped and compiled Freebasic 1.07.1. You can get the binaries and html documentation in a single package here if you're interested.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Thanks! A couple of people have asked for an RPi package. I wish we provided official RPi packages, but it's not easy to set up a build machine/VM. I suppose the easiest way to do that would be to install a full distribution of Raspian under qemu.

Did you just run "scons" without an "arch=..." argument? I'm not actually sure whether "scons arch=arm" works properly or not. SConscript has some possibly dubious assumptions around arm and android, e.g. that fbc treats 'arm' as an alias for armv7-a but also accepts "armv7-a".

Ideally you'd provide a packaged version of the engine for arm rather than just binaries. To do that, just edit distrib-linux.sh, commenting out the two small blocks at the bottom with calls to package_for_arch, and add "package_for_arch arm". (Again I'm assuming that this actually works)
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

Hey! This is cool! Thank you, Lenny!

By the way, I recently got a Raspberry Pi 4. I haven't tried building the OHRRPGCE on it, but now I feel motivated to.

Why do a nightly build on a VM when we could use the real thing? ;)
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Indeed!
A year or two ago I tried building a gcc crosscompiler to compile for arm/raspbian, but it failed because the raspbian system libraries contained a lot of hardcoded paths so that it wasn't possible to simply mount the raspbian iso and point a crosscompiler at it. It might be possible to get compiling to work by using a chroot but that's tricky because gcc still needs to find all its own files.
Last edited by TMC on Sat Feb 15, 2020 3:36 am, edited 2 times in total.
lennyhome
Slime Knight
Posts: 115
Joined: Fri Feb 14, 2020 6:07 am

Post by lennyhome »

Ideally you'd provide a packaged version of the engine for arm
I suggested you overlay the RPi binaries on top of a stock source distribution because I'm not sure what files are required at runtime. I noticed that "custom" reads some text files for the help for example, but I'm still new to the internals of ohrrpgce.
I tried building a gcc crosscompiler
Consider that Raspbian is just debian arm-hf with some RPi specific bootcode added to it, but that has no impact on applications. The only issue could be shared library versions mismatch, but that's more of a general linux thing.
Did you just run "scons" without an "arch=..." argument?
I didn't have to specify arch=. There really isn't much ohrrpgce specific that I had to do. It's really it's just matter of getting Freebasic and Euphoria to work.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

lennyhome wrote:I suggested you overlay the RPi binaries on top of a stock source distribution because I'm not sure what files are required at runtime. I noticed that "custom" reads some text files for the help for example, but I'm still new to the internals of ohrrpgce.
Yes, it's distrib-linux.sh that bundles the correct files together. (Also you can run "scons install", which is equivalent to the standard "make install". It takes destdir and prefix args too (not envvars).
The only issue could be shared library versions mismatch, but that's more of a general linux thing.
I think the problem was .la files, which are text files parsed by libtool at link time, containing paths to the actual .so files to link, and other metadata. Though maybe the problem was .so files which were actually ld link scripts containing absolute paths to libraries. This is a distro-specific issue; Slackware for example got rid of all .la files to avoid this sort of problem.
Last edited by TMC on Sat Feb 15, 2020 9:25 am, edited 6 times in total.
Post Reply