Solved the resolution problem. It was using the default resolution, which is extremely tiny on a high-res screen. It wasn't quite as simple as changing the default resolution, though, because there is no way of knowing ahead of time what the end user's screen resolution is going to be. Easy solution was to simply make a call to resize once the resolution is known after SDL is initialized.
Anyway, I have to get ready for another long shift at work, so here is the test APK and full source code, as promised:
Plug-in Test A (
source code)
IMPORTANT: Before you start, please delete the app-data from my previous test apps if you ran those in the past! Several things have changed in there since the last round of tests, so I have no idea how the app will behave if you aren't using the current version of the app data. It will still be located on your device, even if you uninstalled the apps themselves. It will be located on your sdcard at
[path to sdcard]/app-data/paulscode.android.mupen64plus (on my phone this is /mnt/sdcard/app-data/paulscode.android.mupen64plus). Simply delete the entire paulscode.android.mupen64plus folder before you run the above test the first time.
The above APK is packaged with two versions of the app, one optimized for ARM7a, and one compatible back to ARM5. However, since I don't have an ARM5 device to test on, I have no idea if the settings are correct to deploy the correct version on pre-ARM7a devices. So if it won't install, let me know, and I'll compile a separate ARM5 test apk.
As with the last round of tests, the above app will automatically download the data it needs the first time you run it. If your device doesn't have an internet connection, or if you have a data limit, you can manually install this data BEFORE running any of the tests. Simply unzip the following file and place all the contents onto your device's SD card under
[path to sdcard]/app-data/paulscode.android.mupen64plus/
App Data ZIP (not necessary if your device has internet access)
I didn't include an x86 version in this round of tests. I want to fix some of the other bugs first before I open a new can of worms. ;D The next round of tests will include x86 (sorry, folks who have to wait)
The main things I'm looking for in this round of tests are:
1) Results on a variety of devices, to see how consistently it behaves.
2) Results on devices with ARM5 or ARM6 processors
3) Results from Android versions prior to 2.3 (
should be compatible back to Android 1.6 in theory, but untested)
4) In the case that the app doesn't crash like it does on my phone, tests of the input plug-in (requires manual editing of the file app-data/paulscode.android.mupen64plus/data/InputAutoCfg.ini to configure the buttons)
5) In the case that the app has new problems that I haven't experienced on my own phone (immediate crash, error messages, black-screen even after force-closing and restarting the app, no-sound, strange phone behaviors, etc), then please send me your logcat output (using the free app "aLogcat" from the Android market), and also send me the file app-data/paulscode.android.mupen64plus/data/DEBUG_PluginTestA_memoryMaps.txt). (I don't need these from everyone else, just the folks who are experiencing different problems that I don't know about yet).
Known issues on my phone (Motorola Droid X, Android 2.3.3, rooted):
1) Layout switching problem after the data downloader finishes on the first run. Results in video disappearing, app restarting, and black-screen. Work-around: force-close the app and restart it (not until after the data is finished downloading though!)
2) Polygon sort-order problem (3D splash is missing pieces, Mario's face looks jumbly, Bowser's arms show through his body).
3) Scene transitions are choppy (audio cuts out, frame-rate stalls momentarily).
4) Crash after Bowser breaths fire (app usually restarts once then force-closes; sometimes enters restart loop, requiring manual force-close; sometimes freezes the phone, requiring battery to be removed, sometimes reboots the phone)
Feel free to post results here, PM me, or email (whichever works). Thanks in advance!
If you are compiling from source code, to work around the "RAM full of zeros" bug, run "ndk-build" for mupen64plus-SDL1.3, and then again for mupen64plus-core-ARCHs. Then do four copy/pastes (overwriting the existing files):
Copy mupen64plus-core-ARCHs/libs/armeabi/libcore.so and paste it into:
mupen64plus-SDL1.3/libs/armeabi/ and
mupen64plus-SDL1.3/obj/local/armeabi/
Copy mupen64plus-core-ARCHs/libs/armeabi-v7a/libcore.so and paste it into:
mupen64plus-SDL1.3/libs/armeabi-v7a/ and
mupen64plus-SDL1.3/obj/local/armeabi-v7a/
If any Android developers who happen to be reading this can figure out how to solve the problem without this silly work around, please let me know (it's got to be a simple settings-related bug in the make files, because the source code itself is identical in both projects)