Author Topic: GLideN64 Android port  (Read 141032 times)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #150 on: May 19, 2015, 10:49:16 AM »
Thanks Gonetz :)

Yes, if we want to differentiate GLES support, then ideally we would build three different versions of the binaries and bundle them all into the same installation file.  We would then treat them as three distinct plugins in the front-end.  From a build point of view, this is very easy -- we would not need to actually duplicate the source code into three separate folders as you suggest.  We can simply add a few sections to jni/Android.mk to build three different variants of the plugin, where each binary has a distinct name like you suggested for the folder names.  We can continue to keep the folder structure in the mupen64plus-ae repository the same as what's in your upstream repository.

The bigger challenge, and I don't know the answer, is related to Android manifests, Google Play visibility, and installability.  In order to build the GLES3.1 binaries, we need to bump the manifest SDK flags (see some of the first commits in the gliden64-integration branch).  Unfortunately that prevents installing the app on older devices, which would largely defeat the purpose of this whole exercise.  I'll do some research and see if it's possible to include binaries built against a higher SDK into an app built against a lower SDK.  It wouldn't surprise me if there's a way to do it, but I will need to do the research and possibly tweak some of the project layout.

Updating the front-end settings system is easy enough to do at the end, once we figure the manifest stuff out.

Edit: Come to think of it, we are already doing this "build-against-higher-sdk" thing with the xperia touchpad library.  It's built against SDK 9 but the app minSDK is 7.  It throws a lint warning but it still builds.  Let me see if I can do the same for GLideN64...
« Last Edit: May 19, 2015, 10:55:29 AM 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 #151 on: May 19, 2015, 11:30:38 AM »
So besides making the GLES2 version render correctly and position stuff correctly,should it be primarily optimized for performance and non-crashing/non-freezing?

All about the GLES2 version:
And is it possible to bring code from Glide64 to it to fix some of the issues?
Or would you like to take a different approach and perfect the Glide64 plugin by placing as much of GLideN64 code as you can into it to apply most of the missing framebuffer effects and improve performance?

Just trying to stretch out the options here.

Offline gdark100

  • Green Team
  • byte
  • *
  • Posts: 48
    • View Profile
Re: GLideN64 Android port
« Reply #152 on: May 19, 2015, 11:38:36 AM »
So besides making the GLES2 version render correctly and position stuff correctly,should it be primarily optimized for performance and non-crashing/non-freezing?

All about the GLES2 version:
And is it possible to bring code from Glide64 to it to fix some of the issues?
Or would you like to take a different approach and perfect the Glide64 plugin by placing as much of GLideN64 code as you can into it to apply most of the missing framebuffer effects and improve performance?

Just trying to stretch out the options here.
if I was gonetz, I would focus on speed. From what I understood, the main focus of this plugin was emulation accuracy and some neat features. GLES2 doesnt support those features through, and also doesnt support some of the necessary stuff to run some effects correct. So, to avoid it being just another Glide64 for GLES2, he could work on speed. A bunch of games work slow on older devices, and be able to play those would be awesome  ;D (Conker's BFD and Mario Tennis are two of those games that i can't play on my phone cause its too slow)
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 littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #153 on: May 19, 2015, 11:40:35 AM »
I rebased the gliden64-integration branch in my own fork (so that I don't mess up other devs).  I have resolved my concerns about the Android manifest.  My branch builds and installs on Gingerbread devices (but obviously doesn't run GLES 3.x code) so all is well :)
https://github.com/littleguy77/mupen64plus-ae/commits/gliden64-integration

@Gonetz
Would you mind pushing your latest work to your GitHub repo?  If it's too "dirty" then perhaps on a branch?  Or else just post the source code here.  In any case, please let me know what flags to set and files to compile for each GLES version of GLideN64.  Once I have all that info, then I can test the builds, update the front-end, and we'll soon have your plugin in the master branch. 8)

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 #154 on: May 19, 2015, 01:16:18 PM »
I know that on GLES2,Banjo-Tooie has the working CCL bubble visuals,yet Super Smash Bros. has several broken effects like items,fireballs,and Samus' charge shot.
If only the several games would not cause the grey screen exit,we could know if the other buffer effects like Yoshi's Story's Jungle Puddle water,both Zelda's various effects including Majora title after-images,Conker's large list of effects,and Paper Mario's star speech visibility after Mario falls.

