Author Topic: GLideN64 Android port  (Read 143302 times)

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #210 on: May 24, 2015, 01:22:01 PM »
@retroben I don't remember such details.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #211 on: May 24, 2015, 01:36:52 PM »
When the little goomba finds Mario and gets Goombpa/Goomb-ario to help him,it takes you to a scene with him in a bed.

Then one of the star people appears to tell him where to go.
During this moment,the star brightens periodically.

I was right!
The noise is emulated correctly when the feature is enabled.
I first  used a custom profile with EnableNoise unchecked,and the star was going bright and dim without varied pixels.

Then I exited the game and selected the default GLES2 profile and hit resume.
BAM! The noise effect is fully visible on the star when he periodically goes brighter.
To get to this point,all you need to do on a new game is go to Peach,lose to Bowser,and easily wait until you get to that scene after Goomb-ario where Mario is in a bed in the Toad's house and the star person with the white mustache (depicting wisdom) appears and "telepathically" speaks to him.

The point is that noise emulation works perfectly fine on (at least my) GLES2.
GLideN64's MultiSampling is also working on my GLES2.
« Last Edit: May 24, 2015, 01:38:55 PM by retroben »

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #212 on: May 24, 2015, 02:03:40 PM »
I just finished GLideNHQ no-boost edition. Everything seems to work now:
https://drive.google.com/file/d/0B0YqMPjGo3B2SExtSkFnQmgycms/view?usp=sharing

Great!

Is it possible to add FreeType library to mupen64plus-ae?

Anything is possible :P  I can take a look.  How essential is it?  I believe the core or UI-console use it as well, but we never got around to integrating it since we already have a front-end with overlapping functionality.
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 #213 on: May 25, 2015, 12:49:48 AM »
Text drawer is not critical, but pretty much essential. First load of large texture pack may take 1-3 minutes. That is user starts a game with texture packs and watches black screen for few minutes. When user exit game, plugin saves texture cache, which also takes time. On second start texture pack loads from the cache, but it also several seconds for large packs. All this time user will not know what is going on. Text drawer shows what is loading atm.

I could use font texture as Glide64 does, but with FreeType the result is much nicer. Cite: "If you need FreeType (a library to render fonts), you'll need to cross-compile it. Note: The Android system uses FreeType but internally it doesn't expose it to native apps." As I see, it's technically not hard to add FreeType to the project, but it is for you to decide. Since you don't need boost anymore, you may use freed space for that little lib :)
« Last Edit: May 25, 2015, 12:51:35 AM by Gonetz »

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #214 on: May 25, 2015, 09:25:33 AM »
Those are good reasons to integrate FreeType.  Plus it would be nice to have the text from UI-console on the screen as well.  I'm bump it up my priority list.

@littleguy - I doubt that my plugin can be comparable to the other plugins in terms of speed. It's too complex and run slow even on top GLES2 devices. Remove complexity and you will get gln64.

That's an interesting comment actually.  This may sound like blasphemy, but if there were a set of build flags/config options that removed GLideN64's advanced features and made it equivalent to gles2n64, then we could drop the gles2n64 plugin from the mupen64plus-ae repository (one less thing for us to maintain).  I'm guessing GLideN64 is too far evolved to make that a realistic proposition, but I thought it was worth mentioning.
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 #215 on: May 25, 2015, 11:19:28 AM »
I've fixed texture problems with Mali400. Tested on Galaxy 2 and Galaxy Note 2. Changes pushed to master.
Link to apk with the fix and hack for PowerVR GPU:
https://drive.google.com/file/d/0B0YqMPjGo3B2NTNuNGhxTDJXRG8/view?usp=sharing

I'd like to provide apk with texture library support, but unfortunately the build from gliden64-glidenhq branch works only on my Shield device. On any other device it crashes on any rom even with default settings and default graphics plugin.
@littleguy, please check, does it work on your devices?

Regarding possible gles2n64 replacement: I need to find time and use debugging tools provided by NVidia to profile my code and find performance bottlenecks. I need to clone myself and probably not once to complete all necessary tasks.

Attached is corrected makefile for gliden64-glidenhq branch, to build my noboost texture library. I made test build of desktop version for my users with updated library and waiting for feedback. I'll push sources tomorrow if nothing wrong will be found.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #216 on: May 25, 2015, 11:26:46 AM »
*trips on a rock* Okay,I will try out that build to see if it effects qualcomm in a good way.

