Started by Duplo, September 30, 2019, 12:20:18 AM
0 Members and 1 Guest are viewing this topic.
Quote from: Freahk on September 30, 2019, 05:58:54 AMI 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.txtAdditionally you can try this guide for ubuntu http://spacethingy.weebly.com/compiling-simutrans-for-linux-beginners.htmlHowever, 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.
BACKEND = sdl2COLOUR_DEPTH = 16
Quote from: Freahk on September 30, 2019, 01:24:04 PMThe 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-extendedAnd you also have to setCode Select ExpandBACKEND = sdl2COLOUR_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.
Quote from: Duplo on September 30, 2019, 03:10:25 PMI got it to finish compiling and now I have an even bigger issue with possible file system corruption
Quote from: DrSuperGood on October 01, 2019, 04:03:53 AMI 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.
Quote from: Duplo on October 01, 2019, 06:44:25 AMMy take on it is that the card may just couldn't cope with the load.