My aging Windows laptop is dying and I’m not currently in a position to replace it, so I need to find an offline parser-based IF development system that runs on a Raspberry Pi 4.
Does anyone have any suggestions?
Search engine results were mostly for tutorials to code something from scratch.
wont most things run on it?
Apparently Ren’Py can be run on a Raspberry Pi 4, but be sure to check the wiki instructions for configuration requirements.
I am sure I am missing several good options that will work on the computer you want to use, and expect that parser-based options would be significantly easier to get running on a Raspberry Pi.
It has an ARM processor, so programs compiled for x86 or x64 CPUs won’t run on it.
You can always use Inform 6, the executable is up on the Archive: Index: if-archive/infocom/compilers/inform6/executables
You just need the execuatable for the Pi, and then the latest library set from David Griffith’s GitLab: David Griffith / inform6lib · GitLab
That and a text editor would do it. You could make games in I6.
Inform 6 comes from an era of trying to support as many different operating systems and architectures as possible, so it’s written as portably as possible and is as sparing with resources as possible. I have no doubt it’ll run on a Pi.
If you don’t want to be object-oriented, you can also find the old source for Inform 5 on the Archive. I honestly prefer the older version, but the lack of updates to the standard library is far more of a hassle than the class system.
Dialog is more recent and thus doesn’t try to support all the architectures from the 90s, but all you need to build it is a C99 compiler and Make, so that should also be fine on a Pi. I’d be shocked if it stressed the hardware resources at all.
Ah. understood. You could compile Inform 10 or anything else open source?
The command-line version of Inform 10 should also compile fine (I believe it ends up being just standard C in the end), but I’m not sure how it will do with the Pi’s limited RAM.
TADS definitely works fine on a Pi, and it’s hard to believe current Inform versions don’t. You’re not going to have any problems with computing power or memory writing IF. I used a Pi 4 for several months between computers. Your web browser will run slower than you’d like, but even that will be usable (maybe not with the lowest-memory model).
Inform 6 standard lib and punyinform, Dialog, Inform 7.10 and zilf all run well on my RPi 4 with 4 Gb.
Wow. I have never been able to get TADS to run on my RPi.
Can you share your installation method and OS. I typically run RaspiOS, but I could easily use a different SD card for an alternative.
I think I just compiled it? Not sure if it would have been Raspbian at the time or the Debian install I replaced it with. I can check on that later. This is a Pi 3… I don’t believe I messed with it on the Pi 4. I don’t remember doing anything special.
I was never able to TADS to compile correctly on the RPi 3 or 4. If you ever get a chance, let me know your compiling procedure.
Thank you.
I found a couple of other possibilities by going through my bookmarks.
DAAD has a precompiled 32-bit binary of its compiler available for the Raspberry Pi and it should be possible to compile the A-code system from the available C source.
Does anyone know if ALAN can be compiled for the Pi 4? The IDE seems to only be for Windows, but the other tools have Linux versions available.
I guess it’s more trouble than I remembered (or it wasn’t trouble at the time but is now). I’m getting some compilation errors. I don’t think it’s Pi-related though. Same thing on Ubuntu on a regular laptop and Ubuntu on the Pi. Going to see if I can figure it out though.
EDIT: Ok, so putting -std=c++98 in my CXXFLAGS and changing the > in line 1987 of vmtz.cpp to != got it to work on Ubuntu 22.04.1 with Clang 14.0.0, on the laptop. “It” being frobtads 1.2.3.
EDIT: Works on the Pi 4 as well. Same changes, plus for reasons unknown I had to add -lstdc++ and -lm to LDFLAGS (different compiler config I guess). It’s not convenient to test it on the Pi 3 right now, but I swear there’s no logical reason it would be different from any other machine. It’s just compiler settings we’re wrangling.
Any advice for cross-compiling inform 7 to ARM? I’m thinking of going down this road myself, but haven’t yet attempted it…
The procedure published by HannonO works for me. I used it recently to update my install.
These i7-helpers make building your story straight forward.
I appreciate your help on this. It would be very nice to have it on my RPi. I have tried numerous times with no luck.
Thank you, Jeff
My Rpi4 has inform6, dialog, and ScottKit. You can probably get all those running on any Rpi. The Rpi Zero W is not slow compared to the 486 I had in 1996 and I could run Inform on that.
The Rpi4 and probably Rpi3 are fast enough to also run many emulators so if you want to go retro you can probably run any old authoring system that ran in MSDOS or on an Amiga or any other last century system. Good thing about text games that they are portable and have low hardware requirements.
Some notes on cross-compilation (ie. building the inform project on an x86-64 machine, but creating binaries that can be run on ARM) since I finally got around to experimenting with this.
First: you can override the C compiler used by exporting CC in your shell. (For example, my cross compiler was named arm-linux-gnueabihf-gcc, and export CC=arm-linux-gnueabihf-gcc was enough to convince the Inform build tooling to use it for C compilation.
Second: while most of the built binaries will run only on the target system, inbuild needs to run on the build host, and should be built using the system compiler and not a cross compiler. This also means you can’t use the usual first.sh script to build everything. I ended up doing something like:
# First, build inbuild
../inweb/Tangled/inweb -prototype scripts/inform.mkscript -makefile makefile
make makers
make inbuild/Tangled/inbuild
# Finally, the cross-compilation step
export CC=arm-linux-gnueabihf-gcc
make tools forcekits forceextensions localintegration
If you need to run inbuild on ARM – conceivable, though most examples I’ve seen don’t use it – you may need to build it twice.
Of course, vastly easier to just build everything on whatever ARM system you’re targeting and save yourself the hassle!