If only reprogramming the GLES2 part of GLideN64 as a seperate plugin for less complexity and more performance wouldn't take such a long time,then you could try to replicate Glide64mk2's framebuffer
(fixing black screen Conker and Banjo-Tooie's dynamic shadow plus puzzles the hacky way) while still having the rendering and buffering capabilities like Tooie's CCL bubble,both zelda's lens of truth,Yoshi's Story's water,and maybe even fix some other effects that aren't appearing because of framebuffer failures.

I really think it is about time to dig deeper in Mupen64Plus AE to increase performance on the core and RSP level and also get features like overclocking and VI Refresh Rate.

Sorry if I am being too obnoxius and pushy,but its time Mupen64Plus AE gets a more premium performance capability so low end devices can even run it at full speed.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #217 on: May 25, 2015, 11:34:52 AM »
gdark100 should test it to see if it fixes textures on his device.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #218 on: May 25, 2015, 02:06:05 PM »
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.

I'd like to provide apk with texture library support, but unfortunately the build from gliden64-glidenhq branch works only on my Shield device. On any other device it crashes on any rom even with default settings and default graphics plugin.
@littleguy, please check, does it work on your devices?

Yes, I have the same problem when setting APP_PLATFORM to android-21, which is necessary for GLES 3.1.  If you build against android-18 (giving you GLES 3.0), you won't have any crashing (binary incompatibilities) on really old devices.  Of course then you lose the GLES 3.1 variant.  If you look at my branches, you can see the changes in Application.mk to permit the GLES 3.0 variant, and then the changes to permit the GLES 3.1 variant.

I have researched the problem and it is a known issue in various android communities (e.g. http://stackoverflow.com/a/27093163/254218).  Much of the standard library has been redefined in the android-21 binaries (substituting macros or inlines or some such thing).  I have no idea what google was thinking (as usual).  I know at least one way to solve it: GLideN64 GLES 3.1 variant can be built against android-21 and the remainder of the native code can be built against android-18.  This is not as simple as setting a flag, however, and actually requires restructuring a lot of directories in mupen64plus-ae.  I will try to get something working, hopefully tonight if I can get some free time.

Apparently CrystaX-NDK will also solve the problem and is a drop-in replacement for vanilla NDK.  Unfortunately I made a quick test and had some build errors in SDL2.  That's another avenue I'm pursuing.
« Last Edit: May 25, 2015, 04:01:44 PM by littleguy »
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 #219 on: May 25, 2015, 02:10:27 PM »
I really think it is about time to dig deeper in Mupen64Plus AE to increase performance on the core and RSP level and also get features like overclocking and VI Refresh Rate.

This is not really the best place to make such a request.  We are using the standard upstream core.  Any performance gains are better addressed by upstream devs.  Gillou is the only person who frequents this forum who might be able to help, and he also reads the upstream discussions.  Keep in mind Gillou has been a part of this project almost as long as I have.  All the easy stuff has already been done.  It's not a simple matter of time or willpower.  Again, your hopes and dreams are most likely to be resolved if you become more active in the upstream discussions.
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 #220 on: May 25, 2015, 02:32:22 PM »
Okay then,I know that increasing performance is often the hardest thing to accomplish,especially on a different OS and architecture like Android and ARM,not to mention already doing some optimizations to fix the sluggishness of initially porting it. :)
It would need the MIPS equivalent of how DraStic runs so speedy,but that was a little less difficult because the general architecture of NDS matches Android's.

It would be cool to see how it runs with OC'ing and VI Refresh Rate,but I should continue this idea on upstream.
Even if it could be done for downstream only by copying upstream,adding the features,and then porting it to downstream so that way we wouldn't upset the balance of the primary upstream.

Or simply put,making an upstream branch just for implementing these features and porting them when testable or complete.
These would just be for now before getting into the nitty-gritty of core and RSP performance improvements.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #221 on: May 25, 2015, 03:59:04 PM »
We are using the upstream modules as-is.  There is no porting or modification here.  Any performance gains made upstream will be immediately available in mupen64plus-ae.  At this point, mupen64plus-ae is simply a user-friendly front-end and a bit of glue code.  Once the emulator starts running, it's almost entirely upstream code that's running.  The only downstream code involved during emulation is the input handling, and that is not a performance bottleneck.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Gillou68310

  • Developer
  • long
  • *****
  • Posts: 112
    • View Profile
Re: GLideN64 Android port
« Reply #222 on: May 25, 2015, 04:06:51 PM »
@littleguy what about extracting gles3.1 headers + lib from ndk into the jni folder. So can keep the app platform version and use gles3.1 as an external library? I'm just think out loud not sure it's actually possible to do  ;)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #223 on: May 25, 2015, 08:49:25 PM »
I've fixed texture problems with Mali400. Tested on Galaxy 2 and Galaxy Note 2. Changes pushed to master.
Link to apk with the fix and hack for PowerVR GPU:
https://drive.google.com/file/d/0B0YqMPjGo3B2NTNuNGhxTDJXRG8/view?usp=sharing

I finally got around to testing on my Tegra3-based 2012 Nexus 7.  Unfortunately I only get random pixels when running GLES 2.0 variant (all that my device supports).  This occurs for both the head revision of GLideN64 on GitHub, and the APK you posted here.  Sorry I didn't test this sooner, been focused on other things.

 
« Last Edit: May 25, 2015, 08:53:00 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 #224 on: May 25, 2015, 10:48:38 PM »
Textures working here on Mali 400MP, just with minor glitches. performance is not too bad, but a bit slow. Will test on PVR when I have time.

@littleguy - I get those random pixels at the startup, but they disappear and the actual game start playing after 2-3 seconds.
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