Porting Mupen64Plus to Android
- Thread starter paulscode
- Start date
[SS] Starscream
Banned
Just gave it a try on my Galaxy Prevail. Mupen scanned my entire SD card (took a while) and then loaded Mario 64 (which I do not have on my SD card at all). Mario 64 played a bit slow for me and was missing graphics and there was no obvious way to control it, but good work so far. Also, how do you get other games to load, I put Mario Kart in the roms folder but there is no way to manually pick a game, Mario 64 loads every time.
Last edited:
OP
paulscode
New member
- Thread Starter
- #243
The missing graphics seems to be related to the depth buffer settings, which I am tweaking now. Folks with Qualcomm chip-sets seem to be most affected (compared to the OMAP3630 on my Droid X with displays the graphics perfectly for every ROM I've tried).
For control, you can use a program like aLogcat to get the log output, run the emulator and press a few buttons, then compare that to the logcat output which will give you the SDL scancodes to enter into InputAutoCfg.ini. Roundabout way for now, until I get around to the front-end GUI (going to fix the other problems first).
For game picking, just call whatever ROM you want to run "mario.n64". That's something else that will improve once I've added the front-end GUI.
After I solve the depth-buffer problem, I'll finish the on-screen gamepad (it's nearly finished), then tackle that inevitable crash problem.
For control, you can use a program like aLogcat to get the log output, run the emulator and press a few buttons, then compare that to the logcat output which will give you the SDL scancodes to enter into InputAutoCfg.ini. Roundabout way for now, until I get around to the front-end GUI (going to fix the other problems first).
For game picking, just call whatever ROM you want to run "mario.n64". That's something else that will improve once I've added the front-end GUI.
After I solve the depth-buffer problem, I'll finish the on-screen gamepad (it's nearly finished), then tackle that inevitable crash problem.
[SS] Starscream
Banned
I'm not interested in running games yet if it's not ready, I can wait. I wasn't sure how far along the emulator was and was just asking some general questions. If you need someone to test any changes on a Qualcomm chip, just email me or post here. Hopefully those missing graphics issues can be solved.
gles2n64 was developed on OMAP3, so it's not really surprising that it works better there.
Also, the "50-second crash" is because you left some debugging code active in store_assemble. It will produce a bunch of output after a specific amount of time. The intent is to set the timer to capture a specific part of the game that you want to debug, but you need to remember to remove it when you're finished.
Also, the "50-second crash" is because you left some debugging code active in store_assemble. It will produce a bunch of output after a specific amount of time. The intent is to set the timer to capture a specific part of the game that you want to debug, but you need to remember to remove it when you're finished.
OP
paulscode
New member
- Thread Starter
- #247
Today's Update:
- Added Toast message displaying SDL scancodes for keys when pressed
- Stopped device from entering sleep mode while app is running
- Fixed side-bar graphics glitches
- Removed 50-second crash
--Links Removed--
For those with missing graphics (Qualcomm chipsets), here is a version with the poly sort-order bug, until I fix the other problem:
-- Links Removed --
- Added Toast message displaying SDL scancodes for keys when pressed
- Stopped device from entering sleep mode while app is running
- Fixed side-bar graphics glitches
- Removed 50-second crash
--Links Removed--
For those with missing graphics (Qualcomm chipsets), here is a version with the poly sort-order bug, until I fix the other problem:
-- Links Removed --
Last edited:
OP
paulscode
New member
- Thread Starter
- #248
I decided to post an official build with the virtual gamepad, so folks can start testing it. I probably won't have time to make any updates or bug-fixes until I get back home (there are a couple known issues, see below)
-- Links removed --
IMPORTANT: You will need to update the app data, because several changes were made, mainly to the button masks. If you do not update the app data, you will get weird behavior of random alternate buttons pressing when you are trying to press other buttons! In case anyone isn't familiar with how to do this, the easiest way to update the app data is to delete the folder app-data/paulscode.android.mupen64plus from your SDCard, The emulator's DataDownloader module will then automatically download the new data for you when you start the app.
Known Problems:
The first thing you will notice is that the hat image doesn't move. I purposely disabled this, because the call to "invalidate()", which tells the surface to redraw, was ridiculously slow and having a major hit on performance. I'll need to rethink how to redraw without requiring so much CPU power (possibly some kind of timed "redraw granularity" rather than redrawing on every touch event that involved the analog stick).
The second thing you will notice is that it is really easy to "drop" the analog stick if you slide your finger too far (while running forward, etc). I'll need to implement some type of "stick capture" logic.
-- Links removed --
IMPORTANT: You will need to update the app data, because several changes were made, mainly to the button masks. If you do not update the app data, you will get weird behavior of random alternate buttons pressing when you are trying to press other buttons! In case anyone isn't familiar with how to do this, the easiest way to update the app data is to delete the folder app-data/paulscode.android.mupen64plus from your SDCard, The emulator's DataDownloader module will then automatically download the new data for you when you start the app.
Known Problems:
The first thing you will notice is that the hat image doesn't move. I purposely disabled this, because the call to "invalidate()", which tells the surface to redraw, was ridiculously slow and having a major hit on performance. I'll need to rethink how to redraw without requiring so much CPU power (possibly some kind of timed "redraw granularity" rather than redrawing on every touch event that involved the analog stick).
The second thing you will notice is that it is really easy to "drop" the analog stick if you slide your finger too far (while running forward, etc). I'll need to implement some type of "stick capture" logic.
Last edited:
OP
paulscode
New member
- Thread Starter
- #250
I've added some hardware checking logic, since the depth bug fix requires different settings for different hardware. I'm not calling this an official build yet, though, because I haven't got results from very many devices yet (I fully expect the fix to NOT work on many devices until I have enough examples to notice some reliable patterns for each group).
HW Profiler Test
If anyone has problems with the shadows, stars, and carpet (missing, flickery, or sort-order incorrect) then please let me know which (if any) of the HW Info Test aps I posted work on your device, and provide me with the logcat output:
HW Info Test (default) OMAP
HW Info Test 2 Qualcomm?
HW Info Test M IMAP
HW Info Test S Tegra 2
HW Profiler Test
If anyone has problems with the shadows, stars, and carpet (missing, flickery, or sort-order incorrect) then please let me know which (if any) of the HW Info Test aps I posted work on your device, and provide me with the logcat output:
HW Info Test (default) OMAP
HW Info Test 2 Qualcomm?
HW Info Test M IMAP
HW Info Test S Tegra 2
Last edited:
OP
paulscode
New member
- Thread Starter
- #252
The test will automatically download Mario 64 when you run it the first time (this is the only ROM I'm testing with at the moment until I finish fixing the remaining graphics problems, although you can "trick" the emulator into playing other ROMs by calling them "mario.n64"). Thanks for offering to help!
ScottJC
At your service, dood!
I don't mean to rain on your parade but that sounds dangerously close to breaking Emutalk's rules on rom downloading... Emutalk.net doesn't provide roms, and this kinda indirectly does provide people with a rom.
Plus you really shouldn't automatically give people roms, they should be able to get it themselves, absolves you of legal responsibility. Super Mario 64 is still being sold on the Virtual Console so Nintendo might not like this.
Still i'm not entirely sure on what our stance on this forum should be when it comes to this so i'd like to ask any other mod to weigh in on this.
OP
paulscode
New member
- Thread Starter
- #256
So, to summarize, to run the tests please place your ROM on your device's sdcard under the folder app-data/paulscode.android.mupen64plus/roms/ It must be called "mario.n64". I'll work on adding a simple GUI to the front-in so it isn't so confusing. The reason for all this in the first place was because vanilla mupen64plus is a command-line emulator, so as an app I had to hard-code the command-line arguments 
Last edited:
OP
paulscode
New member
- Thread Starter
- #257
Today's update:
- fixed shader bug on devices without Neon
- created separate SDL Scancode Finder app, removed scancode notifications from emulator app
- added hardware profiling to fix missing shadows and door stars in Mario64
- fixed crash when slide-out keypads or gamepads are opened or closed while app is running
- fixed crash caused by incoming calls or other view changes
- implemented Eeprom clock emulation
Test APK (source code)
I also built a simple SDL scancode finder, since the scancode notifications are no longer part of the emulator:
SDL Scancode Finder (source code)
Note: the hardware profiling is still new, so please let me know if you are missing shadows, stars, carpet, etc in Mario64, so I can improve the logic.
- fixed shader bug on devices without Neon
- created separate SDL Scancode Finder app, removed scancode notifications from emulator app
- added hardware profiling to fix missing shadows and door stars in Mario64
- fixed crash when slide-out keypads or gamepads are opened or closed while app is running
- fixed crash caused by incoming calls or other view changes
- implemented Eeprom clock emulation
Test APK (source code)
I also built a simple SDL scancode finder, since the scancode notifications are no longer part of the emulator:
SDL Scancode Finder (source code)
Note: the hardware profiling is still new, so please let me know if you are missing shadows, stars, carpet, etc in Mario64, so I can improve the logic.
It works really well i tested some games, bomberman hero works without problems, i tried yoshi story and backgrounds are missing and a lot of menu stuff, conker bad fur day has a lot of geometry missing.Overall it works nice and is very playable with good speed, i would prefere virtual controls on the top cause most of the action takes place on th bottom of the screen and im covering it with fingers.
Shadows are missing in mario.
Im on galaxy S.
i tested some games, bomberman hero works without problems, i tried yoshi story and backgrounds are missing and a lot of menu stuff, conker bad fur day has a lot of geometry missing.Overall it works nice and is very playable with good speed, i would prefere virtual controls on the top cause most of the action takes place on th bottom of the screen and im covering it with fingers.Shadows are missing in mario.
Im on galaxy S.
Last edited:
OP
paulscode
New member
- Thread Starter
- #259
Thanks. Can you post your logcat output after running the Test APK (you can use a free app called "aLogcat" from the market).
Alternately (if logcat doesn't work for whatever reason), you can install a free terminal emulator from the market and run the following command and send me the generated cpuinfo.txt file:
cat /proc/cpuinfo > /mnt/sdcard/cpuinfo.txt
Which (if any) of the "HW Info Test's" posted above show the shadows correctly?
So how you want me to do it, run aLogcat first, then emu then close emu and then save log in Logcat? Or just open Logcat after playing and closing emu ?
Does this version work with ARMv6 processors ?
Log:
http://www.mediafire.com/?kdp674dl1rd4yrq
This version has shadows but they flicker
Mupen64Plus-debug-hwinfo,-.001,-.001.apk
all others dont have shadows.
Here is log from this version:
http://www.mediafire.com/?eqws41e7weh945r
Does this version work with ARMv6 processors ?
Log:
http://www.mediafire.com/?kdp674dl1rd4yrq
This version has shadows but they flicker
Mupen64Plus-debug-hwinfo,-.001,-.001.apk
all others dont have shadows.
Here is log from this version:
http://www.mediafire.com/?eqws41e7weh945r
Last edited: