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
Android: Get game metadata from core #9078
Android: Get game metadata from core #9078
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will display the gameId for the in-game emulation menu's game title. What do you think about removing the gameID there to maximize space for menu options?
|
I guess that makes sense. But what do we do in the case where the title database doesn't recognize the running game? Do we show just the game ID (like how this PR works right now) or nothing? |
|
I think displaying the game ID as a fallback if no title is found is fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, GeckoOS is giving me this exception on startup:
2020-09-13 09:42:12.622 8486-8486/org.dolphinemu.dolphinemu.debug E/AndroidRuntime: FATAL EXCEPTION: main
Process: org.dolphinemu.dolphinemu.debug, PID: 8486
java.lang.IllegalStateException: No game is running
at org.dolphinemu.dolphinemu.NativeLibrary.CheckGameMetadataValid(NativeLibrary.java:456)
at org.dolphinemu.dolphinemu.NativeLibrary.IsEmulatingWii(NativeLibrary.java:436)
at org.dolphinemu.dolphinemu.overlay.InputOverlay.refreshControls(InputOverlay.java:706)
at org.dolphinemu.dolphinemu.overlay.InputOverlay.initTouchPointer(InputOverlay.java:140)
at org.dolphinemu.dolphinemu.fragments.EmulationFragment.initInputPointer(EmulationFragment.java:158)
at org.dolphinemu.dolphinemu.activities.EmulationActivity.initInputPointer(EmulationActivity.java:1141)
at org.dolphinemu.dolphinemu.-$$Lambda$VaQ0DnlfVw6B_598YlWOOA_cqe0.run(Unknown Source:2)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7073)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:494)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:965)
c0cfe4a
to
bf290bf
Compare
|
Both problems should now be fixed. (Regarding Gecko OS, I hadn't taken into account that |
bf290bf
to
e7b23cc
Compare
|
Even with the most recent push, I'm getting a (unhelpful) |
|
Nevermind, it's the combination of https://bugs.dolphin-emu.org/issues/11113 and Android Dolphin resetting my default controls upon reinstall. |
|
I don't really get how that could cause a |
|
|
I tried turning off Wii Remotes and launching Xenoblade Chronicles through Gecko OS (saying yes to when Gecko OS asked me to install IOS 53), and it worked perfectly for me. Do you have any details on what's triggering the exception? I would assume it has something to do with the call to Host_TitleChanged, but I'm not sure. I will try to create a separate PR (for all platforms) for displaying a name for DOL/ELF files. (I don't believe it's possible to reach the case where nothing, not even a game ID, is displayed when running a disc or WAD.) |
Perhaps I should mention this explicitly: With this PR, when you launch a game through something like Gecko OS, the title will update to match the game you launched. This is one of the advantages of getting the title from the core. |
e7b23cc
to
935cabc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps I should mention this explicitly: With this PR, when you launch a game through something like Gecko OS, the title will update to match the game you launched. This is one of the advantages of getting the title from the core.
Now that I've gotten to the point where mods were loaded in this PR, I was able to notice that change and it makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That fixed the problem. I don't have much C++ review experience but as far as I can tell this PR LGTM.
|
I've managed to reproduce the crash now (with the last commit reverted). The reason why I couldn't reproduce it before was because it only happens with fastmem on and I had accidentally left fastmem off (since I need it off when using the debugger). Unfortunately, this means that I can't use the debugger to figure out what's going on, and I would really like to know what's going on before this gets merged. I'm also not getting a |
98e6d3d
to
d8de4c2
Compare
d8de4c2
to
1a48fbf
Compare
Source/Android/jni/MainAndroid.cpp
Outdated
| @@ -152,8 +152,10 @@ void Host_TitleChanged() | |||
| { | |||
| s_game_metadata_is_valid = true; | |||
|
|
|||
| JNIEnv* env = IDCache::GetEnvForThread(); | |||
| env->CallStaticVoidMethod(IDCache::GetNativeLibraryClass(), IDCache::GetOnTitleChanged()); | |||
| std::thread([] { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should have a comment explaining why this is required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that I have no idea why this is required. It's the one thing keeping this PR from being mergeable in my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a similar issue and know where it crashes. The culprit is JVM's AttachCurrentThread in GetEnvForThread.
In IDCache.cpp:
if (status == JNI_EDETACHED)
s_java_vm->AttachCurrentThread(&env, nullptr);The things is, for me at least, it raises randomly many different type of exceptions/errors such as segfault, libc/stack corruption, memory access errors, etc. I tried to find any relevant pieces of documentation regarding this behaviour but couldn't find any. I also don't know (yet) how to debug native code so I couldn't go deeper.
I suspect there is something fishy in that function and that depending on how the thread was created it might produce an undefined behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, so AttachCurrentThread fails if we call it from the CPU thread, but only when fastmem is enabled... Maybe we could make sure to attach the CPU thread before enabling fastmem? I'll give that a try.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems to do the trick. I'm much happier with this than the earlier workaround.
My new commit calls AttachCurrentThread before EMM::InstallExceptionHandler, but calling it immediately afterwards also seems to work. Perhaps the problem only occurs after the first fastmem fault rather than after the exception handler is installed?
1a48fbf
to
84fff1b
Compare
|
This should be ready for merge now. |
A title change to a title with no game ID is still a title change.
Trying to get it from a GameFile before emulation starts is unreliable.
84fff1b
to
80360d2
Compare
80360d2
to
e86d713
Compare
Trying to get it from a GameFile before emulation starts is unreliable.