Author Topic: GLideN64 Android port  (Read 117330 times)

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #30 on: April 20, 2015, 01:43:01 PM »
Yes  ;D,commit fa61986 adds support for armeabi-v7a. (the armv7 library)

Good luck everyone.  :)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #31 on: April 20, 2015, 02:48:23 PM »
@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
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 #32 on: April 21, 2015, 07:18:36 AM »
Actually I prefer to edit code in IDE, but possibility to use command line is always handy. Thanks!

Offline Gillou68310

  • Developer
  • long
  • *****
  • Posts: 112
    • View Profile
Re: GLideN64 Android port
« Reply #33 on: April 21, 2015, 07:57:10 AM »
@Gonetz I created a new branch with the boost library compiled for all platforms in case your interested:
https://github.com/mupen64plus-ae/mupen64plus-ae/tree/boost

Instructions on how to use it are here:
https://github.com/MysticTreeGames/Boost-for-Android

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #34 on: April 21, 2015, 01:07:42 PM »
Will the other plugins take advantage of Boost as well?
So if someone like myself intends to do performance comparisons between them and GlideN64 when the port is completed.

FireTV would be great for testing because it is pretty weak since it has ancient Qualcomm
drivers ( V@15.0 ) when most other devices have V@66.0 and later.
Hopefully TechVendetta,rbox and the other XDA devs can eventually finish the Custom CM12 ROM with the latest driver baked into it.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #35 on: April 21, 2015, 01:47:16 PM »
Boost is just a set of utility libraries; it doesn't "boost" performance just by using it.  It's just being used in glide to handle non-ASCII filenames in the texture packs.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #36 on: April 21, 2015, 04:07:35 PM »
Oh yeah,it would only help if they were all ported from the most superior versions
(Mudlord Rice 6.1.4 for fastest performance) and would need custom changes for it to even have any effect.
But that would be WAY too much trouble.
Forget I asked.  :P

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #37 on: April 22, 2015, 12:22:11 PM »
@Gonetz I created a new branch with the boost library compiled for all platforms in case your interested:
https://github.com/mupen64plus-ae/mupen64plus-ae/tree/boost

Instructions on how to use it are here:
https://github.com/MysticTreeGames/Boost-for-Android

Thanks! I'll check it.

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #38 on: April 22, 2015, 12:27:42 PM »
Boost is just a set of utility libraries; it doesn't "boost" performance just by using it.  It's just being used in glide to handle non-ASCII filenames in the texture packs.
Glide64 does not use Boost at all.  GLideHQ uses it to scan hires-textures folder and load texture files. It also used for some system-specific task IIRC. GlideHQ also use Boost threads for multi-threading processing of loaded textures. I replaced it by  c++ 11 threads in GLideNHQ.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #39 on: April 22, 2015, 02:58:53 PM »
So it improves the speed and reliability of loading hi-res textures and possibly reduces any CPU overhead from using them or the xBRZ enhancement.
About the plugin,I know that a main factor of performance is maintaining a lower CPU overhead much like Mudlord Rice 6.1.4 does compared to Glide64 with and without "read every frame (slow)" used,reaching 50-80% with Banjo-Tooie on my single core toaster when running more intensive games like Banjo-Tooie.
The only other actually much more intensive game I can think of is Conker with 30fps and major skipping.

Fact: Banjo-Tooie was way too good for the N64 to handle and was rushed like the first game,which is why it has internal frameskip in addition to rugged counter factoring usage as seen when on an actual system. *shudders*
(less noticable in childhood)

I can manage to barely run it smoothly at 60fps using my GS code on PJ64 2.1 with Rice.
Though Glide64 essentially runs Smash Bros. flawlessly at a solid 60fps,even on Apollo64.
Too bad the Android one lags behind by comparison,but GlideN64 should easily close the gap.

I hope that GlideN64 takes full advantage of multi-threading for greater performance.

Could someone request an overclocking feature on upstream,either VI Refresh Rate style or Dolphin Ishiiruka style with a percentage bar.
Retroarch already has a form of VI Refresh Rate on their N64 core,maybe the source code can be looked through.
I would want it for smoother framerates on Banjo-Tooie and especially Conker by setting it to 2200 to clear out the remaining jitters,but the expense of lost timing stability.

Sorry for being so annoying and needy,just stoked and pumped up.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #40 on: April 22, 2015, 03:26:31 PM »
Multi-threading and overclocking were actually both discussed in the upstream google groups forum on two separate threads recently.  I think it was William Shipley who described it best, and the takeaway message was that multi-threading buys very little in performance due to the overhead penalties, games are generally not CPU bound in the areas that are easy to parallelize, and the code is much harder to write and maintain.  The last is especially important for a distributed project with only a handful of volunteer developers.

I believe Nebuleon described the overclocking thing in a different thread.  You're just trading off one thing for another but at the end of the day you are no better off than where you started.  You get higher internal processing rates but lower FPS or something like that.  You'll have to dig up his post for a more accurate explanation.

Edit:
https://groups.google.com/forum/#!searchin/mupen64plus/multi/mupen64plus/6iz4onBpOEw/-CE-9yY9XH4J
https://groups.google.com/forum/#!topic/mupen64plus/dQ7Rw8W9_jA
« Last Edit: April 22, 2015, 03:30:40 PM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #41 on: April 22, 2015, 05:15:13 PM »
That's a shame,I guess the primary course of action would be to lower the CPU head as much as possible without making it unstable or inaccurate.
Is it possible to increase single-threaded performance in any way such as a pipeline of sorts?

I kinda wished there was a performance/accuracy slider or setting so you could put it further on performance for those slower running games including Smash Bros. from not being able to exceed 60fps,even on smaller spots with two fighters.

Even with my x86 tablet (pretty strong,but only 1gig ram) where Banjo-Tooie runs much faster,I would sometimes hit a wall of performance limits.
It is always spots like the HailFire Peaks Icy Side's ledge above the oil rig.

While I am still here,is there any way to disable the native N64 noise effect to make it look prettier for HD?
One time,I managed to make it look clear,but whatever I changed stopped working after a while.

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #42 on: April 23, 2015, 01:10:56 PM »
Hello,

Sorry, but I need help.

My first goal is to make my current code somehow compatible with Android.
It was once ported to Mupen64Plus AE. I used version 2.4.4 I added support for GLideN64 settings to the GUI. Attached is a patch for mupen64plus-ae, which does that. Thus, I had somehow working Android version of GLideN64, which I could test. I donít know, how to make GUI support for my plugin in the current version of the emulator. So, I returned back to my hack, and just replaced old version of the plugin code with the actual one. Of course, I got tons of new C++ errors. My old code was GLES2 compatible. Today I found that make it GLES2 compatible again is not easy. I need any working result ASAP, so I choose an easy way Ė compatibility with GLES 3.1 It supports almost everything I use in my code, at least I found most of necessary functions. GLES 3.1 supported only since android-21 platform, that is by most recent Android devices. Ok, itís not a problem, I have such device. I spent a day on code fixing and finally built an apk, which uploaded on the device. The program crashes on game start. It was expected, since I did not fix work with shaders. Surprise was that it crashes with any other video plugin. I built apk with old code of the plugin Ė the same result. I should say that I modified AndroidManifest.xml to force it use 21 SDK. May be it is the reason. The fact is that I canít use my old hack for work with my new code.

I tried to add my plugin to the current emulatorís code, which I successfully build and run yesterday. It seems that the project does not seen it :(

I need help to solve 2 problems:
1. Include my plugin to the main project, so it will be compiled by NDK.
2. Get any support from the GUI to be able to select my plugin as the current one and debug it.

I uploaded my today code here:
https://drive.google.com/file/d/0B0YqMPjGo3B2dXl5WGowT0F5alU/view?usp=sharing
Unpack it to jni folder and try to build. It should compile if you know how to include it to project compilation.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #43 on: April 23, 2015, 02:04:39 PM »
My old code was GLES2 compatible. Today I found that make it GLES2 compatible again is not easy. I need any working result ASAP, so I choose an easy way Ė compatibility with GLES 3.1 It supports almost everything I use in my code, at least I found most of necessary functions. GLES 3.1 supported only since android-21 platform, that is by most recent Android devices. Ok, itís not a problem, I have such device.

I can only hope that means you can at least try to do the same thing you did with the PC version,but instead with GLES2 and GLES3.1 so less modern ES2 Android devices can still use it too.
(I'm tired of being stuck with obsolete junk) :'(
Otherwise I myself would be stuck with my 1GB Intel tablet as the only way to use your wonderful plugin.

Unless you decide to release the older test build alongside it or test various newer parts to make a lesser version that still works on the old GLES2 compatibility.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #44 on: April 23, 2015, 04:46:20 PM »
@Gonetz

Thanks much for all your hard work!  I will definitely help with getting your plugin integrated, and the UI fixed.  Let me take a look at what you have done tonight, and I'll get back with you with a plan for moving forward.  Like everyone here, I'm really excited that we're at this stage!
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version