Open Cryolitia opened 8 months ago
Random stab in the dark, this might be an I/O error; the game attempted to load too many sprites at once and ended up crashing because it didn't have enough memory assigned
You can try increasing the UI Scale in settings.json in order to remediate this issue. Otherwise, I have no idea, and Waydroid/Linux is an unsupported platform as of current. A stable desktop build is coming soon, but I have no idea whether a native Linux build will be available or not (Proton will always be an option)
We will have a Linux native build after desktop releases, as well as Macintosh.
As @DavidScann said, this can be a memory allocation issue, but I noticed in kernel log attached, the container tried to load up a CPU emulation layer, which handled the ram for game too.
Especially, I found in log, this line occurred before the progress get killed: “Failed to determine oat file name for dex location”, that’s why I believe the emulation layer compatibility issue might occur in this case as well.
Nevertheless, official AMD64 builds are not released yet, since you utilize two emulation layers, there’s too much for us to debug, and since it’s not running on current supported platforms, I don’t think there’s much help you can get from AstroDX team.
If you REALLY care about it, file a issue in your emulation layer’s repositories might be a better choice.
For me AstroDX even crashes when I have one song installed after 2-3 seconds into the main menu. v1.1.1 is playable with small issues tho. Also I am not sure how good the multitouch support will be when running the Windows binary using Proton on the Steam Deck.
I made a discovery. From what I have analyzed from the logcats it crashes because of the ARM transation layer, because the plattforms we are running are x86_64 and not ARM. Both off us use the libndk translation layer. From what I have read in multiple Waydroid issues libhoudini has a better translation layer. I sadly can't switch because of https://github.com/ryanrudolfoba/SteamOS-Waydroid-Installer/issues/22#issuecomment-1986856202 but @Cryolitia you could try to switch to libhoudini. This script has libhoudini in the setup: https://github.com/casualsnek/waydroid_script
It has nothing today with general issues with having a translation layer as AstroDX works perfectly fine in NoxPlayer which also has x86_64 as the architecture.
It has nothing today with general issues with having a translation layer as AstroDX works perfectly fine in NoxPlayer which also has x86_64 as the architecture.
That's what I predicted about, the crashing is caused by compatibility / emulation / translation layer instead of ADX itself.
In this point I think I may close this issue as I believe this should be filed at their repository instead of here, to get better support and developers may actually resolve it, we cannot help a lot here.
Anyway, thanks for everyone to diagnosing this, and happy playing!
but @Cryolitia you could try to switch to libhoudini.
libhoudini is even worse, AstroDX would suddenly crash after starting. As a reference, Arknights works fine with it. I'm no meanning for bothering AstroDX team to waste time on it. Just record it if someone is interesting in it.
I switched to Genymotion with https://github.com/niizam/Genymotion_A11_libhoudini and except of general performance issues (which I think have more to do with the under powered CPU of Steam Deck) everything works fine. (Also just an info for anyone stumbling over this in the future)
From what I have gathered it's a general thing with some Unity versions as they use ARM calls which somehow are not translated with some translation layer variants.
We will have a Linux native build after desktop releases, as well as Macintosh.
As @DavidScann said, this can be a memory allocation issue, but I noticed in kernel log attached, the container tried to load up a CPU emulation layer, which handled the ram for game too.
Especially, I found in log, this line occurred before the progress get killed: “Failed to determine oat file name for dex location”, that’s why I believe the emulation layer compatibility issue might occur in this case as well.
Nevertheless, official AMD64 builds are not released yet, since you utilize two emulation layers, there’s too much for us to debug, and since it’s not running on current supported platforms, I don’t think there’s much help you can get from AstroDX team.
If you REALLY care about it, file a issue in your emulation layer’s repositories might be a better choice.
May I ask when would the desktop version be released? (or test builds)
Describe the bug I use it to play on waydoird on Linux. It could work when I only importing serveral songs. But when I importing hundreds of songs, astrodx crashes.
To Reproduce Steps to reproduce the behavior:
Expected behavior A clear and concise description of what you expected to happen.
To work
Screenshots If applicable, add screenshots to help explain your problem.
录屏 2024-03-06 16-49-01.webm
Additional context
logcat.txt