Maybe omitting the stuff that obviously doesn't work and is possibly causing the grey screen exits on GLES2 while keeping the rest that makes Tooie's bubble work and other games have certain working bits that don't work in other plugins.

That CCL bubble works,but paths can be seen through the Jinjo houses and the dynamic shadow is only a rectangle.

(I really want access to 5xBRZ so I can try it and see if it works,even if my device runs like trapped dirt.)
What number do I put to get 5xBRZ? I wished the names were implemented so I could select it directly.
Or is the shading not yet implemented within GLES2?

You should be able to do something similar to Rice while adding in the 5xBRZ.
I mean if you have to drop Boost library and GlideNHQ from the GLES2 portion for some reason.

Or maybe you can get GlideHQ running for GLES2 if the GlideNHQ refuses to work.

Edit: Tested Gex 3 Deep Cover Gecko and it looks nearly perfect with water and other effects!
Just the general bits of textures changing to the wrong part briefly in corners of a few object models.
Flawless text,remember that I am using the Power VR fix build which also fixes my Qualcomm issues.
« Last Edit: May 19, 2015, 02:14:54 PM by retroben »

Offline DonzBegonz

  • byte
  • *
  • Posts: 12
    • View Profile
Re: GLideN64 Android port
« Reply #155 on: May 19, 2015, 05:02:26 PM »
@Gonetz and @littleguy

I've been following your guys' progress on this emulator forum for quite some time now. Is there any ETA on when the new mupen will be ready to go? I'm running on a Nvidia shield tablet and I'm just dying to try out the new video plugin. I'm also more than happy to do testing for any games for you guys. as always, keep up the great work!

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #156 on: May 20, 2015, 12:09:08 AM »
@littleguy I'm finishing with shaders related code refactor. I think that it will be ready today and I'll upload the result on GitHub. GLES20 and GLES3+ will use different source files.

@DonzBegonz I already posted link on apk with GLideN64-GLES3.1
If you have dev tools, you may download current souses of the emulator and the plugin, switch to gliden64-integration branch, copy GLideN64 sources to jni and build the version to test.

@retroben
"All about the GLES2 version:
And is it possible to bring code from Glide64 to it to fix some of the issues?
Or would you like to take a different approach and perfect the Glide64 plugin by placing as much of GLideN64 code as you can into it to apply most of the missing framebuffer effects and improve performance?"

No, it is not possible.  Glide64 and GLideN64 have almost nothing in common.


Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #157 on: May 20, 2015, 12:28:32 AM »
Okay,I didn't expect it to be completely impossible.

I am left hoping for shading and MultiSampling access on GLES2 since Rice has something like those already usable.

Glad to have helped in any way by testing the "Power VR fixes" build on Qualcomm with great results. ;D

Edit: I don't know how,but Gex 3 runs really fast in-game with FBEmulation disabled.
I didn't expect that much of a jump,but the graphics are still perfect in that game without the buffer.

Edit2: Thought I should point this out...

I tested A SM64 hack called Shining Stars 2 Mirror Madness (SS2MM) and it has all black textures on Android GLES2 just like the Star Road issue #535 on Windows.

I know these are identical since normal SM64 works in GLES2 on GlideN64 for me while the hack has black textures.
« Last Edit: May 20, 2015, 10:20:38 AM by retroben »

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #158 on: May 20, 2015, 01:41:23 PM »
I've uploaded the changes on GitHub. Sorry for delay. I met bad problem: the plugin does not work anymore on my Note 2. It now has the same issue as other Mali400 devices - most of textures are missing. I thought that I broke it during my  code changes and spent hours trying to find where I broke it. I found nothing. Moreover, I installed my own apk with GLES2 support and it does not work either. I don't understand, what happened. I saw it working with my own eyes. I saw log messages from the plugin in debugger, so it was really my plugin. Now the same version does not work.

