Porting Mupen64Plus to Android
- Thread starter paulscode
- Start date
ihearpixels
New member
Don't like it?
Make your own plugin that is truly under the GPL.
Wouldnt be the first time someone made something to escape the shit that is anything non GPL....
OP
paulscode
New member
- Thread Starter
- #184
Nice article. I have to admit, I have typically played the role of the kernel developers who set out to create a complete system - I prefer to bring together components that other developers have spent years perfecting, rather than trying to reinvent them myself from scratch.
OP
paulscode
New member
- Thread Starter
- #185
Progress update on my project: I've been working out some graphics issues with Pelya's SDL port when OpenGL ES code is compiled using the new NDK r5b. That may seem to be a bit off track, but ultimately this is another one of the important components of the project. I haven't finished porting my statically-linked project to JNI yet, due to some weird compiler problem, where it is reporting a syntax error in stdio.h. Not sure if it is an NDK r5b issue or (more likely) user error. I'm working with folks on both problems via other forums.
Well, i'm not sure you need the complicated pleya SDL port. My "port" which can be found in the droid64 github repository is really minimal with dummy video/input etc. I don't see the need to use SDL video at all and you could even probably remove SDL completly from the port, but if you already got it working ...
OP
paulscode
New member
- Thread Starter
- #187
Right, my OpenGL ES project is separate from my Mupen64Plus project at the moment. Of course once the core and dynarec are working, a more complete SDL will be essential for all the input/output components, and Pelya's port is the most complete and debugged one I am aware of for Android (and Pelya himself is one of the most helpful developers I've worked with as well).
--EDIT--We got my OpenGL ES project working (just required updating a few packages on my computer required by the new NDK version). Shifting focus back to porting the working statically linked Mupen64Plus core/dynarec to a dynamically linked JNI project.
Now I've got to figure out why it thinks there is a problem with stdio.h. The line the compiler is complaining about is this:
Code:
int printf(const char *, ...);--EDIT 2--
:blink: Wow, I'm an idiot. Spot the problem, anyone?
Code:
...
#ifndef __WIN32__
#ifndef __ANDROID__
# include <ucontext.h> // extra signal types (for portability)
#else
#define EXIT_SUCCESS 0
#define MUPEN_VERSION "1.5_android_0.1a"
#include <stdlib.h>
#include <android/log.h>
#define printf(...) __android_log_print(ANDROID_LOG_VERBOSE, "new_dynarec", __VA_ARGS__)
#endif
# include <libgen.h> // basename, dirname
#endif
#include <sys/time.h>
#include <sys/stat.h> /* mkdir() */
#include <errno.h>
#include <stdio.h>
...
Last edited:
Oh alright. But really thanks for the quick response! it is much appreciated.
OP
paulscode
New member
- Thread Starter
- #192
Yes, I tried it out, and it runs shockingly well on my phone. Mario flys at double speed (actually not really playable because it is too fast!) This definitely gives me motivation to continue my project. Hopefully his project is based on Mupen64Plus so I can take a look through the source code.
It shouldn't be too hard to figure out if it's based on Mupen64Plus. Can you run strings or objdump on the binary and see if there's anything interesting?
I guess the benefit of being the first to release an n64 emulator for Android is it is the only option out there, so you can charge whatever you likeAs soon as another competitor or two hit the market, Yonghz will no doubt release a Lite version.
Yeah you're right. I'm using the Tiger GBA and Tiger NES etc emulators for Android that are free
It's for sure based on mupen64plus and gles2n64 plugin. I'm also almost sure it's the version worked on by zottd since they do release things together. He must provide source code but i'm not sure he will.