Detailed compile guide for Linux (Debian) 32bit ARM (Raspberry Pi)

[Duplo]

Hi everyone,
Is there any detailed guide to compile on linux that is beginner friendly. I am trying to get Simutrans Extended to run on a Raspberry Pi and I'm new to Linux, being a Windows guy.

[Mariculous]

I can't provide a guide specific to Raspberry Pi Debian but there are some general instructions in the readme:
https://github.com/aburch/simutrans/blob/master/readme.txt

Additionally you can try this guide for ubuntu http://spacethingy.weebly.com/compiling-simutrans-for-linux-beginners.html
However, I don't know if it works under Debian especially ARM arc Debian.

However, I guess there is no guide specifically for ARM and I don't expect it to wor out-of-the box blindly following these instructions.

I also want to note that you should not expect tooo much performance from Simutrans at your Raspberry.

[Duplo]

I can't provide a guide specific to Raspberry Pi Debian but there are some general instructions in the readme:
https://github.com/aburch/simutrans/blob/master/readme.txt

Additionally you can try this guide for ubuntu http://spacethingy.weebly.com/compiling-simutrans-for-linux-beginners.html
However, I don't know if it works under Debian especially ARM arc Debian.

However, I guess there is no guide specifically for ARM and I don't expect it to wor out-of-the box blindly following these instructions.

I also want to note that you should not expect tooo much performance from Simutrans at your Raspberry.

Thanks for your reply. However, I'm looking for a more specific one for simutrans extended as the compling for this version requires more twerking and I cannot just make install with it.

[Mariculous]

The instructions also work for extended.

I have compiled standard headless server builds and extended debug builds from source and apart from the settings of course, both worked just the same.

Edit: For sure you obviously have to clone (or download) the sources from the extended git repository instead of standard. https://github.com/jamespetts/simutrans-extended

And you also have to set

Code Select Expand


BACKEND = sdl2
COLOUR_DEPTH = 16

, instead of posix/0. Because you want a client instead of a headless server.

So give it a try.

If anything is not working and you guess it's specific to extended, please try to compile standard and reply here.

If you think it is an extended specific bug, plese file a bugreport.

However, while most code should compile just fine no matter the cpu architecture, I suspect there are some sections in the code that could cause problems when compiling for ARM.

[Duplo]

The instructions also work for extended.

I have compiled standard headless server builds and extended debug builds from source and apart from the settings of course, both worked just the same.

Edit: For sure you obviously have to clone (or download) the sources from the extended git repository instead of standard. https://github.com/jamespetts/simutrans-extended

And you also have to set

Code Select Expand


BACKEND = sdl2
COLOUR_DEPTH = 16

, instead of posix/0. Because you want a client instead of a headless server.

So give it a try.

If anything is not working and you guess it's specific to extended, please try to compile standard and reply here.

If you think it is an extended specific bug, plese file a bugreport.

However, while most code should compile just fine no matter the cpu architecture, I suspect there are some sections in the code that could cause problems when compiling for ARM.

Well I am in the process of compiling it and I wonder if the backend is set to opengl would it cause any problem?

[Mariculous]

I didn't try out the openGL backend but if I recall correct, it is or was work in progress, so I would not expect it to work. However, maybe I'm wrong.
sdl and sdl 2 should work. On Windows you could alternatively choose GDI (why is there no Nod, I'd prefer that)
posix is for headless server only, that means without user interface.
Don't know about mixer_sdl or allegro.

[Duplo]

I got it to finish compiling and now I have an even bigger issue with possible file system corruption

[DrSuperGood]

I got it to finish compiling and now I have an even bigger issue with possible file system corruption

I last used a RaspberryPi many years ago but I recall for file system storage one commonly used a SD card, which the user had to supply separately at their own cost.

There are a lot of fake SD cards available on the internet and even in shops. Some are obvious fakes, but the less obvious ones have reasonable capacities and reasonable prices and often use genuine images. Even legitimate and big retailers can end up with fakes mixed in with their legitimate orders. These fake SD cards are usually lower capacity flash chips with modified controllers to appear as the labelled size. Once the controller tries to use memory beyond the physical size data loss occurs. This could very easily explain the missing file errors as well as file system corruption occurring.

I recommend checking the SD card if it is legitimate. Most reputable manufacturers of SD cards like Samsung offer you a program to do this. There are also some third party ones which work by insuring that every advertised byte can be written to and read without data loss, however this will erase any data on the card.

[Duplo]

I last used a RaspberryPi many years ago but I recall for file system storage one commonly used a SD card, which the user had to supply separately at their own cost.

There are a lot of fake SD cards available on the internet and even in shops. Some are obvious fakes, but the less obvious ones have reasonable capacities and reasonable prices and often use genuine images. Even legitimate and big retailers can end up with fakes mixed in with their legitimate orders. These fake SD cards are usually lower capacity flash chips with modified controllers to appear as the labelled size. Once the controller tries to use memory beyond the physical size data loss occurs. This could very easily explain the missing file errors as well as file system corruption occurring.

I recommend checking the SD card if it is legitimate. Most reputable manufacturers of SD cards like Samsung offer you a program to do this. There are also some third party ones which work by insuring that every advertised byte can be written to and read without data loss, however this will erase any data on the card.

I got the card directly from an authorized reseller (Pimoroni) and I also reformatted and checked the card myself so I'm sure counterfeits isn't the problem here. My take on it is that the card may just couldn't cope with the load. Also, RPi file system corrupting is quite common. Anyway, I don't really have anything useful on the card so I just did a format and ran a new image.

[DrSuperGood]

My take on it is that the card may just couldn't cope with the load.

That does not seem likely as SD cards should be able to cope with any amount of I/O load. Under high loads their I/O speed should decrease a lot, especially with some models not intended for I/O speeds, but it should still operate very reliably. Unless there was some sort of driver bug.

[dustNbone]

I have built the nightly code on a Pi4 with Raspbian, SDL2 frontend and I'm actually quite shocked that it performs quite well.

As far as I remember (I did the build last week but only got to testing it this morning), all dependencies were available in the Raspbian repository.  I will write a fresh Raspbian install to an SD card and write up a guide with the necessary dependencies, and any compiler flags I determine to be beneficial.  I will only target Pi 4 (Cortex A72) because I don't think earlier versions will offer a playable experience in Extended.

I haven't bothered packaging it into a .deb yet, I'm probably going to fiddle with build options a little more.  I just downloaded the Windows binary/pakset zip, extracted it into a folder and dumped the simutrans-extended executable I compiled in there. 

Everything ran as normal, obviously the CPU is what it is, a huge step up from previous Pis but still fairly weak compared to what we're used to in our PCs.  I started a 1024x1024 map with 30ish cities and played for an hour or so, I didn't run into any walls performance wise, scrolling with time running can get a bit chunky but paused it's quite smooth.  I will play more.  For science.

I'm not sure what the status of the openGL frontend is,  but I suspect that could offer substantial gains in user experience if not in raw performance.  The Pi4 has a decent GPU, now with proper OpenGL 2.x drivers enabled, it would be nice to lean on that capability to take some load off the CPU.

If the demand exists, it wouldn't be too much trouble to set up a cross compile environment on my server PC and have nightly builds of just the executable binary, as that's the only part that's unique to the Pi/ARM platform.  It might be prudent to give it a different filename from the normal x86 version so they can avoid stomping on each other, like when using the Java nightly updater to update an installation on a Pi using my binary.

I'm guessing the Java updater will otherwise work just fine in Raspbian provided a compatible Java runtime is installed.

[prissi]

The opengl will not do much, as it relies anyway on SDL2 and uses the opengl bitblt (copying regions). Since SDL2 will use the best rendering anyway, and copy regions is mostly limited by memory bandwidth, opengl has not advantage for a shared memory architecture; if the CPU has a larger memory bandwidth than the GPU, CPU based rendering is even faster on joint memory architectures like Rasberry.

Also Standard runs decently on a 600 MHz first version Atom processor as well as a Galaxy Pocket with Android 2.6, which both are in a similar CPU category than the Rasberries. I mean it was built on 140 MHz Pentiums in 2002 ...