Anyway, the code is tested and debugged on other devices. Note: PowerVR/Qualcomm needs define PowerVR_SGX_540, see GLSLCombiner_gles2.cpp
I've attached project files for GLES2 and GLES3 for reference.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #159 on: May 20, 2015, 03:12:43 PM »
Well that stinks. :(
I don't see how it could stop working randomly with the same build.

Try using the reload app resources function in the main settings to see if that could fix it in some odd twist.

Edit: I decided to try the GLES2 build on my x86 tablet and it still does not run it and instead goes 0fps on a black screen,even when changing the settings in a different profile.
So your x86 Android version of the plugin must be really broken and non-functional,no offense.
I am curious if my x86 tablet would run the ARMv7 version of the plugin via libhoudini?
Perhaps if I copy the ARMv7 file into the proper data/data directory and replace the x86 version of gliden64.so then it might actually run. (or not,because Intel has issues)

Edit2: Didn't work,why must x86 Android suck so much? :'(
« Last Edit: May 20, 2015, 03:39:30 PM by retroben »

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #160 on: May 20, 2015, 03:34:05 PM »
Awesome, thanks Gonetz.  I will take a crack at this tonight.  To keep things simple, I will not put the powerVR specific stuff in the master branch.  The combinatorics of all three GLES versions and multiple device-specific versions would make the front-end a headache and the APK large.  Hopefully there will be a long-term fix for the device-specific stuff, and in the meantime we can always make a single-commit branch that changes the device defines.

I actually ran into another issue, again with the Android version stuff.  We can keep the manifest minSDK value at 7, allowing it to be installed on older devices.  The front-end runs fine on Gingerbread with the GLideN64 plugin.  The issue is that GLES 3.1 requires the entire native codebase to be compiled against the SDK 21 platform binaries.  This means that some (but not necessarily all) older devices will not be binary-compatible with the native code, and will crash as soon as the emulator is loaded.  It all depends on how the platform binaries differ between 7 and 21, and how many of those differences we are using in native code.  But I have at least one data point (Xperia Play, Gingerbread) that crashes when built with APP_PLATFORM=21.

I'm going to have to do some experimentation to see if a solution can be found.  This may postpone merging to the master branch.  Though at the very least I should still be able to get all three GLES variants working in a branch, with the GLES-specific config tweaks you requested a few posts back.
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 #161 on: May 21, 2015, 12:22:02 AM »
If you will need any kind of modifications in the plugin, let me know.
Today I'll try to attach texture library to the plugin.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #162 on: May 21, 2015, 07:45:38 AM »
@Gonetz - Do you want me to include all three GLES variants (2.0, 3.0, 3.1), or will just two suffice (2.0, 3.0)?  The reason I ask is because you do not include the 3.1 variant in your makefile attachment above, so I'm not sure if you are intending to deprecate/obsolete that variant.
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 #163 on: May 21, 2015, 09:56:25 AM »
All three. makefile for GLES3 and GLES3.1 is almost the same. You just need to define GLES3_1 instead of GLES3 and probably link 3.1 lib (-lGLESv3.1 ?)

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #164 on: May 21, 2015, 10:09:19 AM »
I need help again.

I'm trying to attach texture library. Steps:
- merge boost branch into gliden64-integration
- pull latest GLideN64 master
- correct makefile

I stuck on linking necessary libs. GLideNHQ needs libpng, libz, libboost_system, libboost_filesystem.
I tried to add
Code: [Select]
BOOST_LIBS := $(JNI_LOCAL_PATH)/boost/lib/
...
LOCAL_LDLIBS :=         \
    -lGLESv3            \
    -llog               \
    -lz                 \
    -lpng               \
    -L$(BOOST_LIBS)     \
    -lboost_filesystem-gcc-mt-1_53
but linker can't find libpng and boost libs. Compilation works ok. I found one issue in GLideNHQ code, the fix is already in master.

makefile attached.

Note: on PC GLideNHQ is a separate library linked with the main project. Here I added just added GLideNHQ sources files to GLideN64 ones. Not sure that it will work.