Post new topic    
Slime
Send private message
Fufluns binaries for the Raspberry Pi 
 PostFri Feb 14, 2020 5:55 pm
Send private message Reply with quote
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.
Metal King Slime
Send private message
 
 PostSat Feb 15, 2020 1:02 am
Send private message Reply with quote
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)
Liquid Metal King Slime
Send private message
 
 PostSat Feb 15, 2020 2:21 am
Send private message Reply with quote
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? ;)
Metal King Slime
Send private message
 
 PostSat Feb 15, 2020 3:32 am
Send private message Reply with quote
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.
Slime
Send private message
 
 PostSat Feb 15, 2020 4:24 am
Send private message Reply with quote
Quote:
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.

Quote:
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.

Quote:
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.
Metal King Slime
Send private message
 
 PostSat Feb 15, 2020 9:12 am
Send private message Reply with quote
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).

Quote:
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.
Display posts from previous: