Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -55,6 +55,8 @@ typedef void (*pSdlSetScreen) (int width, int height, Uint32 format); | |
typedef void (*pVoidFunc) (); | ||
typedef m64p_error (*pCoreDoCommand) (m64p_command, int, void *); | ||
typedef int (*pFrontMain) (int argc, char* argv[]); | ||
typedef void (*pNativeResume) (JNIEnv* env, jclass cls); | ||
typedef void (*pNativePause) (JNIEnv* env, jclass cls); | ||
|
||
// Function pointers | ||
static pAeiInit aeiInit = NULL; | ||
|
@@ -63,6 +65,8 @@ static pSdlSetScreen sdlSetScreen = NULL; | |
static pVoidFunc sdlMainReady = NULL; | ||
static pCoreDoCommand coreDoCommand = NULL; | ||
static pFrontMain frontMain = NULL; | ||
static pNativeResume nativeResume = NULL; | ||
static pNativePause nativePause = NULL; | ||
|
||
void checkLibraryError(const char* message) | ||
{ | ||
|
@@ -160,9 +164,11 @@ extern "C" DECLSPEC void SDLCALL Java_paulscode_android_mupen64plusae_jni_Native | |
sdlMainReady = (pVoidFunc) locateFunction(handleSDL, "SDL2", "SDL_SetMainReady"); | ||
coreDoCommand = (pCoreDoCommand) locateFunction(handleCore, "mupen64plus-core", "CoreDoCommand"); | ||
frontMain = (pFrontMain) locateFunction(handleFront, "mupen64plus-ui-console", "SDL_main"); | ||
nativeResume = (pNativeResume) locateFunction(handleSDL, "SDL2", "Java_org_libsdl_app_SDLActivity_nativeResume"); | ||
nativePause = (pNativePause) locateFunction(handleSDL, "SDL2", "Java_org_libsdl_app_SDLActivity_nativePause"); | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
littleguy77
Member
|
||
|
||
// Make sure we don't have any typos | ||
if (!aeiInit || !sdlInit || !sdlSetScreen || !sdlMainReady || !coreDoCommand || !frontMain) | ||
if (!aeiInit || !sdlInit || !sdlSetScreen || !sdlMainReady || !coreDoCommand || !frontMain || !nativeResume || !nativePause) | ||
{ | ||
LOGE("Could not load library functions: be sure they are named and typedef'd correctly"); | ||
} | ||
|
@@ -188,6 +194,8 @@ extern "C" DECLSPEC void SDLCALL Java_paulscode_android_mupen64plusae_jni_Native | |
sdlMainReady = NULL; | ||
coreDoCommand = NULL; | ||
frontMain = NULL; | ||
nativeResume = NULL; | ||
nativePause = NULL; | ||
|
||
// Close shared libraries | ||
unloadLibrary(handleFront, "mupen64plus-ui-console"); | ||
|
@@ -242,12 +250,14 @@ extern "C" DECLSPEC void Java_paulscode_android_mupen64plusae_jni_NativeExports_ | |
|
||
extern "C" DECLSPEC void Java_paulscode_android_mupen64plusae_jni_NativeExports_emuResume(JNIEnv* env, jclass cls) | ||
{ | ||
if (nativeResume) nativeResume(env, cls); | ||
if (coreDoCommand) coreDoCommand(M64CMD_RESUME, 0, NULL); | ||
} | ||
|
||
extern "C" DECLSPEC void Java_paulscode_android_mupen64plusae_jni_NativeExports_emuPause(JNIEnv* env, jclass cls) | ||
{ | ||
if (coreDoCommand) coreDoCommand(M64CMD_PAUSE, 0, NULL); | ||
if (nativePause) nativePause(env, cls); | ||
} | ||
|
||
extern "C" DECLSPEC void Java_paulscode_android_mupen64plusae_jni_NativeExports_emuAdvanceFrame(JNIEnv* env, jclass cls) | ||
|
4 comments
on commit 1b8f772
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.
@littleguy77 could you test this branch on your devices too see if everything is ok?
I mainly rebased this commit https://github.com/Gillou68310/mupen64plus-ae-gsi/commit/733b3775349d5c4b4891227744b2aad7161ab885 using your GameSurface class ;-)
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 seems rather intrusive at a quick glance. It seems like a lot of the GameSurface design has been short circuited. Commenting all the assertPrecondition
statements suggests to me that the behavior of the whole class has changed. Can you explain the crux of the problem with the current design? i.e. step-by-step process on your particular device to reproduce the issue this solves? I know we've discussed this before but I can't seem to find the discussion.
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.
Here's the previously discussed topic ;-)
www.paulscode.com/forum/index.php?topic=1813.0
Just to be clear the current design works perfectly on my phone. This is an alternative design that doesn't shut down the core when the surface is detroyed. One advantage is that cheat codes will be retained when restoring the app from background. IMO this is the way it should work, at least this is the way other android emu works ;-)
I removed the assert precondition because of the new destroyGLSurface method which does not respect your state machine.
Concerning nativeResume + nativePause handles they work just fine for me.
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.
One advantage is that cheat codes will be retained when restoring the app from background.
That is indeed very important and alone is sufficient reason to fix this. Thanks for the reminder.
I will try to take a closer look this evening to understand what's going on in this commit and see what the nativePause/nativeResume stuff is all about. I don't like just commenting out code because it no longer works with the changes. That will invariably lead to confusion later when someone has to maintain it.
These function handles will never be found.