HarbourMasters / Shipwright

3k stars 470 forks source link

Crash on Manjaro Arm64 #3269

Open coreybruce opened 9 months ago

coreybruce commented 9 months ago

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

Malkierian commented 8 months ago

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

Malkierian commented 8 months ago

Sorry, this would probably be more applicable https://github.com/Waterdish/libultraship

jschwartzenberg commented 6 months ago

It seems I have a similar issue. This is with an Intel GM45:

[2024-01-02 17:50:59.669] [/home/runner/work/Shipwright/Shipwright/libultraship/src/resource/Archive.cpp:452] [info] Opened mpq file /home/julius/games/oot-mq.otr.
[2024-01-02 17:50:59.798] [/home/runner/work/Shipwright/Shipwright/libultraship/src/resource/Archive.cpp:485] [info] (/home/julius/games/oot.otr) Patched in mpq file.
[2024-01-02 17:50:59.833] [/home/runner/work/Shipwright/Shipwright/libultraship/src/resource/Archive.cpp:518] [info] (/tmp/.mount_soh.apRygoy7/usr/bin/soh.otr) Missing version file. Attempting to apply patch anyway.
[2024-01-02 17:50:59.833] [/home/runner/work/Shipwright/Shipwright/libultraship/src/resource/Archive.cpp:485] [info] (/tmp/.mount_soh.apRygoy7/usr/bin/soh.otr) Patched in mpq file.
Failed to initialize OpenGL loader!
[2024-01-02 17:51:01.163] [/home/runner/work/Shipwright/Shipwright/libultraship/src/public/libultra/os.cpp:20] [info] Added SDL game controllers from "/tmp/.mount_soh.apRygoy7/usr/bin/gamecontrollerdb.txt" (287)
[2024-01-02 17:51:03.865] [/home/runner/work/Shipwright/Shipwright/libultraship/src/debug/CrashHandler.cpp:72] [critical] Signal: 11
INVALID ACCESS TO STORAGE
Registers:
RAX: 0x0000000000000000
RDI: 0x000055BCA99D8290
RSI: 0x000055BCA99D82A0
RDX: 0x000055BCA99D09C0
RCX: 0x0000000000000003
R8:  0x00007FFC2952E270
R9:  0x0000000000000000
R10: 0x000055BCA7115DE0
R11: 0x00007F5770F07500
RSP: 0x00007FFC2952E2A0
RBX: 0x000055BCA9A07340
RBP: 0x00007FFC2952E330
R12: 0x000055BCA9A07340
R13: 0x00007FFC2952E360
R14: 0x00007FFC2952E320
R15: 0x00007FFC2952E310
RIP: 0x000055BCA70B05E2
EFL: 0x0000000000010202
Traceback:
1 /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f5770f50420]
2 ImGui_ImplOpenGL3_NewFrame() (+0x22)
3 LUS::Gui::DrawMenu() (+0xEF)
4 gfx_start_frame() (+0x7E)
5 Graph_StartFrame (+0x124)
6 ./soh.elf(+0x9197be) [0x55bca6b157be]
7 ./soh.elf(+0xd557fa) [0x55bca6f517fa]
8 Graph_ProcessFrame (+0x3B)
9 Main (+0x36B)
10 main (+0x2E)
11 __libc_start_main (+0xF3)
12 _start (+0x2E)
Build Information:
Game Version: Sulu Bravo (7.1.1)
Build Date: Aug 14 2023 00:46:21

It supports OpenGL 2.1 (and OpenGL ES 2.0) only. At least OpenGL 3.0 is required?

gustavostuff commented 5 months ago

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.

jschwartzenberg commented 5 months ago

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.

Malkierian commented 5 months ago

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.

gustavostuff commented 5 months ago

@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.

coreybruce commented 5 months ago

@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

retropieuser commented 4 months ago

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?

fac3l3ss79 commented 4 months ago

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...)

coreybruce commented 4 months ago

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?

Yeah I'm definitely going to test this out and get a pi 5 when I can 😁👍

Malkierian commented 4 months ago

