-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash on Manjaro Arm64 #3269
Comments
Looks like it's something about OpenGL 3. The Pis use OpenGL ES, which can be significantly different from normal OGL. You'd have to add ES as a backend for LUS. The Android port also had to deal with this, you might look into that to get the build running, but if that gets upstreamed you might not actually have to do that work yourself later on. https://github.com/Waterdish/Shipwright-Android |
Sorry, this would probably be more applicable https://github.com/Waterdish/libultraship |
It seems I have a similar issue. This is with an Intel GM45:
It supports OpenGL 2.1 (and OpenGL ES 2.0) only. At least OpenGL 3.0 is required? |
According to one of the devs, 3.1 is enough. The thing is, as mentioned already, the differences between normal vs ES implementations. |
3.1 is too much for quite a bit of hardware that did run the game in an emulator only supports OpenGL 2.1 and OpenGL ES 2.0. Hopefully older OpenGL versions may also work at some point. |
Emulators have different requirements than SoH. SoH is a port, and has been somewhat reworked to take advantage of newer APIs. Support for less than 3.x likely will never happen because it now relies on some of those newer API functions. |
@Malkierian that makes sense. Hopefully devices like raspberry pi wil support newer versions of opengl in the future. I was talking to a friend who compiled SoH inside a raspberry pi 4 (8GB) with RGB-Pi OS4. The issue seems to be the lack of Xorg, which makes sdl2 fail. This is probably a different issue tho. Edit: @coreybruce if this ever happens, it may be useful for you. |
Oh nah it has nothing to do with that issue but thank you for sharing, it seems like the pi 5 will be needed to play this since it supports OpenGL 3 and Vulkan |
Just a quick note, pi5's VideoCore VII GPU supports OpenGL ES 3.1 apparently, so the OpenGL issues could be solvable on a Pi 5? |
It does compile and run on a raspberry pi 5 with raspberry pi os 64 bit bookworm. Seems to run great except the screen to choose the save file, which slows down. But has anyone managed to compile successfully on a pi 4 bullseye 32 bit? (I get a compiling error concerning RumbleMappingFactory.cpp, i think...) |
Yeah I'm definitely going to test this out and get a pi 5 when I can 😁👍 |
Like with 64-bit Pi, 32-bit anything is unsupported out of the box and requires extra changes to CMake to even attempt to build. What those changes are for 32-bit will have to be discovered or specified by someone else, and we have no official support for any of it. |
It's running on my ASUS Tinkerboard S, which has a 32-bit CPU: https://en.wikipedia.org/wiki/Rockchip_RK3288 |
Actually I just found out the Raspberry pi 4 does have OpenGL 3.1 support back in 2020 Can we please re look at this issue? |
Hi there! I now managed to compile and run sucessfully on a raspberry pi 4/400 with raspberry pi os 64 bit bullseye! sudo apt-get install -y libasound2-dev libudev-dev libibus-1.0-dev libdbus-1-dev fcitx-libs-dev libsndio-dev libx11-dev libxcursor-dev libxext-dev libxi-dev libxinerama-dev libxkbcommon-dev libxrandr-dev libxss-dev libxt-dev libxv-dev libxxf86vm-dev libegl1-mesa-dev libgles2-mesa-dev libgl1-mesa-dev libglu1-mesa-dev libdrm-dev libgbm-dev libfontconfig1-dev automake mercurial libtool libfreeimage-dev libopenal-dev libpango1.0-dev libsndfile1-dev libtiff5-dev libwebp-dev libaudio-dev freeglut3-dev libmodplug-dev libsmpeg-dev libjpeg-dev libsamplerate0-dev libjack-dev libopusfile-dev libmpg123-dev libfluidsynth-dev libvulkan-dev autoconf libvulkan-dev libvulkan1 libwayland-dev wayland-protocols wget https://www.libsdl.org/release/SDL2-2.26.5.tar.gz && tar xf SDL2-2.26.5.tar.gz You can also create deb packages and install. You will need to create a debian folder with changelog, control and other files (or you can copy/paste from https://www.libsdl.org/release/SDL2-2.0.18.tar.gz and make some changes) to create deb packages. then: sudo dpkg -i libsdl2-2.0-0_2.26.5_arm64.deb && sudo dpkg -i libsdl2-dev_2.26.5_arm64.deb After this and following standard building instructions for linux, soh should compile. Finally, package soh and run with: Final note: libsdl2-dev needs to be installed, otherwise soh.elf will crash |
Ah I forgot I was still having this issue which hasn't been resolved EDIT: after getting some assistance on the Discord server I have now figured out the issue and I have given some feedback to add what is missing in the documentation |
Oh wow that is a really over complicated way with more work to compile it but I am happy for you haha I just compiled it on Manjaro Arm64 and it was significantly easier to compile as the latest SDL2 is in the manjaro repos, I can now say that this issue is now completed |
Be aware that libsdl2-dev needs to be installed, otherwise soh.elf will crash |
Yeah on manjaro it's just called sdl2 but that wasn't the issue originally, there was another issue that got resolved at some point upstream 😃 |
Worth mentioning, but after Kenix3/libultraship@bd20dd4 I no longer get a crash when launching now on a Raspberry Pi 4 with archlinuxarm and aarch64 architecture. I found it was crashing for me since it was trying to use the x11 driver, despite me trying to run it in console. I guess getting rid of GLEW allows it to find the kmsdrv video mode and use that instead? Not entirely sure why. But I also managed to get it working on 8.0.5 as well by overriding the SDL video driver like so..
However, it still crashes for me when compiled for 32bit armv7h.
|
Yeah the issue has been resolved tho I think the game would be to much for a older Arm7l 32bit device, it stuttered/slows down on the pi 4 in the starting area but stable. Using a more powerful pi 5 gives better stability and performance |
arm linux isn't an officially supported platform, but chances are if you stumbled across this issue you're looking for solutions not a "wontfix" - so i'll share what i know to hopefully point people in the right direction before closing this a lot of the changes needed to get soh building on arm systems that don't have all the libs we'd expect on an x86_64 desktop needed to happen on the LUS side of things. relevant LUS PRs
there has been effort by the portmaster team to get soh running on arm linux handhelds between that work and the fact that it seems the original reported issue has been resolved i'm going to close this thread, it seems the only unresolved crashes in this thread are 32 bit and the issue is titled arm64 |
All tho it isn't officially supported I have already have been compiling it for Arm64 on a Arch based distros and redistributing for it as well as x64 and i686 with my AUR package https://gitlab.com/linuxbombay/soh Thank you for all the hard work for getting it to work on Linux Arm64! I will continue to help support you guys by testing and reporting anything I can as well as compiling for it. |
It seems good to also highlight that while not officially supported, both aaarch64 (from what I'm reading here) and armhf (32-bit) are generally working fine. I found the game quite playable on my Tinkerboard S, which is using a 32-bit ARM chip which would already be considered relatively old I guess. |
Hey there, I successfully got Shipwright compiled on my Raspberry pi on Manjaro Arm64 but when I try and run Shipwright it says it crashed and I was wondering/hoping this could be fixed/resolved so we can enjoy this on the pi4 and even the 5 in the future.
Log: Ship of Harkinian.log
The text was updated successfully, but these errors were encountered: