Author Topic: GLideN64 Android port  (Read 143420 times)

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #75 on: May 04, 2015, 05:59:44 PM »
Goody! Already looks perfect. ;D
Yoshi's Story is a BIG part of my childhood,as it is the first N64 game I remember playing,and I loved every minute of it,especially the rock remix from getting a Super Happy fruit.
I am curious how your framerate is,though I expect it to be really slow until those porting issues get fixed.

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #76 on: May 06, 2015, 12:11:39 AM »
@Gonetz et al

If you want to build mupen64plus-ae without using Eclipse whatsoever, here is the script to do so.  I just verified on Ubuntu 14.04 64-bit.

Code: [Select]
git clone https://github.com/mupen64plus-ae/mupen64plus-ae.git
cd mupen64plus-ae

android update project -s -p libs/extras/android/support/v7/appcompat
android update project -s -p libs/extras/android/support/v7/gridlayout
android update project -s -p .

ndk-build -j4
ant debug

I need to build an apk. I tied the scenario above, only for gliden64-integration branch and for target 21:

android update project --target android-21 -s -p libs/extras/android/support/v7/appcompat
android update project --target android-21 -s -p libs/extras/android/support/v7/gridlayout
android update project --target android-21 -s -p .
ndk-build -j4
ant debug

ant failed. Log file attached. Please explain me, what I do wrong?
Also please build apk with GLES3.1 version for me.
Note: you need to replace -DGLES3 by -DGLES3_1 in jni/Android.mk

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #77 on: May 06, 2015, 07:28:14 AM »
Ok, let me check into it and get back to you.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #78 on: May 06, 2015, 08:24:23 AM »
@Gonetz A few things
 - I updated the gliden64-integration branch.  Probably doesn't change anything but want to keep the branch up to date so it's easy to switch between them.
 - Using this source code (https://drive.google.com/file/d/0B0YqMPjGo3B2T1NkSzBfNDhHazA/view?usp=sharing) I was *not* able to build in Eclipse with -DGLES3_1.  I *was* able to build with Eclipse with -DGLES3.
 - You can build APKs easily from Eclipse in a pinch.  Right click the mupen64plus-ae project, go to Android Tools in the context menu, and select "Export Signed Application Package".  I was able to do this successfully.
   - One caveat, testers will have to uninstall their existing alpha build since you'd be signing it with a different key.
   - Or, you can choose Android Tools -> Rename Application Package right before you export, to allow them to keep their existing installation.

I will have to check the ant build issues later this evening (US eastern daylight time).
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #79 on: May 06, 2015, 01:17:20 PM »
I have a problem with updated branch - emulator crashes on start.
So, I returned to previous state.
I needed apk asap, so I took old GLES3.1 compatible sources, which proved to work.
"Export Signed Application Package" works, thanks!
Tomorrow I'll try to build my current code for GLES3.1

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #80 on: May 06, 2015, 03:59:50 PM »
@Gonetz At the risk of suggesting the obvious, be sure to Build->Clean from Eclipse after switching branches.  Also, I suggest deleting the ./gen/ directory as well, and let eclipse regenerate the resources, just to be safe.

A while back I noticed a crash the first time I built and ran the gliden64-integration branch.  Then I rebuilt and reran the app and the crash disappeared.  I've never seen that behavior before but worth mentioning in case you only tried once.

Front-end crashes are often caught and logged to mupen64plusae-v3-alpha/CrashLogs on the Android device.  Feel free to post them here.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #81 on: May 07, 2015, 09:50:15 AM »
@Gonetz - I made some updates to master and merged them into the gliden64-integration branch.  I had no problems building in Eclipse on Windows or Ant on Ubuntu 14.04.  Here is the build script I used for the latter:

Code: [Select]
#! /bin/sh

# Checkout project, switch to gliden64 branch, add gliden64 source
rm -rf mupen64plus-ae
git clone https://github.com/mupen64plus-ae/mupen64plus-ae.git
git checkout gliden64-integration
tar -xf mupen64plus-video-gliden64_gles30.tar.bz2 --skip-old-files -C ./mupen64plus-ae/jni/

# Initialize local android/eclipse files
cd mupen64plus-ae
android update project -s -p libs/extras/android/support/v7/appcompat
android update project -s -p libs/extras/android/support/v7/gridlayout
android update project -s -p .

# Build project
ndk-build -j4
ant debug
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #82 on: May 07, 2015, 12:33:47 PM »
I've pulled new changes, switched to gliden64-integration and successfully built my current sources with it.
I did just 2 corrections:
- in jni/Android.mk -DGLES3 replaced by -DGLES3_1
- in RSP.h I replaced
Code: [Select]
#define RSP_SegmentToPhysical( segaddr ) ((gSP.segment[(segaddr >> 24) & 0x0F] + (segaddr & RDRAMSize)) & RDRAMSize)
by
Code: [Select]
#define RSP_SegmentToPhysical( segaddr ) ((gSP.segment[(segaddr >> 24) & 0x0F] + (segaddr & 0x00FFFFFF)) & 0x00FFFFFF)

RDRAMSize is calculated as follow:

Code: [Select]
#ifdef OS_WINDOWS
// Calculate RDRAM size by intentionally causing an access violation
u32 test;
try
{
test = RDRAM[0x007FFFFF] + 1;
}
catch (...)
{
test = 0;
}
if (test > 0)
RDRAMSize = 0x7FFFFF;
else
RDRAMSize = 0x3FFFFF;
#else // OS_WINDOWS
RDRAMSize = 1024 * 1024 * 8;
#endif // OS_WINDOWS

May be wrong RDRAMSize causes problems, because when I use it in RSP_SegmentToPhysical, plugin does not work.
I don't know another way to know size of RDRAM array, only via try - catch. May be emulator can help its plugins to know RDRAM size?

If you have GLES3 device and tried my plugin with it, you noticed its bad performance. Yesterday I found the bottleneck. Frame buffer emulation is on by default. Beside frame buffer emulation by itself, two options are on by default: EnableCopyColorToRDRAM and EnableCopyDepthToRDRAM.
EnableCopyColorToRDRAM blit screen size FBO texture to smaller texture, which has size of N64 frame buffer.
Then content of that small texture is read into main memory with glReadPixels. I use GL_PIXEL_PACK_BUFFER to speedup it. This works without noticeable slowdown on PC. The content of read texture copied into N64 RDRAM.
EnableCopyDepthToRDRAM does the same but with the FBO depth buffer texture. Both operations are essential for correct emulation of many games.

I just tried to disable EnableCopyDepthToRDRAM but it did not help much.
However, when I disabled EnableCopyColorToRDRAM as well, speed problem gone.
It seems that my Shield can't process glReadPixels for each frame with descent speed even for small (320x240) regions.

glReadPixels is pretty old method of exchange data between video and PC memory. If you know better way, please share.

Today I finished with fixes in PC version. Tomorrow I'll release an update and continue to work on Android port. Dev. history also should be uploaded within few days.


Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #83 on: May 07, 2015, 01:09:16 PM »
Ahhh!,I really wanna test it on my x86 tablet with ES3.0 support just to help out.
But I am a dope when it comes to compiling things in general. :(

Extra curious since it is an intel x86 instead of a standard ARM device.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #84 on: May 07, 2015, 01:50:20 PM »
May be wrong RDRAMSize causes problems, because when I use it in RSP_SegmentToPhysical, plugin does not work.
I don't know another way to know size of RDRAM array, only via try - catch. May be emulator can help its plugins to know RDRAM size?

I would suggest posting an upstream issue to mupen64plus-core or mupen64plus-rsp-hle and tagging @bsmiles32 @Nebuleon @Gillou68310.  Might be a slight abuse of the term "issue" but I think they'd make an exception for you ;)

If you have GLES3 device and tried my plugin with it, you noticed its bad performance.

I was actually surprised at how fast it was for this early in the integration :)  13 FPS on a Shield Tablet in Super Mario 64 -- with no ES optimizations or frameskip -- is impressive IMO!

I'll take a look at your changes tonight if I can.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #85 on: May 07, 2015, 03:34:10 PM »
13 fps looks pretty bad, if you consider the fact that SM64 is one of the simplest Nintendo 64 games, and the Shield is a very powerful device.  This plugin looks really nice, especially the widescreen feature, also stuff that never worked right before is now looking nice (like Mario Tennis, it was a glitch party on old plugins, now it is nearly perfect on gliden64!). I really want to play my favorite n64 titles in widescreen on my TV using my old tablet (it got an HDMI output), it only have OpenGL ES 2.0 through, and Im affraid that the speed will render the games unplayable, since some games already lag A LOT with plugins like gln64 (Conker's Bad Fur Day and Mario Tennis being some title that goes below 30fps).
« Last Edit: May 07, 2015, 03:35:45 PM by gdark100 »
Motorola Xoom 2 ME:
OMAP CPU Dual Core @ 1.2 Ghz and PowerVR SGX 540 GPU
8.2'' 1280x800 Screen
1GB Ram Dual Channel
32 GB internal storage

Galaxy SII Lite:
NovaThor U8500 CPU Dual Core @ 1.0 Ghz and Mali-400MP GPU
4.0'' 800x480 Screen
768MB Ram
8GB internal storage

Huawei U8150:
Qualcomm CPU @ 532 Mhz, no GPU
3'' 240x320 Screen
256 MB Ram

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #86 on: May 07, 2015, 04:00:29 PM »
At this point,GlideN64 is taxing to the emulator itself with some heavy options enabled,and it reaches a cap really early on the most powerful Android devices because the emulator's capability is WAY below the capabilities of that device.

What we need is improved performance on the emulator's side itself because in reality,it is a tad slow.
Tis' the sad truth. :(
That's why we need overclocking and the VI Refresh Rate option too.
Maybe something similar to the way Dolphin started doing it in the Ishiiruka builds with a clock percentage setting.
Dolphin actually overclocks the native clock speed of the console it emulates,if I am correct.
(maybe set to Wii's default clock regardless)

What default clock rate does Mupen64Plus AE run at anyway compared to the norm?
The normal speed says 93.75 MHz while emulators generally use 100MHz.
If we could overclock that baby to 400MHz or even 600MHz,it may run really well.
Even 200MHz would help.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #87 on: May 07, 2015, 04:12:27 PM »
You guys, this is why developers usually don't submit such early builds to testers.  Tester expectations are usually not in line with how developers work.

Honestly, I was expecting 1-3 FPS with all sorts of bugs and artifacts, in such an early build.  To be able to port (or plan for) that much OpenGL code from PC to Android in that amount of time with no obvious flaws other than performance is nothing short of amazing.  It is a major testament to how well Gonetz must have architected and designed the plugin to begin with.

With some profiling and optimizations the FPS will continue to go up.  Good programmers focus on a good architecture up front, then optimize for speed at the very end.
« Last Edit: May 07, 2015, 04:14:23 PM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #88 on: May 07, 2015, 05:58:00 PM »
What we need is improved performance on the emulator's side itself because in reality,it is a tad slow.
Tis' the sad truth. :(
Must agree with you, yesterday I tried to play the old n64 version of Spiderman, that I used to play on computer when I was younger, for the nostalgia, and it was lagging a bit. It was not too slow, but the lag was annoying, so I started to play around with settings, and the only plugin that worked smooth was gln64, with the enhancements disabled, but the polygons started to glitch out with this plugin, and that was even more annoying. So I had to play the PS1 version, since it have a weaker hardware compared to the n64, it worked smooth as butter :)

But the worst is that Conker's Bad fur Day doesn't work well in any plugin, it is always below 30fps, and that is unplayable. I remember playing it well on may old Pentium III with a GeForce FX 5200 video card (it have some lag sometimes, but it was pretty smooth and very playable). Is that old Single Core x86 833mhz CPU better than the 1.2 ghz Dual Core ARM CPU my tab have? What about the over 10 years old GPU?

Well, point is. I already saw some people saying the plugin was a bit slow on some games even on high end machines (some "issues" on github), add that to the fact that the plugins mupen ae already have runs pretty slow on some games, and with lag on others, so thats the reason I said that I believe this one will only have full speed on recent, high end devices, and some games will probably still have issues with speed. But of course, I really, really hope to be wrong.
« Last Edit: May 07, 2015, 06:00:14 PM by gdark100 »
Motorola Xoom 2 ME:
OMAP CPU Dual Core @ 1.2 Ghz and PowerVR SGX 540 GPU
8.2'' 1280x800 Screen
1GB Ram Dual Channel
32 GB internal storage

Galaxy SII Lite:
NovaThor U8500 CPU Dual Core @ 1.0 Ghz and Mali-400MP GPU
4.0'' 800x480 Screen
768MB Ram
8GB internal storage

Huawei U8150:
Qualcomm CPU @ 532 Mhz, no GPU
3'' 240x320 Screen
256 MB Ram

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #89 on: May 07, 2015, 07:19:48 PM »
I don't care how slow it is,I just wanted to add a test result for graphics of an x86 Android tablet. :)

Android OS is a fairly limited one compared to Windows computers (OpenGL differences to GLES),so the speed differences are dramatic.

As for overclocking,it would fix the issue where Qualcomm does not give it sufficient power to run decently enough.
Using a higher Mhz would give it more power to run with a greater performance.
Of course this would make the battery drain faster though.