But has anyone managed to compile successfully on a pi 4 bullseye 32 bit? (I get a compiling error concerning RumbleMappingFactory.cpp, i think...)

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.

jschwartzenberg commented 3 months ago

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

coreybruce commented 3 months ago

Actually I just found out the Raspberry pi 4 does have OpenGL 3.1 support back in 2020

https://www.hackster.io/news/raspberry-pi-4-model-b-gains-official-opengl-es-3-1-conformance-certification-from-the-khronos-group-0c5e7b31c625

Can we please re look at this issue?

fac3l3ss79 commented 3 months ago

Hi there! I now managed to compile and run sucessfully on a raspberry pi 4/400 with raspberry pi os 64 bit bullseye! A newer version of libsdl2 and libsdl2-dev needs to be compiled and installed though (I used sdl2 2.26.5). This is a must for soh to compile sucessfully on a raspberry pi 4 with 64 bit bullseye and run. Here are the instructions for this:

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 cd SDL2-2.26.5 ./autogen.sh ./configure --enable-video-opengl --disable-esd --enable-video-opengles --enable-libudev --enable-arm-simd --enable-video-vulkan --host=arm-raspberry-linux-gnueabihf make -j4 sudo make install

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. To this, use the following commands: sudo apt-get build-dep libsdl2-2.0-0 dpkg-buildpackage -us -uc

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: MESA_GL_VERSION_OVERRIDE=3.1 MESA_GLSL_VERSION_OVERRIDE=300 ./soh.elf

Final note: libsdl2-dev needs to be installed, otherwise soh.elf will crash

coreybruce commented 3 months ago

Ah I forgot I was still having this issue which hasn't been resolved

https://github.com/HarbourMasters/Shipwright/issues/3780

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

coreybruce commented 3 months ago

Hi there! I now managed to compile and run sucessfully on a raspberry pi 4/400 with raspberry pi os 64 bit bullseye! A newer version of libsdl2 and libsdl2-dev needs to be compiled and installed though (I used sdl2 2.26.5). This is a must for soh to compile sucessfully on a raspberry pi 4 with 64 bit bullseye and run. Here are the instructions for this:

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 cd SDL2-2.26.5 ./autogen.sh ./configure --enable-video-opengl --disable-esd --enable-video-opengles --enable-libudev --enable-arm-simd --enable-video-vulkan --host=arm-raspberry-linux-gnueabihf make -j4 sudo make install

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. To this, use the following commands: sudo apt-get build-dep libsdl2-2.0-0 dpkg-buildpackage -us -uc

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: MESA_GL_VERSION_OVERRIDE=3.1 MESA_GLSL_VERSION_OVERRIDE=300 ./soh.elf

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

fac3l3ss79 commented 3 months ago

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

coreybruce commented 3 months ago

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 thar 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 :smiley:

bkacjios commented 2 months ago

Worth mentioning, but after Kenix3/libultraship/commit@bd20dd4470462420a55d9a3d999868c2110add5d 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..

SDL_VIDEODRIVER=kmsdrm soh

However, it still crashes for me when compiled for 32bit armv7h.

*** buffer overflow detected ***: terminated

(zenity:17854): Gtk-WARNING **: 19:00:28.920: Failed to open display

1 __default_rt_sa_restorer (+0x0)
2 /usr/lib/libc.so.6(+0x7e310) [0xb67be310]
3 raise (+0x20)
Build Information:
Game Version: MacReady Foxtrot (8.0.5)
Build Date: Apr 15 2024 21:40:39
coreybruce commented 2 months ago

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

SDL_VIDEODRIVER=kmsdrm soh

However, it still crashes for me when compiled for 32bit armv7h.

*** buffer overflow detected ***: terminated

(zenity:17854): Gtk-WARNING **: 19:00:28.920: Failed to open display

1 __default_rt_sa_restorer (+0x0)
2 /usr/lib/libc.so.6(+0x7e310) [0xb67be310]
3 raise (+0x20)
Build Information:
Game Version: MacReady Foxtrot (8.0.5)
Build Date: Apr 15 2024 21:40:39

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