Closed Grima04 closed 1 month ago
I don't see any missing symbol in the log. Is not easy to catch a missing symbol there, because for X11, symbol are searched in each X11 related lib open (by the program, not by box64). So you can see many "Symbol not found" for the same symbol until it is finaly found in some lib.
Did you found a missing symbol?
Thanks for the explanation, I think that I misinterpreted the "Symbol not found" errors as missing symbol errors but it looks like they were indeed only temporary errors until the symbols were found in another lib. I haven't seen any missing symbols elsewhere in the log.
I have also made a log with BOX64_LOG=2
since the default logging level doesn't give any useful information about the crash (just the message Aborted (core dumped)
):
US2.log
Hopefully it contains some useful information.
Is there something else I could do to provide more information on the crash?
I have tested the game again with box64 v0.1.5 46f71f3 on my Jetson Xavier NX. The Linux version unfortunately still crashes during the loading screen but the Windows version (using DX11) is now able to go ingame using Wine 6.0 from PlayOnLinux. Getting ingame is unfortunately a matter of luck, the game still freezes or crashes very often during the loading screen but when it manages to load properly, it seems to run quite stable. Currently, there also seems to be a problem with the keyboard and mouse input since it stops working after a while, making the game unplayable but other than that, I haven't noticed any issues.
Performance wise, it doesn't run very well (around 5 to 10 FPS) but I guess that a lot of performance is lost due to WineD3D being used. I also tried to force the game to use OpenGL but it doesn't recognize any graphics adapter in that mode, so we are currently limited to DX11. Overall, this is some really good progress though and it is even more impressive when considering that the game is running through Wine using DX11.
Using box64 v0.1.5 4812d20, the Linux version of the game is also able to get ingame. Every now and then it will still crash on startup but the booting process is more stable than the one from the Windows version. The Linux version is using at least OpenGL 4.3 as far as I know, so it will be harder to test this one on other hardware since most ARM boards don't have OpenGL 4.3+ support at the moment. The game is running very slow though and it isn't fully using the GPU for some reason (the GPU usage hovers around 20% to 30% on my Jetson Xavier NX) and it also seems to have some minor bugs. The inner planetary orbits for example aren't fully rendered and all planets seem to have a temperature of -273°C (which is nearly 0 degrees Kelvin but I am not sure in what unit the game handles its internal temperature values). Other than that, I haven't encountered any issues. Here is a screenshot of the game rendering our solar system:
The 0 K avg temperature is probably an opcode bug? Does the game run without dynarec, and if yes, is the temperature bug still there (I know the loading will be painfully slow without dynarec, sorry)? It would be interesting to debug it. I'll check if I have the game somewhere. I think I have it on steam, not sure if I have a drm free version...
No problem, I will launch it now without dynarec and see if it will go ingame to check the temperature bug. For the game itself, I just took the game files from Steam, copied them over to my Xavier and used the goldberg emulator, so it should be no problem to launch it without the Steam client.
Edit: The bug is also present when using the interpreter. I have also noticed something else. The calculated temperatures are only wrong for planets and bigger objects rotating around the Sun. The Sun itself has a correct temperature value (in °C and Kelvin) and small fragments flying around the Sun in various orbits also seem to be calculated correctly.
Goldberg with box64 can crash games on startup sometimes, i experienced that with Spiritfarer
вт, 26 окт. 2021 г., 19:36 Grima04 @.***>:
No problem, I will launch it now without dynarec and see if it will go ingame to check the temperature bug. For the game itself, I just took the game files from Steam, copied them over to my Xavier and used the goldberg emulator, so it should be no problem to launch it without the Steam client.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ptitSeb/box64/issues/87#issuecomment-952115576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK6SASWKBW6DI5OBJTMCQSDUI3RKVANCNFSM5B7QPW2A .
I have also tested the game with ExaGear from Huawei (another x86_64 emulator) and on there the same temperature bug appeared, so I looked on the Steam forums and apparently some people seem to have the same bug on real x86_64 hardware on Linux. The fix that was recommended in the forums was to disable VSYNC and it worked, now the planets have their normal temperature. So the problem isn't on box64's end after all, I am sorry for the false alarm. The graphics bugs with the orbits were also present on ExaGear (with virgl for GPU acceleration), so it seems to be a bug in the Nvidia drivers but to be sure, we would need a test on another GPU. Here is how it looks with VSYNC disabled:
The crashes on startup are still an issue though, so it would be interesting to look into why Goldberg causes crashes on box64.
Oh, nice! So it's just a vsynch issue?! How strange the side effect change temperature of the planets!
For the crashes, I have made somes fixes in box86 (expecially the ones on LOCK prefixes) that I have to port to box64 that may help.
Is this fixed now?
@Grima04 If you are still having issues with Universe Sandbox 2, feel free to re-open this GitHub Issue. Everything appears to be implemented. Closing as resolved.
When running the Linux version of Universe Sandbox 2 with box64, the game crashes during the loading screen due to missing symbols. I have attached a log taken with
BOX64_DLSYM_ERROR=1
below: UniverseSandbox2.log