PaulsCode Forum

Mupen64Plus AE => General Discussion => Topic started by: Gonetz on April 17, 2015, 01:03:51 AM

Title: GLideN64 Android port
Post by: Gonetz on April 17, 2015, 01:03:51 AM
Hello Everybody!

I'm Sergey 'Gonetz" LIpskiy, author of GLideN64 graphics plugin:
http://gliden64.blogspot.ru/

I'm finished with PC version of the plugin:
http://gliden64.blogspot.ru/2015/04/early-release.html

and now I'm planing to port it to Android.

I already had Android port of my work running with Mupen64Plus Android Edition
http://gliden64.blogspot.ru/2014/07/android-port.html

The code changed a lot, so I need to make that work once again.

I counted to get help from Mupen64Plus AE team. But I see some kind of desolation here.

Where is  Paul Lamb?

Who is in charge atm?

I need to settle technical questions with source code repository, with GUI development etc.
Title: Re: GLideN64 Android port
Post by: xperia64 on April 17, 2015, 05:53:55 AM
I'm not exactly sure where Paul is currently.
Currently the project us kinda on hold until we can get a functioning buildbot again because it's a pain to test things otherwise. I may see about trying to set up a raspberry pi for that purpose.

Previously, littleguy handled most of the upstream syncing. For development purposes, a new branch should be created for this plugin, but everything that goes into an official release should be approved by upstream mupen64plus. Again littleguy knows more about this.

BonzaiThePenguin was the most recent person to work on the GUI, so he would probably be best  to ask.
Title: Re: GLideN64 Android port
Post by: littleguy on April 17, 2015, 06:55:20 AM
@Gonetz Awesome!  I can definitely help guide you through the sync process.  I have not touched the code in about a month, since I have have been swamped IRL and the buildbot isn't working so it's a pain to get it to testers.

Can you successfully build the project from source?  The instructions on the main page are up to date and should provide all the info you need.  But if not just let me know.  Once you have an easy way to build and test, we can talk about possible workflows for integrating and testing on Android (there are several reasonable approaches).
https://github.com/mupen64plus-ae/mupen64plus-ae
Title: Re: GLideN64 Android port
Post by: Gonetz on April 17, 2015, 08:36:36 AM
Thanks for the answers!

I did not finish with my sources cleanup, it will take few days. Then I need to install building environment for Android. I'm planing to install Linux for that on my PC. Anyway, when the building environment will be ready, I'll try to build the current master of the emulator, then I'll try to apply my old patch, which makes the emulator compatible with old version of my plugin. Then I'll release my sources and we can start to work together.

Regarding the sources: currently your project keeps all its code in its git repository. There is a possibility that GLideN64 will be included into several emulation projects, e.g. Project64 and original Mupen64Plus. It will be tiresome to support your own branch of the plugin. I suggest to include GLideN64 to your repository as a submodule. In that case synchronization will be much easier.
Title: Re: GLideN64 Android port
Post by: littleguy on April 17, 2015, 12:58:20 PM
Awesome.  We actually are using a submodule-like workflow, but not using git-submodule specifically.  This is very much intentional, as git-submodule makes it really easy to break the repository if not all devs on the team are git experts.

For a while we were using git-subtree since we had significant differences with upstream.  But since the new year we have been using vanilla upstream for all modules:
http://www.paulscode.com/forum/index.php?topic=1861.msg14174#msg14174

The current workflow is to simply mirror the upstream repositories into our repository.  The mirroring is done manually so that we can pick and choose which upstream version to use (the same philosophy used in git-submodule).  The manual mirroring is done using this script:
https://github.com/mupen64plus-ae/mupen64plus-ae/blob/master/tools/pull-upstream.sh

See the comment at the top of that script for more discussion on the workflow/rationale.  One nice thing about the approach is that it's very easy to test upstream forks -- you simply run the script and specify the non-default branch/fork.  Great for validating upstream PR's.

For GlideN64 I had imagined using the same approach.  Your repository would be master and we would simply mirror it into our repository from time to time, unchanged.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on April 17, 2015, 05:09:28 PM
I may have some free times in the following weeks, I would be happy to help integrating gliden64 in the android branch. :)
Title: Re: GLideN64 Android port
Post by: littleguy on April 18, 2015, 08:55:35 PM
@Gonetz I'm pulling the latest upstream versions down to mupen64plus-ae.  I'll let you know when we're up to date.

@Gillou68310 In case you missed it, I'm getting one hiccup with building the latest from upstream.
https://github.com/mupen64plus/mupen64plus-core/commit/9f3385b9960e11f179756a588867fac6f9a390f7#commitcomment-10790453
Title: Re: GLideN64 Android port
Post by: Gonetz on April 19, 2015, 03:44:49 AM
Hello again,

It seems that I need help with emulator's build.

Details:
- OS Ubuntu 14.04 64bit with updates

- Java. java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

- Android SDK installed

- Android NDK r10d

- Eclipse with ADT plugin

- mupen64plus cloned
git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

- mupen64plus projects imported to Eclipse, Native Support enabled.

run Project->Clean mupen64plus-ae
got Problems:
Description   Resource   Path   Location   Type
The container 'Android Dependencies' references non existing library '/home/sergey/WS/mupen64plus-ae/libs/extras/android/support/v7/appcompat/bin/mupen64plus-ae-appcompat.jar'   mupen64plus-ae      Build path   Build Path Problem
The project cannot be built until build path errors are resolved   mupen64plus-ae      Unknown   Java Problem


I tried to build via command line:

ndk-build - build with no errors

ant debug
BUILD FAILED
/home/sergey/WS/android-sdk-linux/tools/ant/build.xml:601: Invalid file: /home/sergey/WS/mupen64plus-ae/libs/extras/android/support/v7/gridlayout/build.xml

full ant log attached.

What do I wrong?


UPDATE: I switched to tag 2.4.4 and built debug version with no errors using command-line tools. I deployed the build to my phone, it works properly. That is enough for my current needs. My first task is to build my current code, emulator's version is not important for that.

UPDATE 2: Still can't build the project in Eclipse :( Error log attached.
Title: Re: GLideN64 Android port
Post by: Gonetz on April 19, 2015, 05:57:13 AM
One more question: I checked project file for Glide64 port. GlideHQ texture library is disabled. Why? Is it possible to build Boost for Android?
Title: Re: GLideN64 Android port
Post by: littleguy on April 19, 2015, 07:06:57 AM
Thanks Gonetz, I'll take a look.  Your issues with the tip of master are probably the same issues that are breaking Paul's build-bot.

Tag 2.4.4 is *very* out of date with upstream.  I would recommend you test your plugin against Alpha 19 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/99ce095) if you can't build the current head.  So much has been refactored in both the upstream code and the android front-end since 2.4.4.

(The alphas are discussed on this (http://www.paulscode.com/forum/index.php?topic=1818.0) thread in case you're curious.)
Title: Re: GLideN64 Android port
Post by: littleguy on April 19, 2015, 07:19:52 AM
Regarding Boost, no one wanted to hassle with it when Kris (Metricity) ported Glide to GLES, so we simply disabled GlideHQ temporarily.  But no one ever got around to dealing with it.  There's currently an upstream ticket to remove it as a dependency, which may be easier than adding Boost to mupen64plus-ae.
https://github.com/mupen64plus/mupen64plus-video-glide64mk2/issues/46
Title: Re: GLideN64 Android port
Post by: retroben on April 19, 2015, 03:22:36 PM
So that's why Mupen64Plus AE's Glide plugin is missing some good features.
Mainly no choice for HQ4x enhancement,texture packs,or other settings.
Then again,it has a few bugs like shadows clipping the ground (seen in Banjo-Tooie),missing vertex chunks (Banjo honey barns in both games),and slower performance due to porting issues with differences/limitations in GLES.
But I guess you should disregard these issues since this topic is for GlideN64.

Happy to see things aren't as bad as I once thought they would be with Paul missing from the forums.
Still hoping he will appear sooner or later.

Edit: My ultimate test for performance is running Banjo-Tooie with this "no frameskip" code enabled (8007913F 0001) for 60fps and countperop=1 for perfect smoothness at the expense of less headroom.
Rice normally runs the fastest in these conditions,please try this ultimate performance test to see how GlideN64 holds up on Android.
Title: Re: GLideN64 Android port
Post by: Gonetz on April 19, 2015, 11:54:06 PM
OK, I'll try to test the plugin against Alpha 19 when there will be something to test.
Currently it does not compiled yet.

Regarding Boost: I found this solution:

https://www.crystax.net/en/android/ndk

Looks like worth to try ndk. I Don't have time to rewrite texture library without Boost usage. If that NDK provides ready Boost libs it may solve the problem and we will get fully functional plugin on Android.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on April 20, 2015, 12:59:28 AM
Another option is to build our own boost library in order to keep compatibility with official ndk version:

https://github.com/MysticTreeGames/Boost-for-Android (https://github.com/MysticTreeGames/Boost-for-Android)

I will try to build it and report any issues I came across
Title: Re: GLideN64 Android port
Post by: Gillou68310 on April 20, 2015, 04:35:24 AM
@Gonetz concerning your issue with appcompat, make sure API 21 is installed via SDK manager before importing the project in eclipse. I had a similar issue on windows where eclipse used a lower (but not compatible) API version.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on April 20, 2015, 06:43:12 AM
Quote
I tried to build via command line:

ndk-build - build with no errors

ant debug
BUILD FAILED
/home/sergey/WS/android-sdk-linux/tools/ant/build.xml:601: Invalid file: /home/sergey/WS/mupen64plus-ae/libs/extras/android/support/v7/gridlayout/build.xml

full ant log attached.

What do I wrong?


@Gonetz you need to run "android update project" in both appcompat and gridlayout directories before you can run ant debug.

Code: [Select]
android update project --name appcompat --target 2 --path /home/gilles/workspace/mupen64plus-ae/libs/extras/android/support/v7/appcompat
android update project --name gridlayout --target 2 --path /home/gilles/workspace/mupen64plus-ae/libs/extras/android/support/v7/gridlayout

Target 2 beeing API 21 on my computer (android list target) 
Title: Re: GLideN64 Android port
Post by: littleguy on April 20, 2015, 06:55:22 AM
Thanks, that's helpful Gilles.  I'm going to take some time this morning to try to get to the bottom of all this.

@Gonetz I just wanted to mention a couple things:
 - Alpha 19 should be plenty sufficient for initial integration testing, and it doesn't contain any of the appcompat stuff that may be causing some of the build issues Gilles describes.
 - Alpha 19 should build just fine without modification.  Note that with mupen64plus-ae, everything you need to build is included in that single repository -- you don't need to pull any upstream repositories.  GlideHQ will be disabled, but the whole project will still build and run fine.  There's no need to add Boost just to start testing -- unless GlideN64 requires it.  (Does it?)
Title: Re: GLideN64 Android port
Post by: littleguy on April 20, 2015, 08:01:34 AM
BTW the tip of mupen64plus-ae master is now in sync with the latest from upstream.  I'll look into the linux build issues now.
Title: Re: GLideN64 Android port
Post by: Gonetz on April 20, 2015, 09:22:19 AM
@Gonetz concerning your issue with appcompat, make sure API 21 is installed via SDK manager before importing the project in eclipse. I had a similar issue on windows where eclipse used a lower (but not compatible) API version.

SDK manager has tons of options which look redundant for me. Could you check that my current setup is ok? Screenshot attached.
Title: Re: GLideN64 Android port
Post by: Gonetz on April 20, 2015, 09:30:11 AM
There's no need to add Boost just to start testing -- unless GlideN64 requires it.  (Does it?)

PC version of GlideN64 is linked with GLideNHQ (GL port of GlideHQ). GLideNHQ uses Boost system and filesystem.
I can cut that link for Android and I'll do it as the first step to Android compatibility. However, I'd like to bring to Android full power of PC version.
Title: Re: GLideN64 Android port
Post by: littleguy on April 20, 2015, 09:32:31 AM
@Gonetz
Looks like your installation should be fine to build the latest tip (which includes appcompat libraries) or Alpha 19 (which does not include appcompat and therefore is easier to build).

I agree that the full power should be in Android if at all possible.  I think disabling HQ for now just to get building is reasonable.  We always planned to get GlideHQ into Android, we just ran out of time/higher priorities/etc.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on April 20, 2015, 10:25:37 AM
I managed to build Glide64 with GlideHQ support, using this library:
https://github.com/MysticTreeGames/Boost-for-Android (https://github.com/MysticTreeGames/Boost-for-Android)

I didn't check if it's actually functionnal, but I'm not sure we can use it anyway as their is no support for armv7 or x86.
Title: Re: GLideN64 Android port
Post by: littleguy on April 20, 2015, 10:44:32 AM
@Gonetz
After cloning, did you create an initial project file, as described in mupen64plus-ae/README.md?

Quote

Download and install the prerequisites
    Android SDK
    Android NDK
    Eclipse ADT plugin
Clone the mupen64plus-ae repository and initialize the working copy
    git clone https://github.com/mupen64plus-ae/mupen64plus-ae.git
    cp .project.init .project
Import the Eclipse project and dependencies
    Open Eclipse
    Select File → Import → Android → Existing Android Code Into Workspace, and press Next
    Browse to root of cloned repository, and press OK
    Select all projects, and press Finish
Add native support to the Eclipse project
    Right-click the mupen64plus-ae project in the Eclipse Package Explorer window
    Select Android Tools → Add Native Support...
    Accept the default library name (mupen64plus-ae), and press Finish
    Delete the unneeded generated C++ file: rm jni/mupen64plus-ae.cpp
Build and run the app from Eclipse
    Select the mupen64plus-ae project in the Eclipse Package Explorer window
    Select Run → Run
Title: Re: GLideN64 Android port
Post by: littleguy on April 20, 2015, 10:58:34 AM
@Gonetz
I just verified that I could build the latest tip of master using Ubuntu 14.04 64-bit, using a fresh install of the SDK, NDK, ADT, and Eclipse Luna.  I followed the instructions in the README.md exactly without any deviations.

I did have to apt-get install a few things, which I found through a quick google search
    sudo apt-get install lib32z1 lib32stdc++6

In the Android SDK manager, I have only four things installed
    - Android SDK Tools 24.1.2
    - Android SDK Platform-tools 22
    - Android SDK Build-tools 21.1.2
    - Android 5.0.1 (API 21) -> SDK Platform

Note that I do NOT have the Android Support Library installed.  We mirrored the select elements from ASL into the mupen64plus-ae repository specifically to make it easy to build out of the box for build scripts, users, etc.

I would suggest you delete your git clone, remove unneeded components in the Android SDK Manager, and start fresh.  If you get any build errors, you might just need to apt-get install some dependencies.  Restart Eclipse and clean the build between updates.
Title: Re: GLideN64 Android port
Post by: retroben on April 20, 2015, 11:17:17 AM
Edit: @Gillou:Some release notes from the boost library website has mentions of armv7.

1.54.0

Code: [Select]
Chrono:
Fixed Bugs:
#8367 chrono does not compile with clang from XCode 4.5.2 with -std=c++11 -stdlib=libc++ and -arch armv7

1.56.0 (unrelated to current "for Android" build version limit)

Code: [Select]
Atomic:
Improved support for ARMv6 and later with GCC. Implemented all atomic operations as assembler blocks instead of CAS-based loops. 64-bit operations are supported with ARMv7.

I hope this helps out.

Edit: The Boost for Android github page lists versions including 1.54.0 so I'd assume armv7 is supported in 1.54.0 and 1.55.0 of the Android one.
Then again,what architecture does current Android run on...armv7 and x86.
(and x86-64bit when on Lollipop for supported devices)

...Wait,how could it or "Boost for Android" not be supported on either armv7 and x86?
Those are the main architectures. (especially x86 for computers in 32bit then 64bit form)


(another) Edit:There is one thing on that github page showing "armeabi" that now confuses me.

Just trying to help however I can.
Title: Re: GLideN64 Android port
Post by: Gonetz on April 20, 2015, 11:30:59 AM
Eclipse Luna...
I tried to use Version: 3.8.1 from Ubuntu Software Center.
Ok, I'll get fresh soft and try again.
Title: Re: GLideN64 Android port
Post by: littleguy on April 20, 2015, 11:38:27 AM
@Gonetz
I figured out the ant build issue and will push a fix in a little bit.  Just want to test it all again on a fresh checkout first.
Title: Re: GLideN64 Android port
Post by: Gonetz on April 20, 2015, 12:58:39 PM
@littleguy
Many thanks for the detailed instructions!
I did everything as you said and got working build with no problems.
Now I can switch to issues with my code.
Title: Re: GLideN64 Android port
Post by: littleguy on April 20, 2015, 01:17:47 PM
Excellent!  I'll probably have the fix for ant pushed up later if you prefer ant instead of eclipse.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on April 20, 2015, 01:31:47 PM
Thanks for your help @retroben but iI think I found what I was looking for:
https://github.com/sorccu/Boost-for-Android/commits/multiabi-refactor (https://github.com/sorccu/Boost-for-Android/commits/multiabi-refactor)

I'll test this tomorrow ;)
Title: Re: GLideN64 Android port
Post by: retroben on April 20, 2015, 01:43:01 PM
Yes  ;D,commit fa61986 adds support for armeabi-v7a. (the armv7 library)

Good luck everyone.  :)
Title: Re: GLideN64 Android port
Post by: littleguy 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
Title: Re: GLideN64 Android port
Post by: Gonetz 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!
Title: Re: GLideN64 Android port
Post by: Gillou68310 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 (https://github.com/mupen64plus-ae/mupen64plus-ae/tree/boost)

Instructions on how to use it are here:
https://github.com/MysticTreeGames/Boost-for-Android (https://github.com/MysticTreeGames/Boost-for-Android)
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: retroben 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
Title: Re: GLideN64 Android port
Post by: Gonetz 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 (https://github.com/mupen64plus-ae/mupen64plus-ae/tree/boost)

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

Thanks! I'll check it.
Title: Re: GLideN64 Android port
Post by: Gonetz 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.
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: Gonetz 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.
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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!
Title: Re: GLideN64 Android port
Post by: Gonetz on April 23, 2015, 11:48:38 PM
@retroben
I'm planning to move step by step from 3.1 downside to 2.0 Most of my Android devices are ES 2.0
I just need a starting point first - a working version, which I can test and debug. For my current code 3.1 is the shortest way to get working Android build.

@littleguy, thanks in advance! I'll wait for your results. So far I'll switch back to PC version issues.
Title: Re: GLideN64 Android port
Post by: littleguy on April 24, 2015, 07:04:03 AM
@Gonetz
I took a look last night and I don't foresee any issues getting your plugin into the Android app.  The patch you sent and the android makefile are both very helpful and should make it very easy for me to translate into the latest Alpha releases.  I can do all the legwork of modifying the UI, so you will only have to drop your source code into the jni directory and press build in Eclipse.

I will be out of town and mostly offline for the next three days, but I can certainly get this set up for you on Monday, if you don't mind waiting.
Title: Re: GLideN64 Android port
Post by: retroben on April 24, 2015, 09:48:06 AM
Okay,good. :)

@littleguy: Don't get crushed by an evil moon while you're gone.  :D
Title: Re: GLideN64 Android port
Post by: Gonetz on April 25, 2015, 01:32:05 AM
@littleguy - Monday is perfectly fine for me, thanks in advance! I'll use that time to fix some stuff in the code before PC release.

Regarding my old patch to emulator's UI: it was done for settings, which plugin used year ago. Current set of settings is a bit different, see Config.h in my code.

On the first step I'll need support for settings from sections "generalEmulation" and "frameBufferEmulation".
Sections "video" and "texture" are under question.
As I remember, screen size is loaded from general emulator's settings.  multisampling is for GLES31 devices and can be ignored for now. Anisotropy has no support in GLES. "bilinearMode" option is useful, but not must. "maxBytes" option defines how much of video memory plugin can take for textures. I think, that option should not be user-defined on Android. I believe that we can ask Android OS about available video memory and provide the plugin with that information. As a temporal solution I can just hardcode it for some reasonable value.
Title: Re: GLideN64 Android port
Post by: retroben on April 25, 2015, 02:01:34 AM
But multisampling is also featured in the Rice plugin and works on my device that's stuck on GLES2.
It makes many things look much crisper with almost no performance impact.
Edit: To add,I am on Jellybean 4.2.2 with this feature in Rice fully functional to 16.

One drawback of multisampling is the use of CountPerOp drastically increasing and increased strain to the 1500 VI Refresh Rate limit causing dropped fps when in certain parts/viewpoints of a game.
Title: Re: GLideN64 Android port
Post by: littleguy on April 27, 2015, 09:13:23 AM
@Gonetz
I started a branch for you to start integrating your plugin.  I left you a bunch of comments on GitHub, feel free to reply inline or here if you have any questions or comments.
https://github.com/mupen64plus-ae/mupen64plus-ae/commits/gliden64-integration

For now I have just included the bare minimum mods to allow you to build and test.  I will start exposing your config settings in the android front-end once you are able to build and run the branch.

I haven't actually confirmed the build process yet.  Looks like I will need to obtain the GLESv3 headers and binaries somewhere.  Perhaps the Tegra Android Development Pack?
Title: Re: GLideN64 Android port
Post by: xperia64 on April 27, 2015, 12:09:53 PM
android-18 has the gles3 headers. I assume the project target api level must be set to at least 18.
https://android.googlesource.com/platform/development/+/master/ndk/platforms/android-18/include/GLES3/gl3.h
Title: Re: GLideN64 Android port
Post by: Gillou68310 on April 27, 2015, 11:16:23 PM
@Gonetz could you re-upload your code please? I didn't get time to download it before the weekend :)
Title: Re: GLideN64 Android port
Post by: Gonetz on April 27, 2015, 11:54:56 PM
@littleguy - thanks a lot!
I'm currently overbusy with PC release preparation - need to polish some stuff before release for remaining few days.
I'll try to check your work in parallel and ask questions in case of troubles.

Latest Android NDK contains GL headers for GLES3.1

I accidentally removed sources of my preliminary Android port. Here the update link:
https://drive.google.com/file/d/0B0YqMPjGo3B2R19Oa05wbjA3YjA/view?usp=sharing
Title: Re: GLideN64 Android port
Post by: Gonetz on May 02, 2015, 12:46:20 PM
Sorry for delay.
Was very busy with plugin Public Release preparations.

I've fetched latest state, switched to gliden64-integration, copied my sources (correct accordingly to the littleguy's instructions) and built the project. Run, select GLideN64 as graphics plugin and start the demo rom. Result is expected:

05-02 23:37:57.738: I/UI-Console(17664): using Video plugin: 'GLideN64' v2.0.0
05-02 23:37:57.738: I/UI-Console(17664): using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v2.0.0
05-02 23:37:57.739: I/UI-Console(17664): using Input plugin: 'Mupen64Plus Android Input Plugin' v1.0.0
05-02 23:37:57.739: I/UI-Console(17664): using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.0.0
05-02 23:37:57.768: A/libc(17664): Fatal signal 11 (SIGSEGV), code 2, fault addr 0x7e88d61c in tid 17738 (CoreThread)

Is it possible to debug native c++ code using Eclipse (breakpoints, call stack etc) or Log is my only hope?
Title: Re: GLideN64 Android port
Post by: retroben on May 02, 2015, 01:49:25 PM
A quote of what hunterk said on libretro: "Twinaphex has been backporting a lot of gonetz's work into mupen64plus-libretro's gln64 plugin. It turns out it's not wildly different from gln64, so backporting makes more sense in this case than bringing over the plugin wholescale."

Can this same method be done on Mupen64Plus AE after merging over the original glN64 and cleaning it up?
Title: Re: GLideN64 Android port
Post by: littleguy on May 02, 2015, 04:13:11 PM
@Gonetz No worries, you have done so much already.

Unfortunately I don't have any easy advice about debugging the native code on Android.  I have looked into it in the past and realized there was no "easy button" as far as I could tell.  But there are tools out there like ndk-stack (see the tools directory of mupen64plus-ae) and the tegra android development pack, and I would think someone out there has taken the time to document a good solution.  Most of my personal involvement in the native debugging has been with regards to ae-bridge, mupen64plus-input-android, xperia-touchpad, and a bit of SDL2.  In those cases I gave up and just suffered through using debug statements.  If you find a particularly good link or tutorial, I'd love to know.

@retroben Not sure I understand what you're trying to say.  If you are suggesting that we somehow fork GLideN64, then that is not my interest at all.
Title: Re: GLideN64 Android port
Post by: retroben on May 02, 2015, 04:59:50 PM
What I meant was taking the main original gln64 (first platform or best version/main version GLideN64 was made on) and combining it with the AE version,then implant GLideN64 into that.

Sorry,might be a bad idea,but I don't know much about it on a technological standpoint,and it might end up being too much work. :(
Title: Re: GLideN64 Android port
Post by: Gillou68310 on May 03, 2015, 03:06:21 AM
@Gonetz you can send debug messages to the android log using this function in your code:

Code: [Select]
void DebugMessage(int level, const char *message, ...)
{
  char msgbuf[1024];
  va_list args;

  if (l_DebugCallback == NULL)
      return;

  va_start(args, message);
  vsprintf(msgbuf, message, args);

  (*l_DebugCallback)(l_DebugCallContext, level, msgbuf);

  va_end(args);
}

Pointers to DebugCallback and DebugCallContext are passed through PluginStartup:

Code: [Select]
EXPORT m64p_error CALL PluginStartup(m64p_dynlib_handle CoreLibHandle, void *Context,
                                   void (*DebugCallback)(void *, int, const char *))

You can see the logs directly in the logcat view in eclipse.
From my experience this is the easiest way to debug native code. Setting breakpoints is a nightmare and even if your breakpoint is hit, it's extremely slow.

I'm kind of used to debug native code on android, so if you need help with this don't hesitate to ask ;)

BTW, is your current work on android in sync with Public Release 1?
Title: Re: GLideN64 Android port
Post by: Gonetz on May 03, 2015, 05:55:17 AM
Thanks for advice. I'll check NVidia tegra tools.

My current Android port code is right above the master, from which Public Release was built.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 03, 2015, 12:41:07 PM
I've installed Tegra Android Development tool. The project successfully loaded, built and run.
I've got the same error on rom run and I decided to finally enable promised C++ debug.

First, I found this hint:
https://devtalk.nvidia.com/default/topic/527587/tegra-tools/tutorial-for-using-nvidia-debug-manager-in-tadp/
I set breakpoints and run Debug as >Android NDK application. Nothing.

I found that:
http://tools.android.com/recent/usingthendkplugin
The result was as if I debug release code: all breakpoints are ignored, but I got the name of function, which crashed.

I fond this one:
http://stackoverflow.com/questions/17705109/how-to-debug-c-c-code-ndk-in-eclipse
I edit jni/Andorid.mk to set -g in LOCAL_CFLAGS for gliden64
and jni/Application.mk to set APP_OPTIM := debug
Rebuilt the project. Does not help as well, breakpoints do not work.
GDB says:
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

Nevertheless I found the place where plugin crashed on start, fixed it  and finally got messages about shader compilation error.
Now I can work further. However, if somebody knows working recipe  how to make debugging work, please share.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 04, 2015, 03:24:07 AM
GLES3.1 compatible sources for gliden64-integration branch:
https://drive.google.com/file/d/0B0YqMPjGo3B2akh6NXlGZFVBM3c/view?usp=sharing

Works very slow atm, but seems to be fully functional. Very close to PC version capabilities.
Title: Re: GLideN64 Android port
Post by: littleguy on May 04, 2015, 07:20:11 AM
Awesome!!  I can't wait to give it a try once I have an Nvidia Shield (hopefully very soon! :) )

So, I was just curious what your long-term plans were for source code, contributions, etc.  Were you going to just publish tarballs periodically, or were you going to push the development history into https://github.com/gonetz/GLideN64 and start accepting pull requests?  If the latter, any guess as to when that might happen?  Mainly just curious, as I was thinking about the workflow we'll use for building it into mupen64plus-ae.

Thanks for the amazing progress!
Title: Re: GLideN64 Android port
Post by: Metalmusic3000 on May 04, 2015, 09:43:40 AM
Nvidia shield portable has been discontinued expect a refresh soon rumors are the new shield portable 2 is coming supposidly with the tegra x1 and 3gb ram and a larger screen i expect a announcement at E3 nvidia project code name is loki alot of into can be found in the nvidia shield forum search for loki
Title: Re: GLideN64 Android port
Post by: littleguy on May 04, 2015, 09:49:41 AM
I meant shield tablet, not shield portable.  But thanks for the info, sounds like another cool product :)
Title: Re: GLideN64 Android port
Post by: Gonetz on May 04, 2015, 12:12:34 PM
Awesome!!  I can't wait to give it a try once I have an Nvidia Shield (hopefully very soon! :) )

So, I was just curious what your long-term plans were for source code, contributions, etc.  Were you going to just publish tarballs periodically, or were you going to push the development history into https://github.com/gonetz/GLideN64 and start accepting pull requests?  If the latter, any guess as to when that might happen?  Mainly just curious, as I was thinking about the workflow we'll use for building it into mupen64plus-ae.

Thanks for the amazing progress!

Of course, I'll  push the whole development history. When? Soon. May be even earlier.
I planned to do that after the first results with Android port, so we may start to work with somehow working code.
However, I need to make some kind of bugfix release on PC first. There are few nasty issues, which must not be in release. After that I'll push the history.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 04, 2015, 12:35:49 PM
Here the GLES30 compatible code:

https://drive.google.com/file/d/0B0YqMPjGo3B2T1NkSzBfNDhHazA/view?usp=sharing

Thanks Gillou68310 for help with it.

I've corrected manifest and .mk files to switch to android-19 platform.
This build works fine on NVidia Shield tablet, but has heavy glitches on my Galaxy Note 3.
It looks a bit better with frame buffer emulation off, but textures still don't work.

You may notice that some textures works on Note 3. These are texrects. Texture coordinate for texrect vertices are pre-calculated. Texture coordinates for normal polygons calculated by vertex shader. It's a hint, where to search the problem. I suspect that Uniforms Block functionality does not work properly on Note3.
Since the plugin works more correct with frame buffer emulation off, I suppose that glBlitFramebuffer also works incorrect. If you have other GLES3 compatible devices, please check how it works for you.

What is bad, after switch to android-19 I can't debug it as Android Native application anymore.
gdb just can't see the app.

Also, frame buffer emulation works very SLOW even on NVidia tablet.
Title: Re: GLideN64 Android port
Post by: littleguy on May 04, 2015, 12:42:20 PM
When you mentioned glBlit I immediately thought of this post.  We've seen problems with Adreno drivers before...
https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/#horrible-qualcommadreno
Title: Re: GLideN64 Android port
Post by: retroben on May 04, 2015, 12:51:54 PM
Is there a build of it I can get and test?

Immediately,my FireTV becomes a piece of trash again because ancient Qualcomm V@15.0 drivers I am stuck on.
(Hurry up with the MOD TechVendetta of XDA!,please!)

My Acer Iconia x86 Intel tablet has ES 3.0 support along with the OpenGL 3.0 as well.
Crappy RAM though because only 1gig.
Curious if it would even run on an Intel at all.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 04, 2015, 01:19:23 PM
> Is there a build of it I can get and test?

I tried to build an apk with ant, but it fails. I'm not Android dev guru. Yet :)
Title: Re: GLideN64 Android port
Post by: Gonetz on May 04, 2015, 01:25:03 PM
When you mentioned glBlit I immediately thought of this post.  We've seen problems with Adreno drivers before...
https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/#horrible-qualcommadreno

It looks really horrible. I'm not ready to fight with such issues. Just hope that Adreno has better GLES2 support .
Title: Re: GLideN64 Android port
Post by: littleguy on May 04, 2015, 01:40:53 PM
> Is there a build of it I can get and test?

I tried to build an apk with ant, but it fails. I'm not Android dev guru. Yet :)

Would love to have another :)

Gonetz - I can create a build for testers whenever you like.  I will wait for your signal, in case you want to phase the rollout between PC and Android.  You have a lot on your plate and fielding bug reports on an initial release tends to be overwhelming.
Title: Re: GLideN64 Android port
Post by: xperia64 on May 04, 2015, 03:18:04 PM
I have a build at the ready. (GLES3.0)

It's pretty slow, but fairly accurate. The puzzle piece effect in Banjo-Kazooie works fine.
I know this is an early build, but just wanted to note that Animal Forest has issues with 2D elements being nonexistant. However, the pause menu is already better in my opinion as the player character is displayed properly and the read from framebuffer effect in the background works, as opposed to random colors being displayed.

And there's this unsettling issue in CBFD: http://imgur.com/XHoK4WA,g6haqiy

(Building this version in eclipse is a bit of a pain. I had to mess around with the jar files and library dependencies).
Title: Re: GLideN64 Android port
Post by: retroben on May 04, 2015, 04:33:25 PM
Could ya help a playa out? ;D
Would you either test Yoshi Story on Jungle Puddle or please help me obtain a build for testing it myself?
Title: Re: GLideN64 Android port
Post by: xperia64 on May 04, 2015, 05:10:34 PM
http://m.imgur.com/BXB9WbZ
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: Gonetz 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
Title: Re: GLideN64 Android port
Post by: littleguy on May 06, 2015, 07:28:14 AM
Ok, let me check into it and get back to you.
Title: Re: GLideN64 Android port
Post by: littleguy 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).
Title: Re: GLideN64 Android port
Post by: Gonetz 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
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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
Title: Re: GLideN64 Android port
Post by: Gonetz 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.

Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: gdark100 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).
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: gdark100 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.
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 07, 2015, 11:33:46 PM
It seems that everybody missed my main point:
disable EnableCopyColorToRDRAM and EnableCopyDepthToRDRAM options in config file and you will get fullspeed with GLideN64 in most games on most compatible devices right now.

Screen shot: Zelda MM running full speed on Shield with frame buffer emulation:
https://drive.google.com/file/d/0B0YqMPjGo3B2YlJFdE5hWS1vTHM/view?usp=sharing
Title: Re: GLideN64 Android port
Post by: retroben on May 07, 2015, 11:59:36 PM
Sorry about all of that. :(
I already knew you said how to fix the slowdown the first time. :)

Regardless,I can't test it on my x86 tablet without an apk since I am unskilled to compile it myself.
I really wanna give some test results with it.
Nobody mentioned how Super Smash Bros. ran with it yet.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 08, 2015, 12:14:34 AM
@retroben drop me a line to gonetz at ngs dot ru
I'll give you a link to apk.
Title: Re: GLideN64 Android port
Post by: retroben on May 08, 2015, 12:33:41 AM
Thank you.

Line has been dropped as instructed.
Title: Re: GLideN64 Android port
Post by: littleguy on May 08, 2015, 06:44:49 AM
@Gonetz I'll work on updating the UI to expose those settings.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 08, 2015, 08:54:47 AM
Great!
Title: Re: GLideN64 Android port
Post by: Gonetz on May 08, 2015, 11:55:06 AM
Thank you.

Line has been dropped as instructed.

Link to apk has been sent. Waiting for feedback :)
Title: Re: GLideN64 Android port
Post by: retroben on May 08, 2015, 01:15:10 PM
Got it.
Oh fiddlesticks! It sadly stays on black screen with no progression with sound. :(
This is on an Acer Iconia A1-840HD Intel x86 tablet.
I can successfully select the GLES 3.0 plugin on Dolphin emulator and boot Melee,albeit really slow from lack of x86 JIT recompiler,so my support for it is not bad at all.

Maybe someone with limits to 3.0 on an ARM architecture should try it and see if it runs to make sure its not an intel issue.
Normal Glide64 boots Super Mario 64 fine with that particular apk.
The same device can also run DK64 and Banjo-Tooie just fine,yet only on the v3 Alpha builds.
Maybe Gillou can help like he did when both those games started working on x86.
Title: Re: GLideN64 Android port
Post by: littleguy on May 08, 2015, 01:31:15 PM
No issues in SM64 on Shield Tablet (same as Gonetz is using).  Disabling the config settings mentioned above brings the framerate up to full speed.  It might even be faster than Glide64mk2 right now, but it's a bit hard to say since FPS are maxing out on the Shield.

FPS are actually about 3 times faster than the other plugins in the Star Wars Ep 1 Racer intro (45-60 FPS vs. 15) but that title seems to have some audio stutter issues that might be interfering with the other plugins' results.  Switching to audio-sles made no difference so maybe there's an issue with that title that goes deeper to the core.  So it might not be a proper comparison.  Still, amazing to see such performance!

Will be following the GLES 2.0 migration with great interest :)
Title: Re: GLideN64 Android port
Post by: retroben on May 08, 2015, 01:40:38 PM
Of course it runs fine on that ARM beast.  ;D *jealous*

I get no frames or startup at all on GLideN64. (x86 tablet)
I tried Super Smash Bros. the first time with the same black screen.
The game is not the problem,the architecture seems to be though,but I am not sure.

I too am veddy interested in GLES 2.0 and how it will perform. (hopefully better than all three others)
Glide64 is currently messed up anyway,corrupted texture placement and all.
Title: Re: GLideN64 Android port
Post by: Metalmusic3000 on May 08, 2015, 01:56:41 PM
I have been following gliden64 development since i guess late last july and have been waiting for the day to come and i just have to ask the question littleguy have you tried starwars rogue squadron are any lle games yet?how do they run on android? i really want to know lol
Title: Re: GLideN64 Android port
Post by: retroben on May 08, 2015, 04:43:07 PM
Found a possible cause of my issue.

Logcat after GLideN64 plugin name when opening Super Mario 64.

Requested context: GLES 2.0

Meaning it is not loading my ES 3.0 support.
Strange issue.

Also keep seeing "Searching package installed with ABI2 with Uid: 10130" on logcat.

Edit2:Hey Gonetz,do you think you can check the logcat on your Galaxy to see what context GLES version it says after booting a game?

It must be failing to detect the x86 edition of GLES 3.0 on my tablet.
Title: Re: GLideN64 Android port
Post by: retroben on May 08, 2015, 05:37:31 PM
Checked the "Device Info" part in PPSSPP,and it says...

Code: [Select]
Model_ Intel(R) HD Graphics for BayTrail

API Version_ OpenGL ES 3.0 - Build CL-26051

Shading Language_ OpenGL ES GLSL ES 3.0 - Build CL-260519-Cl-15.33-24169

I think this CL name difference could explain part of the problem.
Title: Re: GLideN64 Android port
Post by: littleguy on May 08, 2015, 08:29:24 PM
On ARM I get
Code: [Select]
05-08 21:27:55.573: I/GameLifecycleHandler(24206): onCreate
05-08 21:27:55.906: I/GameLifecycleHandler(24206): onStart
05-08 21:27:55.906: I/GameLifecycleHandler(24206): onResume
05-08 21:27:55.934: I/GameLifecycleHandler(24206): surfaceCreated
05-08 21:27:55.934: I/GameLifecycleHandler(24206): surfaceChanged
05-08 21:27:56.101: I/GameLifecycleHandler(24206): onWindowFocusChanged: true
05-08 21:27:56.101: I/ae-bridge(24206): Loading native libraries
05-08 21:27:56.105: W/linker(24206): libmupen64plus-core.so has text relocations. This is wasting memory and prevents security hardening. Please fix.
05-08 21:27:56.110: I/input-android(24206): init()
05-08 21:27:56.110: I/ae-bridge(24206): Android_JNI_InitImports()
05-08 21:27:56.110: I/SDL(24206): SDL_Android_Init()
05-08 21:27:56.110: I/SDL(24206): SDL_Android_Init() finished!
05-08 21:27:56.111: V/UI-Console(24206):  __  __                         __   _  _   ____  _             
05-08 21:27:56.111: V/UI-Console(24206): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___
05-08 21:27:56.111: V/UI-Console(24206): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __| 
05-08 21:27:56.111: V/UI-Console(24206): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \ 
05-08 21:27:56.111: V/UI-Console(24206): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/ 
05-08 21:27:56.111: V/UI-Console(24206):              |_|         http://code.google.com/p/mupen64plus/ 
05-08 21:27:56.111: V/UI-Console(24206): Mupen64Plus Console User-Interface Version 2.0.0
05-08 21:27:56.111: I/UI-Console(24206): attached to core library 'Mupen64Plus Core' version 2.0.0
05-08 21:27:56.111: I/UI-Console(24206):             Includes support for Dynamic Recompiler.
05-08 21:27:56.269: I/Core(24206): Goodname: Super Mario 64 (U) [!]
05-08 21:27:56.269: I/Core(24206): Name: SUPER MARIO 64     
05-08 21:27:56.269: I/Core(24206): MD5: 20B854B239203BAF6C961B850A4A51A2
05-08 21:27:56.269: I/Core(24206): CRC: 635A2BFF 8B022326
05-08 21:27:56.269: I/Core(24206): Imagetype: .z64 (native)
05-08 21:27:56.269: I/Core(24206): Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
05-08 21:27:56.269: I/Core(24206): Version: 1444
05-08 21:27:56.269: I/Core(24206): Manufacturer: Nintendo
05-08 21:27:56.269: I/Core(24206): Country: USA
05-08 21:27:56.273: D/UI-Console(24206): Cheat codes disabled.
05-08 21:27:56.275: I/UI-Console(24206): using Video plugin: 'GLideN64' v2.0.0
05-08 21:27:56.275: I/UI-Console(24206): using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v2.0.0
05-08 21:27:56.275: I/UI-Console(24206): using Input plugin: 'Mupen64Plus Android Input Plugin' v1.0.0
05-08 21:27:56.276: I/UI-Console(24206): using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.0.0
05-08 21:27:56.303: I/Core(24206): Setting video mode: 1600x1200
05-08 21:27:56.303: I/GameSurface(24206): Creating GL context
05-08 21:27:56.303: V/GameSurface(24206): Found EGL display connection
05-08 21:27:56.303: V/GameSurface(24206): Initialized EGL display connection
05-08 21:27:56.303: V/GameSurface(24206): Found compatible EGL frame buffer configuration
05-08 21:27:56.305: V/GameSurface(24206): Created EGL rendering context
05-08 21:27:56.307: V/GameSurface(24206): Created EGL window surface
05-08 21:27:56.337: V/GameSurface(24206): Bound EGL rendering context to EGL window surface
05-08 21:27:56.373: I/Audio(24206): Initializing SDL audio subsystem...
05-08 21:27:56.374: V/SDL(24206): SDL audio: opening device
05-08 21:27:56.405: I/Core(24206): Starting R4300 emulator: Dynamic Recompiler
05-08 21:27:56.415: I/Core(24206): Init new dynarec
05-08 21:27:56.425: I/Core(24206): ARM CPU Features: SWP, Half, Thumb, FastMult, VFP, ESDP, NEON, VFPv3, TLS, VFPv4, IDIVa, IDIVt
05-08 21:27:56.640: D/Core(24206): State loaded from: yyyy-mm-dd-hh-mm-ss.sav
05-08 21:27:56.676: W/art(24206): Native thread exiting without having called DetachCurrentThread (maybe it's going to use a pthread_key_create destructor?): Thread[26,tid=24790,Native,Thread*=0x77713100,peer=0x42973260,"Thread-10105"]
05-08 21:27:56.677: V/SDL(24206): SDL audio: opening device
05-08 21:27:59.900: I/GameLifecycleHandler(24206): onWindowFocusChanged: false
05-08 21:28:01.218: W/InputEventReceiver(24206): Attempted to finish an input event but the input event receiver has already been disposed.
05-08 21:28:01.218: I/GameLifecycleHandler(24206): onPause
05-08 21:28:01.218: D/Core(24206): Emulation paused.
05-08 21:28:01.543: I/GameLifecycleHandler(24206): surfaceDestroyed
05-08 21:28:01.543: D/Core(24206): Stopping emulation.
05-08 21:28:02.035: D/Core(24206): Saved state to: yyyy-mm-dd-hh-mm-ss.sav
05-08 21:28:02.051: I/Core(24206): R4300 emulator finished.
05-08 21:28:02.073: W/art(24206): Native thread exiting without having called DetachCurrentThread (maybe it's going to use a pthread_key_create destructor?): Thread[26,tid=24792,Native,Thread*=0x77713100,peer=0x429732c0,"Thread-10107"]
05-08 21:28:02.075: W/art(24206): Native thread exiting without having called DetachCurrentThread (maybe it's going to use a pthread_key_create destructor?): Thread[24,tid=24788,Native,Thread*=0x62f55100,peer=0x4273a140,"Thread-10103"]
05-08 21:28:02.093: I/GameSurface(24206): Destroying GL context
05-08 21:28:02.094: V/GameSurface(24206): Unbound EGL rendering context from EGL window surface
05-08 21:28:02.101: V/GameSurface(24206): Destroyed EGL window surface
05-08 21:28:02.103: V/GameSurface(24206): Destroyed EGL rendering context
05-08 21:28:02.103: V/GameSurface(24206): Terminated EGL display connection
05-08 21:28:02.103: E/libEGL(24206): call to OpenGL ES API with no current context (logged once per thread)
05-08 21:28:02.107: D/Core(24206): Rom closed.
05-08 21:28:02.110: I/ae-bridge(24206): Unloading native libraries
05-08 21:28:02.168: I/GameLifecycleHandler(24206): onStop
05-08 21:28:02.168: I/GameLifecycleHandler(24206): onDestroy
Title: Re: GLideN64 Android port
Post by: retroben on May 08, 2015, 09:40:28 PM
But yours is not the same copy Gonetz gave me since he had to make some changes to support GLES 3.0 version.
But I still wonder,why is yours not requesting a particular context?
*insert Conker's BFD context sensitive joke here*

Maybe the GLES handler on Android x86 is built differently.

Edit: I have Gems collection booting and running at -1 fps using OpenGL ES 3.0 version.
There is no proper x86 support,so it is really slow.
There's your proof for ES 3.0 support.
Title: Re: GLideN64 Android port
Post by: littleguy on May 09, 2015, 08:27:26 PM
@Gonetz

All 36 of the GLideN64 config settings are now exposed in the UI.  We can prune that later, but for now this should make it a bit easier to test different configs.  Right now the UI is bare-bones - in many cases you will be prompted for text.  Later when things settle down, we can change some of these to sliders, dropdowns, etc. so you won't need to worry about users entering bad values.  But I wanted to keep it simple for now and give you the most flexibility possible.

To change the config, you will need to create a new emulation profile.  This is accessible from the main navigation drawer, under the Profiles menu.  Once inside the emulation profiles management screen, create a new profile using the menu (or tap an existing profile and copy it).  Make as many profiles as you want, or just use a single one and keep editing it.  Keep in mind the profiles system was designed for the end user so they can "set and forget" settings per game and not have to constantly mess with them.  The downside is that it's a bit more tedious to the developer who wants to constantly change settings.  Sorry in advance if it drives you crazy...
Title: Re: GLideN64 Android port
Post by: retroben on May 09, 2015, 08:51:11 PM
Easy proof that I definitely have support for ES 3.0 is the fact that I can select the OpenGL ES frontend and boot it on the Dolphin Emulator for Android while FireTV had it unselectable...

Is there any way via an app to deeply check in-depth details of a device?
Possibly also stuff like supported SDL types/versions?

Or can I get a list for GLideN64 of required OGL and EGL extensions and other various bits of info so I can compare it to what I have?

I just really wanna break down all the details until hopefully,something makes more sense.
Title: Re: GLideN64 Android port
Post by: littleguy on May 09, 2015, 09:35:33 PM
I can verify that SDL is only requesting a GLES 2.0 context.  I'm not sure if SDL is somehow limiting the request, or if a 3.x context is not being requested in the first place by the plugin or the core.  In any case, the strange part is that the Shield is honoring the GLES 3.x commands with only a 2.0 context.  It sounds like your x86 may be doing exactly what it's supposed to.

I've got plenty on my plate between the UI and branch maintenance, and Gonetz said his source would be out soon enough, so I probably won't look into this right away.  I'm sure this will all be resolved soon enough if you can bear with the process.
Title: Re: GLideN64 Android port
Post by: xperia64 on May 09, 2015, 10:45:13 PM
My LG G3 also appears to accept the GLES3.0 commands.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 12, 2015, 11:55:20 PM
I pushed all my work to the current master on GitHub.

Time to switch to GLES2 port-support.
Title: Re: GLideN64 Android port
Post by: retroben on May 13, 2015, 12:03:22 AM
Still such a shame my x86 tablet's ES3.0 is too fussy to work with GLideN64.

I agree. Making GLES 2.0 work should be top priority.

(I wonder if anyone will ever think of taking the source code and making a mod of GLideN64 for Windows to enable OpenGL 2.0 support?)
Title: Re: GLideN64 Android port
Post by: Gonetz on May 13, 2015, 12:19:50 AM
(I wonder if anyone will ever think of taking the source code and making a mod of GLideN64 for Windows to enable OpenGL 2.0 support?)
It is meaningless. Better use old good Glide64.
Title: Re: GLideN64 Android port
Post by: retroben on May 13, 2015, 12:48:32 AM
But Banjo-Tooie lags on my toaster with Glide64. :( ... ;D

Well if Glide64 is open source,someone could splice some stuff together to add some of the accuracy,increase the performance and fix identical bugs.
Just fixing that buffer overhead issue in Glide64 (fixed in GLideN64) would do wonders.

Has anyone tried Conker's Bad Fur Day with the final boss on GLideN64?
There is a known issue with all other plugins that causes the game to run immensely slow during the safe and the final boss.

Edit: First of all,it is primarily a D3D setting and not applicable to Android,but Direct3D Clear Mode set to "only by frame" makes the final boss in Conker run really smooth at the cost of fading transitions and a few other effects.

What would the equivalent OpenGL/GLES function be called?
Would it be OpenGL Clear Mode possibly?
Title: Re: GLideN64 Android port
Post by: Gonetz on May 13, 2015, 06:03:51 AM
To developers: I installed Tegra Android Development Pack:
https://developer.nvidia.com/tegra-android-development-pack
It contains all necessary tools to develop Android apps on Windows.
It includes Nsight Tegra, Visual Studio Edition.
I imported mupen64plus-ae into Visual Studio, build and run it on my Shield with no problems. I even was able to set breakpoint, stop on it and inspect available variables. However, breakpoints do not work everywhere in the code and actual debugging hardly possible - step into a function freezes debugger.
Anyway, it is step forward in compare with what I had with Eclipse.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 14, 2015, 09:50:04 AM
Sorry for stupid question,  but how to get to graphics plugin options via GUI? I can select emulation profile, but can't see where it's settings.

I made my code compilable with GLES2, but it shows nothing yet.
Title: Re: GLideN64 Android port
Post by: retroben on May 14, 2015, 12:07:25 PM
You'll have to make a custom profile.

First go to select a profile and just touch manage on the bottom of the list and then the plus symbol to make a new one.
Now you touch the new profile,edit,then the plugin part to choose from the list,and it should load the settings below.

If not,then maybe somethng went wrong. :-\
Title: Re: GLideN64 Android port
Post by: littleguy on May 14, 2015, 12:20:46 PM
To change the config, you will need to create a new emulation profile.  This is accessible from the main navigation drawer, under the Profiles menu.  Once inside the emulation profiles management screen, create a new profile using the menu (or tap an existing profile and copy it).  Make as many profiles as you want, or just use a single one and keep editing it.  Keep in mind the profiles system was designed for the end user so they can "set and forget" settings per game and not have to constantly mess with them.  The downside is that it's a bit more tedious to the developer who wants to constantly change settings.  Sorry in advance if it drives you crazy...
Title: Re: GLideN64 Android port
Post by: Gonetz on May 15, 2015, 08:34:30 AM
Got it, thanks!

GLES2 version works well with fb emulation off.
Otherwise I have incomplete attachment. I fought with that problem before, so I think it is temporal.
Title: Re: GLideN64 Android port
Post by: retroben on May 15, 2015, 09:05:18 AM
Glad to see you already got it booting! ;D

Can hardly wait to try it whenever you're ready to let us testers and end-users or whenever it is auto-built. 8)
Edit2: I also feel nerdy enough to want access to all 36 options so I can make both a clean profile and a testing profile to expirement with various controls.

Edit: PLEASE tell me you left in multisampling and 5xBRZ shading support on the GLES2.0 version?
Even if it causes major slowdown,I wouldn't care myself,though I expect bloom to destroy framerates.
My guess is the the boost library might run on a seperate thread and maybe also a different core so it minimizes overhead of emulation performance like post-process shading,for example what Dolphin emulator does.

I can enable a postprocessing shader in Dolphin emulator on my single-cored toaster PC,and it surprisingly has NO performance hits whatsoever.
How did they manage to do that?
Title: Re: GLideN64 Android port
Post by: Gonetz on May 15, 2015, 09:48:47 AM
Texture library is not supported yet. I need to learn, how to attach boost for Android to my project.
MSAA is available only for GLES3.1. I tried to enable it on my Shield, but it does not work.
Post-processing shader based AA is possible, but I hardly will have time for it. GLES2 is very limited and I have to rewrite lot of things to make plugin's features available for that platform.

BTW, basic frame buffer emulation is started to breath. I can run Super Mario 64 with it.
Title: Re: GLideN64 Android port
Post by: retroben on May 15, 2015, 11:52:02 AM
So the GLES 2.0 porting is barely functional at the moment? (yes)

Good luck on getting it to run at full power. :)

But how does Rice work with multisampling on GLES 2.0 though?
Is it using a different method,and can it somehow be ported over from Rice?
Or is your code for that feature not fixed up yet since you've only initially got ES 2.0 running?

Sorry for all of these questions. :( I just can't get over the fact that Rice does multisampling on ES2. :P

Though somebody removed the option on later builds...why? ???
I KNOW it works with my early testing of Rice's multisampling on Banjo-Tooie since it looked much sharper and lighting quality was more intense. :-\
Title: Re: GLideN64 Android port
Post by: littleguy on May 15, 2015, 08:07:23 PM
@Paul I mirrored GLideN64 into the mupen64plus-ae repository and we are getting our first auto-builds of the gliden64-integration branch.  Unfortunately it looks like the native stuff isn't getting compiled.  Would you mind checking the build logs on your server?  Perhaps you might need to install additional Android SDK levels?

@Gonetz Right now the gliden64-integration branch contains the source from your Public_Release_1.1 tag.  I wanted to get the autobuilds working first.  Once that's ironed out, all you need to do to pull in your latest revision is pull up a shell and type

Code: [Select]
cd tools
pull-gliden64.sh

Tap enter a few times to accept the defaults and the head revision of GLideN64 will be mirrored into mupen64plus-ae (along with an updated Revision.h).  The commit message will contain a summary of all commits since the last sync.  For example, the message from my latest sync summarizes all the commits between Public_Release_1 and Public_Release_1.1.
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/7413012
Title: Re: GLideN64 Android port
Post by: Gonetz on May 16, 2015, 09:58:27 AM
Yesterday I managed to run GLES2 build of my plugin on NVidia Shield tablet. I rewrote large part of code to get that result. Today I had been porting my work on true GLES2 device and found that my yesterday struggle was just a warm-up before the real battle. I forgot how limited GLES2 is. Lots of things which I considered as basic just do not present here. I feel myself as returning back to stone age. I rewrote all " switch case" with "if else". I replaced "texture" with "texture2D". And so on. Lots of plugin's functionality is disabled because I don't know how to implement it with GLES2 functionality. For example, my mip-mapping code requires textureLod function, which is not supported here. My code is all perforated by "#ifdef #endif" because GLES2 can't do this and requires special code for that. It looks ugly.

Nevertheless, I finally got it working on my Note 2. The work is not finished and I will not push it to repo yet. However, I built an apk with current code. You may try it on your device. I was afraid that GLES2 will run slow, but speed is ok despite of plenty of debug output. Download link:
https://drive.google.com/file/d/0B0YqMPjGo3B2WmZON0ZkdXRNZWs/view?usp=sharing
Title: Re: GLideN64 Android port
Post by: Paul on May 16, 2015, 11:29:36 AM
@Paul I mirrored GLideN64 into the mupen64plus-ae repository and we are getting our first auto-builds of the gliden64-integration branch.  Unfortunately it looks like the native stuff isn't getting compiled.  Would you mind checking the build logs on your server?  Perhaps you might need to install additional Android SDK levels?

The ndk-build is failing with the following output:

Code: [Select]
jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'CachedTexture* TextureCache::_addTexture(u32)':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:539:13: error: 'TextureCache::Textures' has no member named 'emplace'
jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'CachedTexture* TextureCache::addFrameBufferTexture()':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:559:15: error: 'TextureCache::Textures' has no member named 'emplace'
jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'void TextureCache::update(u32)':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:1277:10: error: 'std::this_thread' has not been declared
jni/./mupen64plus-video-gliden64/src/Textures.cpp:1281:10: error: 'std::this_thread' has not been declared
make: *** [obj/local/armeabi-v7a/objs/mupen64plus-video-gliden64/./mupen64plus-video-gliden64/src/Textures.o] Error 1
make: *** Waiting for unfinished jobs....

I'll grab the latest ndk version and see if that makes a difference.
Title: Re: GLideN64 Android port
Post by: retroben on May 16, 2015, 12:03:48 PM
Here is a page about multisampling for Rice in mupen64plus and details of how to implement it.

https://code.google.com/p/mupen64plus/issues/detail?id=338

Maybe this can be done in the same exact way for GLideN64 ES2 but with the Android equivalent,wherever that is.
Hopefully whomever ported Rice as GLES2 to AE or that feature alone could speak up and tell us what instructions were used to implement multisampling.

Figured i'd at least try to help get this feature available one way or another. ;D
Title: Re: GLideN64 Android port
Post by: gdark100 on May 16, 2015, 12:03:57 PM
Yesterday I managed to run GLES2 build of my plugin on NVidia Shield tablet. I rewrote large part of code to get that result. Today I had been porting my work on true GLES2 device and found that my yesterday struggle was just a warm-up before the real battle. I forgot how limited GLES2 is. Lots of things which I considered as basic just do not present here. I feel myself as returning back to stone age. I rewrote all " switch case" with "if else". I replaced "texture" with "texture2D". And so on. Lots of plugin's functionality is disabled because I don't know how to implement it with GLES2 functionality. For example, my mip-mapping code requires textureLod function, which is not supported here. My code is all perforated by "#ifdef #endif" because GLES2 can't do this and requires special code for that. It looks ugly.

Nevertheless, I finally got it working on my Note 2. The work is not finished and I will not push it to repo yet. However, I built an apk with current code. You may try it on your device. I was afraid that GLES2 will run slow, but speed is ok despite of plenty of debug output. Download link:
https://drive.google.com/file/d/0B0YqMPjGo3B2WmZON0ZkdXRNZWs/view?usp=sharing
Tested it here, heavy graphical glitches and poor speed, but it is probably expected since youre rewriting lots of code...

Here are  some screenshots:
First this appeared:
(http://i.imgur.com/TL0dJeh.png)
then:
(http://i.imgur.com/wCJkAL0.png)
This is Super Mario 64. Only a few polygons actually appears on the screen, the rest is black.
I will test other games and let you know how they perform.

Also, good luck with your indiegogo campaign  ;D
Title: Re: GLideN64 Android port
Post by: retroben on May 16, 2015, 12:31:36 PM
I tried a few games on my FireTV.

Banjo-Tooie ran like the once broken part of Glide64 AE with atari style graphics,but with bumps.
After selecting a file and skipping the cutscene,it hits a grey screen and exits the game briefly.
Currently performance is a bit slow,but with good reason. I used fast forward and it only gave me 23fps out of 20.

Super Smash Bros. intro is the first messed up looking part,menus look fine,but it exits with the same grey screen when entering VS. Mode and possibly other modes.

I hope you are not using glblitFrameBuffer since Qualcomm hates that feature.
At least it is running,so that's a plus. ;D

DK64 is the first one that was playable in-game for me.
No crashing at all,the same atari-esque graphics,but text and 2D objects are invisible.
A unique issue is that the resolution changes when in certain spots and there is the same model stretching as Glide64 when near Cranky's Lab.
I got all the way to Jungle Japes,and I have to say the actual framerate is really smooth.
I neglected to remember the debug stuff is the slowdown.
Title: Re: GLideN64 Android port
Post by: xperia64 on May 16, 2015, 12:40:36 PM
@Paul I mirrored GLideN64 into the mupen64plus-ae repository and we are getting our first auto-builds of the gliden64-integration branch.  Unfortunately it looks like the native stuff isn't getting compiled.  Would you mind checking the build logs on your server?  Perhaps you might need to install additional Android SDK levels?

The ndk-build is failing with the following output:

Code: [Select]
jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'CachedTexture* TextureCache::_addTexture(u32)':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:539:13: error: 'TextureCache::Textures' has no member named 'emplace'
jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'CachedTexture* TextureCache::addFrameBufferTexture()':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:559:15: error: 'TextureCache::Textures' has no member named 'emplace'
jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'void TextureCache::update(u32)':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:1277:10: error: 'std::this_thread' has not been declared
jni/./mupen64plus-video-gliden64/src/Textures.cpp:1281:10: error: 'std::this_thread' has not been declared
make: *** [obj/local/armeabi-v7a/objs/mupen64plus-video-gliden64/./mupen64plus-video-gliden64/src/Textures.o] Error 1
make: *** Waiting for unfinished jobs....

I'll grab the latest ndk version and see if that makes a difference.
You either need the latest ndk version or force GCC 4.8 or higher. I'm still on ndk r9d and forcing gcc 4.8 got it to build after experiencing that error.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 16, 2015, 12:57:33 PM
@gdark100 - from which of your devices these screenshots? As I know, my Note 2 is powered by Mali400, and I have almost no glitches or speed issues. Some games crashes, but those which work run pretty well.

@retroben GLES2 does not support glblitFrameBuffer.
Title: Re: GLideN64 Android port
Post by: gdark100 on May 16, 2015, 01:01:14 PM
@gdark100 - from which of your devices these screenshots? As I know, my Note 2 is powered by Mali400, and I have almost no glitches or speed issues. Some games crashes, but those which work run pretty well.

@retroben GLES2 does not support glblitFrameBuffer.
Galaxy S2 Lite (Samsung Janice).
Ill test on the Xoom

Edit: On the Xoom it doesnt show anything. I can only hear the sound.
Title: Re: GLideN64 Android port
Post by: retroben on May 16, 2015, 01:12:00 PM
Never mind about DK64 being crashless,Chunky's crotch made it crash,it was hilarious!
He actually "crashes" into the screen on the DK Rap I skipped last time.

The Tiny Kong scene "changes her size to suit her mood" has stretchy glitching like Glide64.
Maybe these have always been core/RSP issues.

Another general issue is that fading transitions are missing,then again buffering is not functional currently.

Also,Conker's Bad Fur Day hits a grey screen exit on boot.

Edit: I decided to try custom settings,and a few things I noticed...
I made the Nintendo logo appear on DK64 (glitchy booting frame before) after enabling one of the options. (sorry can't remember)
I find that FBEmulation disabled makes it much faster,as one would expect.
Turning on the RDRAM settings must not work on GLES2,but HW Lighting worked with spooky looking kongs.
I can't tell if MultiSampling works yet since textures don't load.
Title: Re: GLideN64 Android port
Post by: littleguy on May 16, 2015, 01:46:55 PM
You either need the latest ndk version or force GCC 4.8 or higher. I'm still on ndk r9d and forcing gcc 4.8 got it to build after experiencing that error.

I'm running ndk-10d and everything builds fine.  I would suggest just staying current with the ndk.
Title: Re: GLideN64 Android port
Post by: retroben on May 16, 2015, 01:52:31 PM
Strange.

When gdark100 tested Super Mario 64,he got blackness and black spots on eyes and mouth.

On the normal GlideN64 profile:
First,I get the logo and then Mario's head with the obvious atari texture issue.
I get a full world of atari textures and a blank faced Mario with skin colors intact,but without eye textures or much others.
The text is garbled and unreadable,but the stat counters are visible with solid backgrounds instead of alpha ones.
The Mario icon is perfect looking.

And this is on Qualcomm Snapdragon 600 with Adreno 320 and V@15.0 drivers.
Am I lucky?

Sorry about the complete lack of screenshots. :(

Edit: Zelda Ocarina starts and reaches Link on Epona at the right edge of the screen before hitting the grey screen exit.
Title: Re: GLideN64 Android port
Post by: retroben on May 16, 2015, 02:57:49 PM
It is pointless to test anything further until you can fix texture and buffer issues and the grey screen exiting. :)

Any chance you are using TMEM?
One time,I enabled that setting on Rice and all of the visuals were broken with extremely similar atari graphics as a result.

Edit: Who ported Glide64 to Android?
What stuff was used to make it work as decent as it does aside from missing polygons?
Somebody knowledgable needs to help out Gonetz if they can please.
Title: Re: GLideN64 Android port
Post by: gdark100 on May 16, 2015, 09:23:25 PM
Well, just a note to gonetz. The problem is not the polygon themselves, but the textures. All textures are black. So only the polygons with colors (not textures) are visible.
Title: Re: GLideN64 Android port
Post by: retroben on May 16, 2015, 10:37:35 PM
Yet you get pretty different and worse results than I do.
But why is it so freakishly different?

If I go in 1st person on Banjo-Kazooie,there's actually tiny bits of textures on walls,but things like eyes in
Banjo-Kazooie and DK64 are solid white.
I forgot to mention that DK64 sometimes went black on areas during the intro sequence.

Let's just hope Gonetz can sort this out soon so we can get into further testing for graphical effects.
Having something that runs is the best thing to ever happen for him so he can more easily debug the problems and test changes quickly.

After all of this,it should hopefully outperform glN64 and Rice while looking better than Glide64.
(mainly no missing polygons)
So far,I didn't see any missing polygons on the honey farms in Banjo-Kazooie,so that's a good sign.
Just wished Smash Bros. went in-game even though textures are completely disjointed and the intro is broken.

I guess even in its fractured state,GLideN64 ES2 already runs pretty darn fast,especially with FBEmulation disabled.

...Why has no one ever devised an ingenius method of automatic effects usage?
To explain,turning on an intense effect at a precise time for the game and disabling it when it is no longer needed.
Even if the visual effect appearances are delayed,it could still be useful for preventing real unfriendly game behaviour when effect rendering is always disabled.
An example such as looking at an object with cool visual effects,not looking at it turns the effect renderer off while looking at it again briefly shows it missing the effect until it automatically turns back on.
This would probably require too much processing though,way more than its worth.
Just an idea,please don't get mad at me for it.

Sorry about the wall of text,my biggest habit sometimes.

Edit: The Super Smash Bros. intro is actually not broken,I thought it was because of the black square.

Performance is low but the framerate smoothness is pure buttery smooth compared to other plugins.
Just look at the frame-by-frame perfection on the intro!
Title: Re: GLideN64 Android port
Post by: gdark100 on May 17, 2015, 12:38:52 PM
I tried to record a video showing some games, but it didnt ended very well, cause I recorded with one hand and played with the other... but well, here it is: https://youtu.be/rGE_endTjcI (https://youtu.be/rGE_endTjcI)
Title: Re: GLideN64 Android port
Post by: Gonetz on May 18, 2015, 03:43:39 AM
Tested it here, heavy graphical glitches and poor speed, but it is probably expected since youre rewriting lots of code...

Here are  some screenshots:
First this appeared:
(http://i.imgur.com/TL0dJeh.png)
then:
(http://i.imgur.com/wCJkAL0.png)
This is Super Mario 64. Only a few polygons actually appears on the screen, the rest is black.
I will test other games and let you know how they perform.

Also, good luck with your indiegogo campaign  ;D

I got that image on PowerVR SGX device. Fragment shaders won't compile. No diagnostics, just "Compile failed".
Title: Re: GLideN64 Android port
Post by: littleguy on May 18, 2015, 07:50:30 AM
@Gonetz
I have seen this sort of device-dependent variation before with shaders.  One solution that has worked on several occasions is to make sure that all shader code explicitly specifies lowp/mediump/highp on the appropriate variable declarations.

http://www.paulscode.com/forum/index.php?topic=188.msg5220#msg5220
Title: Re: GLideN64 Android port
Post by: Gonetz on May 18, 2015, 10:04:08 AM
I know that all variable must have precision qualifier.

The problem is with device driver. This code works:
Code: [Select]

  fragColor = vec4(mix(fragColor.rgb, uFogColor.rgb, vFogFragCoord), fragColor.a);
  gl_FragColor = fragColor;
This code does not work:
Code: [Select]
 
  if (uFogUsage == 257)
    fragColor = vec4(mix(fragColor.rgb, uFogColor.rgb, vFogFragCoord), fragColor.a);
  gl_FragColor = fragColor;

I can't find a workaround. I tried to calculate mix() before "if ()" an store the result in a local variable:
Code: [Select]
 
  lowp vec3 fogged = mix(fragColor.rgb, uFogColor.rgb, vFogFragCoord);
  if (uFogUsage == 257)
    fragColor.rgb = fogged;
  gl_FragColor = fragColor;
It works without "if ()". With  "if ()" alwais "Compile failed".
Title: Re: GLideN64 Android port
Post by: Gonetz on May 18, 2015, 12:12:23 PM
Just tried to run GLideN64 on Samsung Galaxy 2. Not sure which GPU it uses. No errors in logs. Textures do not load at all.
Title: Re: GLideN64 Android port
Post by: retroben on May 18, 2015, 01:26:40 PM
There is an Android version of CPU-Z on Google Play that tells you what CPU and GPU you have along with some other information.

https://play.google.com/store/apps/details?id=com.cpuid.cpu_z

I hope it works on that device for showing you the information.

Edit: There is a slight chance you will see the wrong battery strength or other sensors reading off,but maybe you will see the right information you need.

If you don't want to use that one,there are others to try,but some have fullscreen ads.
Title: Re: GLideN64 Android port
Post by: gdark100 on May 18, 2015, 01:52:27 PM
Just tried to run GLideN64 on Samsung Galaxy 2. Not sure which GPU it uses. No errors in logs. Textures do not load at all.
Cant you port the functions that deal with textures from gln64 for GLES2 to your plugin until you "fix" the problem? So Ill know what is wrong and will have a possible solution.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 18, 2015, 01:56:05 PM
Cant you port the functions that deal with textures from gln64 for GLES2 to your plugin until you "fix" the problem? So Ill know what is wrong and will have a possible solution.

I don't know what to "port". Driver reports no errors.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 18, 2015, 02:00:51 PM
Here the PowerVR SGX 540 compatible build:
https://drive.google.com/file/d/0B0YqMPjGo3B2YUZ5dzk3RmdHWHc/view?usp=sharing

I had to disable fog blend modes to make shader program compiled for this GPU.
Works very slow with and without FB emulation.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 18, 2015, 02:32:57 PM
I've tested GLES2 build on my Note3. Works much better than GLES3 version.  No speed or graphics issues.

So, current result for GLES2:
Shield (Tegra) - OK
Note 2 (Mali400MP) - OK
Note 3 (Adreno 330)- OK
Nook HD+ (PowerVR SGX 544) - Graphics OK, slow
Galaxy 2 (Mali400MP) - no textures, speed ok.

Since Note 2 and Galaxy 2 use the same GPU (as reported by cpu-z), I think the problem is in drivers version.
Title: Re: GLideN64 Android port
Post by: gdark100 on May 18, 2015, 04:01:25 PM
Here the PowerVR SGX 540 compatible build:
https://drive.google.com/file/d/0B0YqMPjGo3B2YUZ5dzk3RmdHWHc/view?usp=sharing

I had to disable fog blend modes to make shader program compiled for this GPU.
Works very slow with and without FB emulation.
No changes on Mali400 MP device, and it is now working on PVR SGX 540 at slideshow speed. Recorded a video because whynot: https://youtu.be/NSpWc1PzuMM (https://youtu.be/NSpWc1PzuMM) (swtiched to gln64 at middle-to-end for speed comparasion)
Didnt see any major graphical issue on SGX 540 tho.
Title: Re: GLideN64 Android port
Post by: IDSG on May 18, 2015, 07:43:32 PM
Tested the GlideN64 plugin on my Ainol Aurora 2 (Mali400MP2 GPU) and doesnt show anything and is really slow, can be a driver Issue like you said (Mali drivers are a pain in the a$$ as far i know), PPSSPP team worked very hard to make it work correctly, i can help you test the plugin on this kind of gpu, keep up the good work
Title: Re: GLideN64 Android port
Post by: retroben on May 18, 2015, 11:32:57 PM
Here the PowerVR SGX 540 compatible build:
https://drive.google.com/file/d/0B0YqMPjGo3B2YUZ5dzk3RmdHWHc/view?usp=sharing

I had to disable fog blend modes to make shader program compiled for this GPU.
Works very slow with and without FB emulation.

I just grabbed this and tested it on my FireTV just cuz,and the textures are fully intact!!!
The framebuffer is a hit and a miss with see-through spots and square shadow on Banjo-Tooie
The speed is a little slow instead of slideshow speeds since I get 15-20fps out of 20 on Tooie.

Edit: I had it switched back to the pre-made experimental profile,so FBEmulation is enabled and no crashing!
Another thing,it boots with some tiedye stripes instead of a blank screen before the game starts.
The CloudCuckooLand bubble actually works already with Banjo appearing within when using a Clockwork egg to walk in the right spot.
I'm going to keep testing things. ;D

Strange how my issue is mostly fixed when that was for PowerVR.

Edit2: DK64 has toasted edges between beach and grass,and the textures go black when in some spots.

Yoshi's Story still grey screen exits :(,but the Nintendo logo looks perfect.
Conker,Zelda Ocarina,and Super Smash Bros. grey screen exit in the same spots.
Conker has a regression for me with a black screen instead of the text appearing.
Zelda has textures but a bad spot in the skybox while Super Smash Bros. has a few stretchy textures with most of them looking okay.

Some frame buffer effects are missing or glitched and some others seem fully intact.

Super Mario 64 looks nearly perfect so far aside from shadows and some objects being visible through walls.
Has an issue with the top left corner screen skybox looking wrong and the Mario head fade-out was squished before fixing itself.

Paper Mario looks great aside from black spots when making a save file.
It does exit during the title intro when Bowser is about to steal the Star Rod,but it can be skipped,and again when the battle is supposed to start after everyone become the wrong size. Mario and Peach shrink into high spots during the dark scene.
Bowser is stretched creepily at nightmare fuel proportions when arriving.
The white speech bubble is missing a chink on the left.

I think this is a general issue of things on the top left of the screen not rendering properly in several games.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 19, 2015, 07:10:11 AM
@littleguy - since GLideN64 capabilities greatly depend on GLES level, I suggest to include three version of the plugin:
GLES2, GLES3 and GLES3.1

GLES3.1 version is almost fully corresponds to PC version. MSAA does not work yet, but GLES3.1 supports it, so I think it can be fixed.

GLES3 version lacks of image texture support, so it does not support N64 depth compare and depth based fog in Beetle Adventure Racing. Everything else is supported.

GLES2 version lacks of everything. Frame buffer emulation is limited, mip-mapping is not supported.

Because of it, each version should have different set of options. for example, N64 depth compare is useless for all versions but GLES31

All GLES versions have different set of API finctions defined in headers. Thus, it is impossible to build one plugin and switch between GLES versions in runtime.

Currently my shaders related code is all perforated by <#ifdef #endif> Frame buffer emulation code also suffered from GL API incompatibility. I want to split common GL code into set of files by API level. I did such trick for Mupen64Plus/Zilmar code. Project file defines which source files to include.

In your project you will have three folders for GLideN64 instead of the current one:
mupen64plus-video-gliden64-gles20
mupen64plus-video-gliden64-gles30
mupen64plus-video-gliden64-gles31

Each version will have different project settings in Android.mk

What do you think?
Title: Re: GLideN64 Android port
Post by: littleguy 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...
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: gdark100 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)
Title: Re: GLideN64 Android port
Post by: littleguy 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)

Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: DonzBegonz 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!
Title: Re: GLideN64 Android port
Post by: Gonetz 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.

Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: Gonetz 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.
Title: Re: GLideN64 Android port
Post by: retroben 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? :'(
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: Gonetz 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: Gonetz 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 ?)
Title: Re: GLideN64 Android port
Post by: Gonetz 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.
Title: Re: GLideN64 Android port
Post by: littleguy on May 21, 2015, 10:32:37 AM
@Gonetz

Some good news.  If we build against APP_PLATFORM 18, the native code runs on older devices (at least the ones in my signature).  The caveat is that we can only include the GLES 2.0 and 3.0 variants of GLideN64, but not the GLES 3.1 variant.  But overall this is still good news because it means we can can get at least the first two variants into the master branch.  With some more work on my end we may be able to get the GLES 3.1 variant into master eventually.

I have heavily rebased the gliden64-integration branch
https://github.com/mupen64plus-ae/mupen64plus-ae/commits/master
https://github.com/mupen64plus-ae/mupen64plus-ae/commits/gliden64-integration
https://github.com/mupen64plus-ae/mupen64plus-ae/commits/gliden64-gles31

I renamed the original gliden64-integration branch to defunct/gliden64-integration/1 so that we don't lose the discussions attached as comments on that branch.  But we should consider that branch dead.

Highlights of the rebased branches
 - Eliminated unneeded changes to manifest, SDL2, mupen64plus-core, and ae-bridge (integration no longer requires upstream involvement :) )
 - Cleaned up and logically separated the changes to the makefile, assets, resources, and java code
 - Split the GLES 3.1 changes into a new branch, so that we can still test that variant on supported devices
Title: Re: GLideN64 Android port
Post by: littleguy on May 21, 2015, 10:35:06 AM
I need help again.

@Gonetz - I can help on this after work, hopefully this evening.  Note that I just rebased the gliden64-integration branch (see last post) so you might want to try the boost merge process again.
Title: Re: GLideN64 Android port
Post by: DonzBegonz on May 21, 2015, 04:15:54 PM
I just tried out the new gliden64 plugin using the 3.1 Gles version on my Nvidia shield tablet. the game I was running was Mario Tennis, and I have to say, what a major improvement. the game still has major slowdowns during the replays and there's also still some graphical issues on the ball, but this completely blows every other plugin out of the water.

will you guys be doing a version for speed vs accuracy like you did with all of the other plugins?
Title: Re: GLideN64 Android port
Post by: littleguy on May 21, 2015, 05:32:27 PM
@DonzBegonz Yes, if necessary.  That's just a front-end tweak and will be done at the very end when we've decided which settings are most important on Android.

Testers: Great news, GLideN64 is now being built by Paul's auto-build bot.  So it should be a little easier to find the latest builds with the new plugin :)

The most important build right now is the one containing the GLES 2.0 and 3.0 variants of the plugin, since I am about ready to merge this to master.  This version is installable on devices as old as Froyo.  The GLES 3.0 variant of the plugin obviously requires a newer device, but everyone should be able to test the GLES 2.0 variant.  If anyone experiences any crashes with this build, please let me know ASAP.
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_gliden64-integration_201505211206_141bda0.apk

If you have a Lollipop device with GLES 3.1 support, you can test that variant of the plugin using this build:
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_gliden64-gles31_201505211203_cf44cae.apk

Finally, if you just want the latest version that doesn't include GLideN64, here it is.  You might want to run this as a comparison if the other builds crash on you.
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201505211102_a188bbe.apk
Title: Re: GLideN64 Android port
Post by: DonzBegonz on May 21, 2015, 07:46:27 PM
@littleguy you are an absolute gentleman and a scholar
Title: Re: GLideN64 Android port
Post by: littleguy on May 21, 2015, 08:30:09 PM
@DonzBegonz That's debatable :P but thanks

@Gonetz Bumped into this and wondered if it had anything to do with the missing textures in GLES 2.0
http://developer.android.com/guide/topics/graphics/opengl.html#textures
Title: Re: GLideN64 Android port
Post by: IDSG on May 21, 2015, 09:58:12 PM
Tested the GLES 2.0 version and, now it shows something on my tablet (MALI400MP), its really slow and have black textures but at least is working now and showing some things
Title: Re: GLideN64 Android port
Post by: littleguy on May 21, 2015, 10:44:26 PM
@Gonetz I think I fixed the makefile for boost/GLideNHQ.  It looks like there are still a few link errors unrelated to boost/png.  Please see my personal branch at
https://github.com/littleguy77/mupen64plus-ae/commits/gliden64-glidenhq

The Android makefile has a lot of quirks.  A few things to note:
 - NDK views boost as a non-system, pre-built library, so we define a few new modules accordingly
 - We are already building libpng as a module, so we link using the mechanisms used in e.g. glide64mk2
 - Linking with libpng will automatically link with libz, due to how jni/png/Android.mk is written
 - To link GLideN64/GLideNHQ with boost/png, we use the LOCAL_STATIC_LIBRARIES parameter
 - LOCAL_LDLIBS is generally used only for "system" libraries that are bundled with the NDK

You can browse the diff here: https://github.com/littleguy77/mupen64plus-ae/commit/8fa5d5b96b1445d979f31c791e5ccb84bc5820a6

Title: Re: GLideN64 Android port
Post by: retroben on May 21, 2015, 11:51:18 PM
Updated with the variant build and GLideN64 still works and has the textures.

Banjo-Tooie has a new issue where the screen goes black when no HUD items are on the screen.
If I make the egg ammo appear,the screen returns,but when that goes away,it turns solid black again.
My results are still with slightly displaced skybox textures and a rectangle shadow along with paths being visible through walls as if the polygon offset hack was in a bad position,even if the hack is disabled or changed.
I do have my "no frameskip" 60fps code on though.

Edit: Yoshi's Story is not exiting!

I am using GLES2 variant:
Jungle Puddle water is unfortunately freaking out on the surface :( while the light rays and the water itself is okay.
The top left fruit dot is changing size randomly.
The surface colors are there but glitched around a bit and shaking like crazy.
Really gotta sort this top left corner of the screen out.
I think it has something to do with FBEmulation since Gex 3 doesn't have the minor left side of some models texture displacement with it disabled.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 22, 2015, 12:22:29 AM
@Gonetz Bumped into this and wondered if it had anything to do with the missing textures in GLES 2.0
http://developer.android.com/guide/topics/graphics/opengl.html#textures
I recall that I already had problem with textures on my Note 2 year ago, when I worked on my first Android port. That time I solved the problem by copying Textures.cpp from gln64. Sources were not so different as now.
So, the problem is probably in texture formats (most likely internal formats), which are available in GLES2 but not supported by Mali400 drivers.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 22, 2015, 12:26:41 AM
@littleguy - many thanks for the help and explanations! I'll check your branch for link errors. BTW, is it possible to build GLideNHQ as separate lib and link together with GLideN64 dll, as it is intended? If it is possible, it's better to make it this way.
Title: Re: GLideN64 Android port
Post by: retroben on May 22, 2015, 12:39:04 AM
Read Gonetz's reply above.

Just finished testing Smash Bros. on the variant build and it also no longe exits.

The primary thing to fix besides Mali is texture sizes.
On a few characters,occasionally: Luigi and Mario are missing their over-alls' buttons,Kirby is missing his face,Yoshi's back is weird,and Jigglypuff can be missing half her face.

On Hyrule,the distance sometimes has giant texturing when you are close to your opponent while being farther makes them fix briefly.
Shields are displaced at times and fireballs overlap their image the first few shots.

GLideN64 is actually now the fastest plugin on Super Smash Bros. (was gln64) when FBEmulation is disabled,and this is with more accuracy sorta like Glide64 has.
Four DKs on Hyrule can actually reach 60fps at times!
The graphics (like "full powered" lighting) still render "properly" while the outer screen is glitched.
I do get the black square replacing the magnifying glass when a player is near a death zone.
A good feature to add for manual triggering is "buffer clear" so the outer screen will look clean without needing FBEmulation enabled if you are trying to squeeze out the most speed.

Edit: Conker is still giving me a black screen but runs and also no longer exits.

Turning off FBEmulation makes visuals appear and the framerate is really smooth!
(using the "Framerate Fix" cheat I ported to NTSC)
The textures are perfect from what I experienced,and the effects like the sunlight and Mrs. Bee's wings are fully intact.
Speech bubbles seem perfect but I think there is a minor few pixels missing on some of them.
There is some instances where I can see other floors through some walls.
And I am obviously getting a rectangle shadow for Conker and the square on the top left of the screen like the original glN64.

I wonder what's causing the black screen in Conker,and I am puzzled Banjo-Tooie also gets some black screen moments when no HUD elements are onscreen.
Title: Re: GLideN64 Android port
Post by: retroben on May 22, 2015, 01:32:04 AM
Paper Mario no longer exits,and I now know that the Star speech is visible,but the same glitches I mentioned before,and additional general issues like a fence's texture changing size.
During fighting Bowser when he becomes invincible,the screen resolution gets too big and overlaps the screen on the cutscenes when you are attacking him there. Forgot to mention the star on the bottom right after speech ends is glitched out in a rectangle shape.

OKAY.

First unique issue.

Kirby 64 has flipped images for Nintendo and HAL Laboratory before the title screen.
The fairy cutscene looks perfect,but the end had a glitched background.
File select textures are repeating,and after hitting a star block in level 1,the Health HUD changed to tiny repeating ones. (though this one is a general issue like most other games with texture sizes)

Edit: Zelda Ocarina no longer exits,as I mentioned on several games... skybox displaced textures,and wrong sized textures at times on walls and floors.
Unique issues like no triangles when Z-Targeting an enemy,HUD icon for A is too small,and last heart is missing from the screen.

Most irritating issue at the moment is the one for pretty much every game with the wrong size textures issue.
So I will probably try to leave out any more non-unique texture size issues for any further test results.

A special treat...

Majora's Mask European Debugger Build: With four controllers enabled,the debug stats will appear at boot time,the stats are colored squares instead of text and the timestamp. (Glide64 shows these)
Missing afterimage effect on title sequence because it sticks to the screen background. :(
Graphics are okay and some identical issues from Ocarina,and it is missing the item moving into place of choice when selecting one.
Lens of Truth works fine on the Snowhead climbing challenge. ;D
Also,oddly,the A button is fine.

Unique one,the time of day HUD is missing all of the sprites making it impossible to know what time it is. :'(
Someone please test GLES2 with Majora's Mask (U) for this issue.

On a final note (heh note pun) for now,Banjo-Kazooie looks great,but it appears the blue or otherwise underwater effect is missing.
Title: Re: GLideN64 Android port
Post by: rafar on May 22, 2015, 04:04:51 AM
on my lg g2 with snapdragon 800 I only can run and play with GLES 2.0, I dont know if GLES 3.0 could be run correctly, actually with many glitches.
Title: Re: GLideN64 Android port
Post by: littleguy on May 22, 2015, 07:40:15 AM
BTW, is it possible to build GLideNHQ as separate lib and link together with GLideN64 dll, as it is intended? If it is possible, it's better to make it this way.

Sure, and in fact that seems to have taken care of the remaining link errors.  Try my latest:
https://github.com/littleguy77/mupen64plus-ae/commit/4b0624f8e27591a0d3203b3d71566ccc99c40988
Title: Re: GLideN64 Android port
Post by: littleguy on May 22, 2015, 07:49:43 AM
Ah, I think I found the error in my first attempt, and why the second (falsely) succeeds.  Will rebase my fork with the fixes right now.
Title: Re: GLideN64 Android port
Post by: littleguy on May 22, 2015, 08:02:49 AM
@Gonetz Would it be possible to eventually remove the boost dependency?  I really dislike how it bloats the repository and brings the Eclipse indexer to its knees.  Also it represents yet another third-party repository for us to track.  (We probably won't ever need to update it, but still it's just one more place to search whenever we have regressions.)
Title: Re: GLideN64 Android port
Post by: littleguy on May 22, 2015, 08:30:32 AM
@Gonetz Ok, I think I got GLideNHQ building properly now.

Here it is when compiled directly into GLideN64:
https://github.com/littleguy77/mupen64plus-ae/commit/a1721fadb9e6dc9c802eab68a1601cff9c57f157

And here it is when compiled as a static library:
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/bb706a6e3bb6a15989a6bd39d2c0afaf5359a760

I'm not sure if I'm using the right build flags for using it as a library.  I'd suggest you verify the approach in the first link before moving on to the approach in the second link.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 22, 2015, 08:31:53 AM
@littleguy The link issue in your glidenhq branch was caused by a mistake in the project file: TxFilterStub.cpp must be excluded as it is not needed anymore. The project compiled successfully.
To test hires-textures I need path to folder with HD packs. On PC default path is Plugin/hires_texture for Zilmar and ./hires_texture for Mupen64Plus. On Android it must be user-defined folder, as with rom library. GLideN64 has config option for user-defined folder - config.textureFilter.txPath. However I forgot to expose it to Mupen64Plus config. I'll fix it.

Of course boost dependency can be removed. Eventually. I don't have time for it now. I'm officially unemployed. Funds collected during Indiegogo campaign already ended. I can work on the project circa a week, then I'll have to find new full time job. Thus, I'm trying to solve all urgent problems with the plugin ASAP.
Title: Re: GLideN64 Android port
Post by: littleguy on May 22, 2015, 08:37:05 AM
Haha I think we cross posted.  I completely understand about boost being very low priority.  Mainly just wanted to make sure it could eventually be done by someone (not necessarily you) without lots of blood sweat and tears.
Title: Re: GLideN64 Android port
Post by: retroben on May 22, 2015, 11:03:28 AM
@Gonetz: Well in that case.

Issue summary of GLES2 with Qualcomm:
1. Textures wrong size.
2. Various issues caused by 1 like various minor bits ,top left textures,and freakish Bowser in Paper Mario.
3. Random black textures in some games. Rare games mostly. :(
4. Framebuffer effects missing and/or broken for most Rare titles (Conker unplayable with FBEmulation enabled)
5. Banjo-Tooie rectangle shadow,black screen when no HUD items.

Others with different issues on another GPU please also summarize your results.

Edit: Banjo-Tooie was the other thing,despite displaying the CCL bubble effect perfectly fine.
Also,performance with Banjo-Tooie is a big issue with AND without FBEmulation.

Maybe Yoshi's Story is also one to look at since the Jungle Puddle water surface is still shimmering like crazy even though the coloring is intact.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 22, 2015, 11:31:48 AM
@retroben ok, thanks!
Title: Re: GLideN64 Android port
Post by: Gonetz on May 22, 2015, 11:57:16 AM
@littleguy:

I've build version from top commit of gliden64-glidenhq from your repo
https://github.com/littleguy77/mupen64plus-ae
It built ok when I added -DGLES3 for GLideNHQ library. TXFILTER_LIB is redundant for the lib, only plugin uses it.
USE_SDL and MUPENPLUSAPI  also redundant.
I see no other issues in makefile.

When I uploaded it on my Shield, I got warning that the program is probably installed incorrectly.
It runs though. I set GLES3.1 profile, run Super Mari 64 - works ok.
Then I created custom profile and enabled texture enhancement in it (set any value between 3 and 12). I started the rom with that profile and it crashed instantly. Need to debug what's going on.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 22, 2015, 12:46:39 PM
I've got it working!
The problem is with correct path. Texture library uses 2 paths:
- path to the Plugin folder, where it stores texture cache.
- path to folder with hires-packs.
The library tries to load saved cache for current game. Since I did not implement correct paths for Android, lib crashes.
When I provide empty string as rom name, it does not search the cache and works correct. Here the screenshots from SM64, standard and with HQ4x enabled:
https://drive.google.com/file/d/0B0YqMPjGo3B2aWpDYzVlZ2QtdTQ/view?usp=sharing

So, I need help from emulator's side with the paths. Path for texture cache can be anywhere; user should not care about it unless he/she want to port saved cache from other computer. Path to hires packs should be user-defined imo.

There is another technical issue. Texture library can use multithreading for texture processing. There is a function in TxUtil.cpp - TxUtil::getNumberofProcessors(). It is not implemented for Android. Currently I hide all try-catch under
#ifndef ANDROID, so numcore = 1. If you know, how to write correct code for Android, please help me with it.

PS I used gliden64-glidenhq branch from https://github.com/littleguy77/mupen64plus-ae  for my experiments.
Title: Re: GLideN64 Android port
Post by: retroben on May 22, 2015, 12:52:06 PM
Nice going Gonetz! ;D
(you also beat me before I could post)
Edit for above: Why u no test 5xBRZ? :P Is it not available yet? (I really hope for it to be usable on GLES2)

I still can't get GLideN64 to run on my x86 tablet with either variant.

It creates my 3.0 context Build CL yet still doesn't run.

Milliseconds later it says Destroying GL context,is that the problem?

Small time as 12:40:00.359 to 12:40:00.529 when destroyed after creation. (tiny .170 difference)

I ran Glide64mk2 and then closed,found it out!

I finally found the issue!

It is destroying the context when running while Glide64mk2 doesn't.
After closing the running Super Mario 64,it destroys context properly on mk2.
On GLideN64 (both variants),it is destroying the GL context immediately after creating it for some odd resaon,making the plugin unusable on Android x86 and thus the game doesn't start.

Edit: I was messing around in Smash on my FireTV and noticed whenever I hovered CPU2's cursor over different characters,my P1 Kirby's face hilariously changed every time to various specific sizes and positions.
Always the same position for every character hovered over.

On Samus,his face is stretched,on Captain Falcon,his face was pushed to the side.
On Yoshi,he becomes "Kakakaruh karrotkake" while Jigglypuff makes his face disappear,and on a yellow Kirby...P1 Kirby's face was perfect.
However,CPU2 Yoshi's back saddle was correct when P1 is Kirby.
Maybe this information is really helpful,as it dictates that other characters mess up each others visual detail positions and sizes.
Generally meaning each object and image is incorrectly copying detail stats instead of securing their own specific ones.
Title: Re: GLideN64 Android port
Post by: littleguy on May 22, 2015, 05:41:16 PM
@Gonetz Excellent!

The warning message about the installation is just because I commented out the GLES 2.0 variant.  The app always checks to be sure it has all libraries on startup (every once in a while Android doesn't seem to install an APK correctly, according to some bug reports).

The high-res texture stuff has been on the todo list for a long time.  I can lookup the location that Rice uses and you can hard code that temporarily.  Later on I can wire up the front end however necessary if we need to give the users more flexibility.

I'll look at this weekend and provide a more in depth response.  Just didn't want to leave you guessing :)

Thanks for mentioning the tweaks to the makefile.  I'll make the changes and get the GLideNHQ branch into the main repository this weekend as well.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 23, 2015, 08:39:36 AM
@littleguy the situation is much worse than I thought. Any call to boost functionality causes crash.
I put lots of log messages. The crash happens in TxTexCache::TxTexCache, TxTexCache.cpp
Code: [Select]
if (_options & DUMP_TEXCACHE) {
/* find it on disk */
std::wstring filename = _ident + L"_MEMORYCACHE." + TEXCACHE_EXT;
LOG(LOG_MINIMAL, "filename=%ls\n", filename.c_str());
LOG(LOG_MINIMAL, "TxTexCache::TxTexCache before boost call\n");
LOG(LOG_MINIMAL, "_path=%ls\n", _path.c_str());

boost::filesystem::wpath cachepath(_path);
LOG(LOG_MINIMAL, "TxTexCache::TxTexCache after boost call 1\n");

Log:
Code: [Select]
05-23 19:33:06.102 31531 31877 D GLideN64: filename=SUPER MARIO 64_MEMORYCACHE.htc
05-23 19:33:06.102 31531 31877 D GLideN64: TxTexCache::TxTexCache before boost call
05-23 19:33:06.102 31531 31877 D GLideN64: _path=/storage/emulated/0/mupen64plusae-v3-alpha/CoreConfig/UserCache/mupen64plus
05-23 19:33:06.103 31531 31877 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 31877 (CoreThread)

That is first call to boost causes crash. boost::filesystem::wpath cachepath(_path) is just a constructor call, which copies input string into internal string:
Code: [Select]
    path(const string_type& s) : m_pathname(s) {}

@Gillou68310 - you are the boost build expert. Could you check, what is wrong with it? May be GLideNHQ lib has wrong cpp flags in the makefile?
Title: Re: GLideN64 Android port
Post by: Gonetz on May 23, 2015, 11:06:46 AM
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on May 23, 2015, 11:56:49 AM
@gonetz I'm on holiday 8) so I won't have time to look at the boost issues until tuesday. Maybe you can test with crystax ndk in the meantime.
Title: Re: GLideN64 Android port
Post by: retroben on May 23, 2015, 12:51:04 PM
Memorial day I presume? ;)

@Gonetz: Maybe something else for the meantime like trying to find a fix for the wrongly changing texture sizes?
Or perhaps the Conker and Banjo-Tooie buffer issues?

Banjo-Tooie is missing the dynamic shadow render even though FBEmulation is enabled,and ironically has a proper shadow shape when FBEmulation is disabled.
I guess both that and Conker are in terrible shape because Conker doesn't even display with it enabled.
Very strange behaviour.

Neglected DK64,but it is missing: the zipper effect,untouched bananaport transparency,and the pause buffer image.
It is among the worst with blackness of some textures when standing in certain spots that make almost all textures solid black.
If not that,it has burnt black edges between the beach and grass.
Also,most Rare games have bad polygon offset issues regardless of enabled and disabled polygon offset hack as with Banjo-Tooie's paths,DK64's floor oddity and Conker's see-through spots.

Just trying to give all of the information I can. So,sorry if I am being really irritating. :-\
Title: Re: GLideN64 Android port
Post by: gdark100 on May 23, 2015, 03:13:03 PM
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Texture pack library is kinda irrelevant when you have a plugin that doesnt even display the textures in the first place.
Title: Re: GLideN64 Android port
Post by: IDSG on May 23, 2015, 05:01:46 PM
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Texture pack library is kinda irrelevant when you have a plugin that doesnt even display the textures in the first place.

Come on, don't be that a$$hole, the dev team are working hard fixing things, they have real jobs and lifes, i am a rookie developer and i know  that some things needs time to debug and fix them
Title: Re: GLideN64 Android port
Post by: gdark100 on May 23, 2015, 05:20:55 PM
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Texture pack library is kinda irrelevant when you have a plugin that doesnt even display the textures in the first place.
Come on, don't be that a$$hole, the dev team are working hard fixing things, they have real jobs and lifes, i am a rookie developer and i know  that some things needs time to debug and fix them
Im not being an asshole. Sorry if I sound like that. Totally agree with what you said, but gonetz made the development of this plugin his full time job (with Indiegogo campaign money). Also he have a very tight time to work on the plugin, like he said a few posts ago, so it would be better to fix critical problems first (like the plugin barely working on kinda a lot of GLES2 devices). Of course, is up to him to decide what is priority...
Title: Re: GLideN64 Android port
Post by: retroben on May 23, 2015, 07:47:00 PM
Would it be possible to infuse parts of the Android glN64 plugin into it to fix a portion of the issues and then finetune it to look correct again?

Maybe just looking at the Android glN64 plugin's source code could help Gonetz figure out a fix.
Finding out what glN64 does that is possibly missing or incorrect for proper Android GLES2 rendering in GlideN64.

If he could Frankenstein with glN64 and GLideN64,hopefully it would finally fix things.

An example is Banjo-Tooie's paths are not seen through the Jinjo Houses on glN64. (proper polygon offset value)

@gdark100: Could you tell me if the textures are ALL black on glN64 with the same games you tested with GLideN64?

If textures are at least present on your Mali device with glN64,this could help greatly.

Edit2: A better example is DK64 with glN64 which displays textures properly on DK64 in DK Isles when GLideN64 even gives ME trouble with it having all black textures in some spots,black-burnt blending between beach and grass,and even broken water coloring.

Edit3: I sincerely apologize for my laziness,I found an issue with the Banjo games related to framebuffer that I neglected to test for.

Banjo-Kazooie's puzzle minigame looks perfect while Banjo-Tooie's Jiggywiggy Challenges lack video and are just solid black instead.

@gdark100: Please,do tell us the results with glN64,if you have textures where they are black in GLideN64,then it will help Gonetz to fix the Mali issue by utilizing the Android glN64 source code.
Title: Re: GLideN64 Android port
Post by: gdark100 on May 23, 2015, 09:22:50 PM
@gdark100: Could you tell me if the textures are ALL black on glN64 with the same games you tested with GLideN64?

@gdark100: Please,do tell us the results with glN64,if you have textures where they are black in GLideN64,then it will help Gonetz to fix the Mali issue by utilizing the Android glN64 source code.
On Mali400MP, textures works perfect on all plugins, except glideN64, on the tested games (on glideN64 all textures are black like show in the screenshots a few posts back). On PVR 540, textures looks OK, but it runs at less than 1 fps I think, very slow. All other plugins have acceptable speeds (at least on SM64).
Title: Re: GLideN64 Android port
Post by: littleguy on May 23, 2015, 10:19:39 PM
@Gonetz Sorry to hear that.  But it sounds like things are at least building properly, which is very good news to me.  Since we'd rather not include boost in the project as a long-term solution, this may all resolve itself later when someone rewrites the file handling code to eliminate the boost dependency.  That's already the plan for the glide64mk2 plugin.  https://github.com/mupen64plus/mupen64plus-video-glide64mk2/issues/46

In terms of impact, the Android community would benefit the most if GLideN64 had basic GLES 2.0 support.  Two-thirds of current Android users do not have GLES 3.x support.  https://developer.android.com/about/dashboards/index.html#OpenGL.  Even with rapid adoption of new Android devices, it will be a long time before GLES 3.x is the dominant majority.  With your unique skills and perspective, you are our best chance of having a well-implemented GLES 2.0 variant of GLideN64.  Keep in mind a GLES 2.0 variant of GLideN64 would not need to be perfect to be considered successful; it would only need to be comparable to the other three plugins currently used in mupen64plus-ae.  I dream of a day when one video plugin is uniformly superior for 90% of all titles on Android.  GLideN64 could be that plugin.
Title: Re: GLideN64 Android port
Post by: retroben on May 23, 2015, 11:28:04 PM
@gdark100: Goody! There just may be some hope left for fixing the black textures in other GPU/s if we can see some successful imports from gles2n64 into GLideN64.

@littleguy: One nice touch is that a lot of the buffer and render effects are functional like Banjo-Kazooie's puzzle with perfectly clean visuals,Tooie's CCL bubble (puzzle video image sadly solid black),proper lens of truth rendering,sorta Yoshi's Story Jungle Puddle water,and Paper Mario's star speech.
Could be quite a few more in other games that are not in other plugins.
Another one is faster performance on a few games like Gex 3 and some instances in Super Smash Bros. when FBEmulation is disabled though.

And if we can get at least the enhancement settings like 5xBR,it would be even nicer.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 24, 2015, 12:50:43 AM
@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. There is room for optimizations, but it should work ten times faster to be usable by most of GLES2 devices. Currently there are performance problems even with PC hardware. I consider GLES2 version as remedy for devices with poor GLES3 support, as my Note 3. Note 3 runs GLES 2 version without speed or texture issues. I'll try to fix compatibility with Mali400, but performance hardly will be acceptable.
GLideN64 is new generation graphics plugin and it requires new generation GL API and hardware which supports it. AFAIK, authors of Dolphin emulator does not even consider GLES2 as possible platform for porting. GLES2 version of GLideN64 misses essential part of functionality, which makes it "advanced".
Anyway, texture library does not depend on GL level, and it is very important part of the plugin. May be I'll spend remaining week to make it boost free. Since its code now differs from GlideHQ for glide64mk2, GlideHQ fix will not automatically help here.
Title: Re: GLideN64 Android port
Post by: retroben on May 24, 2015, 01:11:00 AM
What do you think about my suggestion to pull a frankenstein and infuse parts of gles2n64/gln64 into GLideN64 to fix the black texture issue?

My example was DK64 from how bad DK Isles looks on GLideN64 when gles2n64/gln64 has proper textures for DK64.
However,Majora's Mask has partial black texture issues on gles2n64/gln64 that GLideN64 no longer has on Qualcomm.

Makes me wish Android's Glide64mk2 was a suitable choice for infusing parts of into GLideN64.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 24, 2015, 01:58:44 AM
GLideN64 is now too far from gles2n64/gln64 to take anything from its predecessor.
Black texture issue can be fixed without it, I just need some time for that.
Title: Re: GLideN64 Android port
Post by: littleguy on May 24, 2015, 09:33:41 AM
@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. There is room for optimizations, but it should work ten times faster to be usable by most of GLES2 devices. Currently there are performance problems even with PC hardware. I consider GLES2 version as remedy for devices with poor GLES3 support, as my Note 3. Note 3 runs GLES 2 version without speed or texture issues. I'll try to fix compatibility with Mali400, but performance hardly will be acceptable.
GLideN64 is new generation graphics plugin and it requires new generation GL API and hardware which supports it. AFAIK, authors of Dolphin emulator does not even consider GLES2 as possible platform for porting. GLES2 version of GLideN64 misses essential part of functionality, which makes it "advanced".
Anyway, texture library does not depend on GL level, and it is very important part of the plugin. May be I'll spend remaining week to make it boost free. Since its code now differs from GlideHQ for glide64mk2, GlideHQ fix will not automatically help here.

@Gonetz I see.  Sounds like I have overestimated the innate capabilities of GLES 2.0.  In that case, maybe a more realistic hope for the GLES 2.0 variant is that players can switch to it temporarily to get past certain parts of certain games, where the other plugins fail.

I know you've mentioned some of this already, but could you summarize the fundamental differences between the three variants?  In particular I'd like to know how much is lost going from GLES 3.1 to GLES 3.0.  Unless I can resolve the binary backward-incompatibility of APP_PLATFORM 21, we will not be able to get the GLES 3.1 variant into the master branch and on Google Play.

Also, if you could list which subset of settings should be displayed for each variant, I can go ahead and update that as well.
Title: Re: GLideN64 Android port
Post by: xperia64 on May 24, 2015, 10:17:44 AM
I know you've mentioned some of this already, but could you summarize the fundamental differences between the three variants?  In particular I'd like to know how much is lost going from GLES 3.1 to GLES 3.0.  Unless I can resolve the binary backward-incompatibility of APP_PLATFORM 21, we will not be able to get the GLES 3.1 variant into the master branch and on Google Play.

Also, if you could list which subset of settings should be displayed for each variant, I can go ahead and update that as well.
It'd be a nuisance, but if it comes down to that, it's possible to post multiple APK versions on Google Play under the same listing. Alternatively, it'd probably make the APK huge, but 2 sets of libraries could be included for armeabi-v7a and x86 (I don't see armeabi getting platform 21 or having GLES 3.X :P)
Title: Re: GLideN64 Android port
Post by: Gonetz on May 24, 2015, 12:23:54 PM
I just finished GLideNHQ no-boost edition. Everything seems to work now:
https://drive.google.com/file/d/0B0YqMPjGo3B2SExtSkFnQmgycms/view?usp=sharing

Now I need to implement text drawer. PC version uses FreeType library. I found this tutorial:
http://en.wikibooks.org/wiki/OpenGL_Programming/Installation/Android_NDK#FreeType

Is it possible to add FreeType library to mupen64plus-ae?
Title: Re: GLideN64 Android port
Post by: Gonetz on May 24, 2015, 12:40:02 PM
@littleguy "could you summarize the fundamental differences between the three variants?"
Sure, but I need to check the code for accurate answer. It's midnight of Sunday for me now. I'll check it tomorrow.

As I remember,
GLES3.1 supports almost everything I use on desktop. There is difference in MSAA, and AA currently does not work on my Shield.
GLES3 does not support MSAA and image textures. image textures are used for N64 depth compare shader and for depth based fog in Beetle Adventure racing. Depth based fog can be rewritten with standard textures though.
GLES2 does not support : mip-mapping (very bad), noise dithering (can live without it) , Video Interface emulation (just not implemented for GLES2, possible to do). Not sure that emulation of non-rgba frame buffers works.

I'll check for valid config options set for each version.
Title: Re: GLideN64 Android port
Post by: retroben on May 24, 2015, 01:12:20 PM
Does the star people telepathy scene in Paper Mario use noise dithering?
I see a TV static effect preiodically when he is talking to Mario inside the toad's house at night.

I'll run a test to see if that is what it is.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 24, 2015, 01:22:01 PM
@retroben I don't remember such details.
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: Gonetz 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 :)
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: Gonetz 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.
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: retroben on May 25, 2015, 11:34:52 AM
gdark100 should test it to see if it fixes textures on his device.
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: retroben 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.
Title: Re: GLideN64 Android port
Post by: littleguy 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.
Title: Re: GLideN64 Android port
Post by: Gillou68310 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  ;)
Title: Re: GLideN64 Android port
Post by: littleguy 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.

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2015-05-25-21-18-24.png)  (https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2015-05-25-21-18-58.png)
Title: Re: GLideN64 Android port
Post by: gdark100 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.
Title: Re: GLideN64 Android port
Post by: retroben on May 25, 2015, 11:21:03 PM
I always got farther spread rainbow stripes with GLES2 on boot with games running fine afterward.
The pixels,I got with DetectCFB enabled,and that was the option that makes DK64's initial Nintendo logo appear where he says "OKAY" on boot.

I have yet to run the ES3.0 version as my x86 tablet immediately destroys GL Context after creating it. :(

@gdark100: Are they size changing textures like mine does?
Title: Re: GLideN64 Android port
Post by: Mikhail on May 26, 2015, 12:40:40 AM
Only fcube and Mupen64Plus Demo homebrew are working for me on gles3.0
all games i've tried with it just show wireframes and no textures, the above mentioned demo also
shows the game window in a panel on the right hand side of screen instead of spread accross the whole screen,
like the height and width got inverted.

Gles2.0 is working faster and much better though than the regular glide64,
F1 World Grand Prix I & II both show the in-game osd properly now like RetroArch and it no
longer shows junk outside the game window :-) it does however have a  broken texture on the steering / cockpit
view though which doesn't happen with any of the over plugins.

Nexus 7 2013 - Kitkat  v4.4.4, v66 Adreno320 development driver.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 26, 2015, 03:54:26 AM
@littleguy - I see my mistake, thanks.
Basically, I may use current gliden64-integration branch. Just use updated makefile and updated plugin sources. I've got GLES2 build linked with texture library. Texture enhancement works, but hires textures work only on Shield. Debugging...
Title: Re: GLideN64 Android port
Post by: retroben on May 26, 2015, 04:50:21 AM
Thanks Mikhail!
Now I know that there's hope if FireTV gets that CM12 mod with updated drivers to at least v66 baked in. ;D
Title: Re: GLideN64 Android port
Post by: Gonetz on May 26, 2015, 07:13:58 AM
I found why hires textures do not work on my phone.
The plugin and the texture library use wchar_t strings for paths.
That is all kind of wcs function used: wcscat wcslen wcsncpy and so on.
On my Note 2 the code
Code: [Select]
wcscat(textureFilter.txPath, L"/hires_texture");
results
Code: [Select]
/storage/sdcard0/mupen64plusae-v3-alpha/CoreConfig/UserData/mupen64plus//that is only first character copied. I know that wchar_t was unsupported until Android 2.3, but I run it on 4.1

Is there any way to fix it? May be some compiler flag is missing?
Title: Re: GLideN64 Android port
Post by: Gonetz on May 26, 2015, 10:11:16 AM
I tried to build the project with CrystaX NDK.
I had to remove mupen64plus-video-glide64mk2 from makefile since it won't compile with CrystaX.
I removed -fsingle-precision-constant from makefile because any file which #include <algorithm> won't compile with it.

After that project compiled. When I run it on Note 2 it hangs on rom start with any graphics plugin.
It runs on Note 3, but promised wide string support does not work properly. mbstowcs copies only first character to destination string, thus all paths work incorrect. I've run out of ideas.
Title: Re: GLideN64 Android port
Post by: littleguy on May 26, 2015, 11:11:55 AM
I have a lot on my plate today but I promise to help as soon as I can.

Gilles' suggestion about copying the GLES 3.1 headers into the project may be the least intrusive way to deal with the APP_PLATFORM issue.  That would eliminate the need to use CrystaX-NDK for GLES 3.1 support.  It sounds like CrystaX-NDK may be a dead end for the wchar as well.  Which is fine since I'd rather not have to resort to third-party build tools.

Title: Re: GLideN64 Android port
Post by: fzurita on May 26, 2015, 12:20:37 PM
I have been following this discussion. What about using Multiple APK support so that there are different APKs built with different OpenGLES/SDK versions? With multiple APK support, the user will download a different APK depending on the platform they are running in, yet there will still be only one play store listing. See here:

https://developer.android.com/google/play/publishing/multiple-apks.html
Title: Re: GLideN64 Android port
Post by: Gonetz on May 26, 2015, 12:53:17 PM
I've pushed no-boost GLideNHQ to master.
You may pull update to gliden64-integration branch, use attached makefile and get plugin with texture enhancement support. It's better than nothing. BTW, texture filters and texture enhancements settings are very inconvenient atm. They are just numbers. There should be kind of combobox with list of available options, as on desktop version.
Title: Re: GLideN64 Android port
Post by: littleguy on May 26, 2015, 01:26:42 PM
Thanks!  I hope to get all this into master in the next day or two.

Regarding the combo-boxes, absolutely.  I provided a minimally functional front-end but my plan has always been to replace with combo-boxes and the like once the integration stabilized (didn't want to waste precious time on something that might change).
Title: Re: GLideN64 Android port
Post by: littleguy on May 26, 2015, 01:29:50 PM
I have been following this discussion. What about using Multiple APK support so that there are different APKs built with different OpenGLES/SDK versions? With multiple APK support, the user will download a different APK depending on the platform they are running in, yet there will still be only one play store listing. See here:

https://developer.android.com/google/play/publishing/multiple-apks.html

Yes I know.  That works fine for publishing, though it requires more complicated build scripts.  We want something that's easy for devs to build and debug straight out-of-the-box.  Having multiple build trees would add a lot of nuisance to new contributors.
Title: Re: GLideN64 Android port
Post by: littleguy on May 26, 2015, 10:57:18 PM
Slow progress tonight.  Good news is that Gilles' method of copying the GLES 3.1 headers into the project works to maintain binary compatibility with older devices.  But restructuring the makefiles (commit 498a1) was giving me some strange build issues so I temporarily reverted it.  I should have more progress to report tomorrow.  For now a work in progress branch with a cleaner history:
https://github.com/littleguy77/mupen64plus-ae/commits/gliden64-integration

All GLES variants working, GLideNHQ working (I assume), no boost dependency, installs on older devices, runs GLES 2.0 variant on older devices, all in one APK.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 27, 2015, 12:56:51 PM
I tricked wchar_t support on Android. Here the screen from my Note2:
https://drive.google.com/file/d/0B0YqMPjGo3B2c2RLMjh3QTdzcUU/view?usp=sharing

It was a hard battle. The only 2 widestring functions which works on my devices (except Shield of course) are
mbstowcs and wcstombs, that is convert from char* to whar_t* and vice versa.
Also std::wstring(const whar_t*) works and std::wstring::c_str() works too.
Any manipulations (concatenation, search etc) with wide strings do not work. I wrote wrappers for all used functionality, which converts whar_t* string to char* with wcstombs, and then uses std::string and other functions for char*. Result copied back to  whar_t* with mbstowcs. I tested it on desktop, but on Android my code still crashed.

I found that if you have function foo(const wchar_t * wstr) and call it as foo(L"Hello!"), wstr will get only the first character of your "Hello!" string, that is wstr==L"H". You just can't use wide string constants on Android. You must allocate wchar_t buffer and copy you string to it:
Code: [Select]
wchar_t buffer[128];
mbstowcs(buffer, "Hello", 128);
Needless to say that GLideNHQ uses lots of wide string constants. I had to replace all L"" occurrences with special macro, which does necessary work. Lots of tedious work. The same is for L"" in GLideN64.

After that the paths started to work and textures started to load. I tested it on all GLES2 devices I have on hands. Result is 50/50:
Galaxy 2 (Mali400) - crash
Galaxy Note 2 (Mali400) - ok
Galaxy Note3 (Adreno) - crash
Nook HD+ (PowerVR) - ok
My corrected code works ok on all devices, plugin finds texture pack and starts to load textures. However, on some devices some textures won't load with "error load png file".

Here the test apk:
https://drive.google.com/file/d/0B0YqMPjGo3B2WnpKVUJoc3hHV1U/view?usp=sharing

Path for hires packs:
mupen64plusae-v3-alpha/CoreConfig/UserData/mupen64plus/hires_texture/
That is for SUPER MARIO 64 it will be
mupen64plusae-v3-alpha/CoreConfig/UserData/mupen64plus/hires_texture/SUPER MARIO 64

 
Title: Re: GLideN64 Android port
Post by: retroben on May 27, 2015, 02:02:21 PM
I tried the enhancement instead,and it works beautifully. ;D
Which enhancement number is 5xBRZ?
I used Super Mario 64 with filter 1 and enhancement 12 with seemingly no impact on performance with FBEmulation disabled.

Then I tried Banjo-Tooie with FBEmulation on with the same enhancement and textures were super crisp and sharp.
Still seemingly no additional performance impact.

No more black screen on Tooie at least,but square dynamic shadows normally and another issue when enhancements are on.
All of the text is oversized from the multiplied enhancement strength.
The text "Isle O' Hags" and "Jinjo Village" are garbled in a weird size as a result.
Another oddity,I am getting an app crash exit every time I end the game after the auto save notification.

Edit: Conker still completely black screen with FBEmulation enabled.

Edit2: Super Smash Bros. also has the same text issue with enhancement,even affecting damage percent.
No performance impact on four DKs in Hyrule!

Banjo-Tooie actually runs quite decently aside from the broken dynamic shadow.
Edit3: JiggyWiggy's Challenge puzzle is still solid black. :(

Do you happen to have FB Read Always enabled within FBEmulation?
I believe you have it implemented and it is the reason behind the stronger slowdown when FBEmulation is enabled.
Why else would it be so liquid smooth?
Title: Re: GLideN64 Android port
Post by: littleguy on May 27, 2015, 03:12:06 PM
I tricked wchar_t support on Android. Here the screen from my Note2:
https://drive.google.com/file/d/0B0YqMPjGo3B2c2RLMjh3QTdzcUU/view?usp=sharing

It was a hard battle. The only 2 widestring functions which works on my devices (except Shield of course) are
mbstowcs and wcstombs, that is convert from char* to whar_t* and vice versa.
Also std::wstring(const whar_t*) works and std::wstring::c_str() works too.
Any manipulations (concatenation, search etc) with wide strings do not work. I wrote wrappers for all used functionality, which converts whar_t* string to char* with wcstombs, and then uses std::string and other functions for char*. Result copied back to  whar_t* with mbstowcs. I tested it on desktop, but on Android my code still crashed.

I found that if you have function foo(const wchar_t * wstr) and call it as foo(L"Hello!"), wstr will get only the first character of your "Hello!" string, that is wstr==L"H". You just can't use wide string constants on Android. You must allocate wchar_t buffer and copy you string to it:
Code: [Select]
wchar_t buffer[128];
mbstowcs(buffer, "Hello", 128);
Needless to say that GLideNHQ uses lots of wide string constants. I had to replace all L"" occurrences with special macro, which does necessary work. Lots of tedious work. The same is for L"" in GLideN64.

After that the paths started to work and textures started to load. I tested it on all GLES2 devices I have on hands.

Thanks for the hard-earned knowledge!  That is really useful and may allow us to remove the boost dependency from glide64mk2.

I am curious though, why is all the wide character support necessary?  It is not used anywhere else in the mupen64plus code, I don't think even in Rice HQ.  Are there a lot of texture packs with non-ascii characters in the filenames?
Title: Re: GLideN64 Android port
Post by: Gonetz on May 28, 2015, 02:26:50 AM
@retroben cite from mupen64plus.cfg:
Code: [Select]
# Texture Enhancement (0=none, 1=store as is, 2=X2, 3=X2SAI, 4=HQ2X, 5=HQ2XS, 6=LQ2X, 7=LQ2XS, 8=HQ4X, 9=2xBRZ, 10=3xBRZ, 11=4xBRZ, 12=5xBRZ)
txEnhancementMode = 0

@littleguy - unicode strings are necessary mainly because User folder on Windows is often non-ASCII. User names on my PC use Cyrillic symbols. If path to texture pack has folder with non-ASCII name, it may not work with plain char*. Djipi' texture packs also had non-ASCII sub-folders. So, you should use wchar_t for all user data to be safe.

This problem can be considered as solved. Two problems need to solve to get functional build:
- FreeType support. Technical issue.
- read png errors. GLideNHQ crashes on read png files on some devices. cite TxImage::getPNGInfo:
Code: [Select]
if (setjmp(png_jmpbuf(*png_ptr))) {
DBG_INFO(80, wst("error reading png!\n"));
png_destroy_read_struct(png_ptr, info_ptr, NULL);
return 0;
}
I know nothing about libpng. I just know that compiler warns about this code as deprecated.
However, it works on desktop and on some Android devices. May be other devices use obsolete libpng, which can't read the file? Is it possible to use our own build of lib png based of fresh sources?
Title: Re: GLideN64 Android port
Post by: retroben on May 28, 2015, 03:32:50 AM
Someone managed to make an amazing APNG viewer for Android called Omni Gif,so it should be possible.
It should definitely be possible to implement your own customized version of libpng.

So that 5xBRZ enhancement has amazingly no performance hits from it at all. 8)

Try to use 5xBR on Retroarch for Android,then it will slow to a crawl on most devices,even for 2d system games.
Title: Re: GLideN64 Android port
Post by: littleguy on May 28, 2015, 07:08:45 AM
I know nothing about libpng. I just know that compiler warns about this code as deprecated.
However, it works on desktop and on some Android devices. May be other devices use obsolete libpng, which can't read the file? Is it possible to use our own build of lib png based of fresh sources?

libpng is not part of the Android platform.  We are already compiling it directly into mupen64plus-ae, and it is part of the repository.  Though I'm sure it hasn't been updated in a very long time.  I don't even know what version we've been using.

I am totally swamped the rest of the week but hope to have time this weekend to sort out the png/freetype issues.  If you want to let me know which config options to disable for GLES2.0 and GLES 3.0, I can update the front-end as well to make it more user friendly (hide options and use drop-downs or sliders instead of text).
Title: Re: GLideN64 Android port
Post by: Mikhail on May 28, 2015, 07:20:01 AM
Tried using GLTools with gliden64 Gles 2.0 and it results in black screens even when disabled for the app, you have to unistall it for gles 2.0 to show anything, glide64 is however uneffected and works with GLTools  :o
Title: Re: GLideN64 Android port
Post by: Gonetz on May 29, 2015, 09:19:18 AM
I've checked the code, which plugin's config options are available for Android.

MultiSampling – GLES3.1 only
MaxAnisotropy – remove at all. I see no GLES support for it
EnableLOD – remove from GUI for GLES2. GLES2 unable to calculate lod.
EnableCopyColorToRDRAM – not available for GLES2
EnableCopyDepthToRDRAM– not available for GLES2
EnableN64DepthCompare – GLES3.1 only

Texture library options – include all, but txDump. Texture dumping is for Windows only.

Font options – include all if FreeType will be available. Otherwise, remove all.

Bloom options. Bloom currently not available for GLES2, but it can be fixed. I haven’t tested Bloom on Android yet, may be some additional work needed here.
Title: Re: GLideN64 Android port
Post by: retroben on May 29, 2015, 10:25:28 AM
I tried bloom on the enhancement build,and it did not work yet.

HWLighting works on GLES2 in Super Smash Bros.,but is immensely slow.

I think MultiSampling is actually working on GLES2,if not on GLideN64,someone please mod source code to patch in Rice's MultiSampling if at all possible since it does in fact work.
(I believe Rice's MultiSampling is independant of the plugin,and was implemented by hand quite a few years ago)

I want to have access to MultiSampling on GLideN64 to combine with 5xBRZ for maximum crispness.

https://code.google.com/p/mupen64plus/issues/detail?id=338
Title: Re: GLideN64 Android port
Post by: Gonetz on May 29, 2015, 11:02:42 AM
retroben, there are two ways to get MSAA:
1. create graphics content with AA enabled. Content created by Mupen64Plus core, not by the plugin. Plugin may just say to core that AA is desired. GLideN64 does that, but it does not guarantees that emulator's core will create necessary context. MSAA is not OpenGL core feature.
2. OpenGL core specification defines MSAA only for Frame Buffer Objects. That is plugin uses it only when frame buffer emulation is enabled. Only GLES3.1 specification supports MSAA for FBO.
Title: Re: GLideN64 Android port
Post by: fzurita on May 29, 2015, 02:22:56 PM
I just tried the GLideN64 3.1 version on a nexus player and all I'm getting is a black screen. I tried open gl es 3.1, 3.0, and 2.0 and all give me the same results. The other plugins seem to work fine. The nexus player has a PowerVR 6 processor which is supposed to support 3.1. 

Is there anything I can gather to help debug the issues with the nexus player?

Also, aside from that, there is one other issue with the nexus player that I see. After entering a game, there does not seem to be a way to bring up the menu. I even tried assigning the menu function to one of the keys on my gamepad. This does mean that after entering a game, there is no way to exit the game without going back to the android home screen.
Title: Re: GLideN64 Android port
Post by: Mikhail on May 29, 2015, 03:30:12 PM
How does the Force 4x MSAA for gles2.0 option that's been under developer options since jelly bean work then?

when I select AA in Dolphin it says only 1x is supported.

opengl es 3.0 shader from the app store works for me without issue, opengl es 2.0 vs 3.0, 3.0
shows a major increase in speed for
instanced rendering and transform feedback.

Max Anisotropy is listed as 16x with OpenGL extensions viewer.

www.informit.com/articles/article.aspx?p=770639&seqNum=2
Title: Re: GLideN64 Android port
Post by: retroben on May 29, 2015, 05:09:39 PM
Oop,forgot to respond about the Nexus Player issue...

So this issue is general to ALL x86 Android devices!
Probably the same issue where it destroys GL Context immediately after creating it.
Title: Re: GLideN64 Android port
Post by: fzurita on May 29, 2015, 07:39:20 PM
Oop,forgot to respond about the Nexus Player issue...

So this issue is general to ALL x86 Android devices!
Probably the same issue where it destroys GL Context immediately after creating it.

Interesting, only GLideN64 has this issue?
Title: Re: GLideN64 Android port
Post by: retroben on May 29, 2015, 08:54:54 PM
The other plugins all work fine on x86.
Title: Re: GLideN64 Android port
Post by: retroben on May 30, 2015, 02:49:59 AM
DK64's textures are perfect for me on GLES2 now! ;D
I did not expect it to be fixed for me,but it is.
Still missing pause effect and the zipper effect is black because of this.
Yes,the zipper effect is intact despite being solid black.

How do I stop dithering/stipple from wreaking havik on my visual quality like when underwater on DK64?
Title: Re: GLideN64 Android port
Post by: Mikhail on May 30, 2015, 05:19:13 AM
android:dither="false" in the manifest xml
or
persist.sys.use_dithering = 0 in the build prop

How does dithering look for you in fpse on the bios osd bubbles, the large one in the miiddle on the front screen and the ones in the
cd player should all appear with colour banding without dithering applied.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 30, 2015, 09:57:07 AM
Gillou68310 added FreeType and new pnglib:
https://github.com/Gillou68310/mupen64plus-ae/commits/gliden64

I have corrected my code, and now TextDrawer works fine.
Details:
https://github.com/gonetz/GLideN64/commit/037d2d8e1db2ae3287f6b6742b1b1ba644355204#commitcomment-11438428

Next thing to fix is Bloom post filter.

Attached is a patch with makefiles corrections for Gillou68310's gliden64 branch.
Title: Re: GLideN64 Android port
Post by: retroben on May 30, 2015, 11:31:14 AM
Edit: dammit page overlap,sorry Gonetz. :'(

@Mikhail: What do I edit that into?

Is it an xml inside a certain app's apk file (more difficult),or is there a file in a root directory I need to copy,edit,and then overwrite?

Edit: I already added the build prop one then rebooted,and it did not fix it completely.

Will test fpse bubbles a little bit later when I have time.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 30, 2015, 12:55:23 PM
Bloom postfilter is now GLES2 compatible. New apk with new pnglib, working text drawer and working bloom:
https://drive.google.com/file/d/0B0YqMPjGo3B2UjdJYkhnck1DWHM/view?usp=sharing

To make text drawer working you must set correct font name in emulation profile settings. DroidSans.ttf is a good choice. Also set font size suitable for your device.

To make bloom working, set EnableBloom to 1. Also you may play with bloomBlendMode setting.
Note: bloom adds slowdown on older devices.

All plugin's code changes are in master.

Attached is updated Linux-compatible patch for makefiles.
Title: Re: GLideN64 Android port
Post by: retroben on May 30, 2015, 01:25:36 PM
Great job Gonetz! So much going on right now. ;D
Will test on FTV sometime soon.
Earlier: I am glad that DK64 finally works properly with textures,now all we need is to have see through issues fixed for every game which might also fix the square shadow and solid black puzzle challenge in Banjo-Tooie.
Performance is actually half-decent with FBEmulation in some cases,just Smash Bros. and possibly F-Zero (untested on mine) runs sluggish.

@Mikhail: Yes! Changes for fpse work on the bubble bios screen!
It has banding without dithering,and the admittedly ugly pattern when dithering option is enabled.
Still need to know how to fix up Glide64mk2 so I can turn off the strong stipple dthering within it,mainly when in water on DK64.
Also,Goat Simulator still had dither,but it is harder to point out.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 30, 2015, 01:30:56 PM
Good news: hi-res texture pack loading problem is fixed at least for one of my devices. Probably texture file was corrupted during transfer via usb. I zipped the texture pack and download to the device via wifi.  Unzipped pack loaded without problems.
Title: Re: GLideN64 Android port
Post by: retroben on May 30, 2015, 01:49:06 PM
Bloom is working on my end,obviously causing immense slowdown on my wimpy outdated Qualcomm.
Wimpy because it is outdated on the drivers,if I had the latest drivers,it would probably run lagless with proper graphics.

Any chance we will ever see GLideN64 running on x86 Android devices?
Just upset because I never got to see how it would run on my x86 tablet because of the prematurely destroyed GL Context after creation issue.

BilinearMode setting is broken when disabled/unticked,I get a solid black screen with the game running. :(
I want to use point-sampled to see what it looks like with 5xBRZ enabled.
Title: Re: GLideN64 Android port
Post by: Gonetz on May 31, 2015, 03:24:08 AM
You can't disable texture filtering, plugin does not have that option. BilinearMode setting switch between hardware bilinear filtering and shader implementation of N64 3-point filtering. 3-point filtering was broken for GLES2. I've fixed it.

If you need to check how 5xBRZ works with unfiltered textures, you need to find such textures first. N64 does not filter all textures. Plugin filters only those textures, which filtered on real hardware.
Title: Re: GLideN64 Android port
Post by: retroben on May 31, 2015, 11:09:59 AM
So it is actually missing point-sampled as an option?
I know point-sampled is a filtering/shading/whatever option on the original Glide64 and it made textures look sharp but blocky like it is supposed to.
Using that combined with 5xBRZ could get amazing results.
I would prefer the option to use N64 3-point filter since it is more correct to the system and admittedly less blurry than bilinear.

Personally,I can't stand bilinear filtering (too blurry) and linear audio doesn't sound so good.
One time,I tried src-linear on audio and it sounded horrible compared to trivial.
I think I hit the sweet spot of performance and quality with zero order hold audio.
Title: Re: GLideN64 Android port
Post by: littleguy on May 31, 2015, 01:46:24 PM
Good news: hi-res texture pack loading problem is fixed at least for one of my devices. Probably texture file was corrupted during transfer via usb. I zipped the texture pack and download to the device via wifi.  Unzipped pack loaded without problems.

I just rebased my fork, incorporating you and Gillou's changes and everything looks great!  Hi res textures and on-screen text working on my Shield.  Will start testing other devices, and updating the front-end to make it easier to select options.

Edit: The pull-* scripts are working on Linux now too.
Title: Re: GLideN64 Android port
Post by: littleguy on May 31, 2015, 06:56:33 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.

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2015-05-25-21-18-24.png)  (https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2015-05-25-21-18-58.png)

Never mind, this issue is resolved after I disabled FB emulation (EnableFBEmulation=false).  Should we disable this for all devices when the GLES2 variant is selected?

GLES 2.0 variant running fine on my Tegra-3-based 2012 Nexus 7 (but slow, as expected).  :D
  - GLideNHQ working
  - FreeType working (once I set the font to DroidSans.ttf)

Excellent progress!
Title: Re: GLideN64 Android port
Post by: retroben on May 31, 2015, 07:13:33 PM
Remember that powerful OpenGL ES3.x+ devices can run the GLES2 variant nearly perfect and really fast.
As Gonetz mentioned,I believe. ;)

...I wished I had one of those super strong devices,mainly with the Tegra X1,like the new
awesome "Android TV Shield" console with that same processor and choice of 500GB storage.
Title: Re: GLideN64 Android port
Post by: littleguy on May 31, 2015, 07:59:10 PM
I know, I'm just trying to test other devices.  Actually the NVIDIA Android TV has a better processor (X1) than the other NVIDIA devices (K1).
Title: Re: GLideN64 Android port
Post by: fzurita on May 31, 2015, 09:16:30 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.

(https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2015-05-25-21-18-24.png)  (https://dl.dropboxusercontent.com/u/3899306/Screenshots/Screenshot_2015-05-25-21-18-58.png)

Never mind, this issue is resolved after I disabled FB emulation (EnableFBEmulation=false).  Should we disable this for all devices when the GLES2 variant is selected?

GLES 2.0 variant running fine on my Tegra-3-based 2012 Nexus 7 (but slow, as expected).  :D
  - GLideNHQ working
  - FreeType working (once I set the font to DroidSans.ttf)

Excellent progress!

I tried that option set to true on my NVidia Shield portable (OpenGL ES 2.0) and I don't get those visual artifacts.

Although, I just tried zelda ocarina of time and the pause menu doesn't seem to be working quite right. The first time I bring up the pause menu on the Nvidia shield portable, the FBE seem to work correctly, but after coming out of the pause menu, link's clothing turns black. Also, after opening the pause menu again, the background image is all white.

Also, I just tried Banjo Kazooie and the puzzle pieces are all black.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 01, 2015, 12:55:42 AM
Never mind, this issue is resolved after I disabled FB emulation (EnableFBEmulation=false).  Should we disable this for all devices when the GLES2 variant is selected?
Why? My GLES2 devices support frame buffer emulation.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 01, 2015, 01:24:05 AM
Edit: The pull-* scripts are working on Linux now too.

That's cool, thanks! However, pull-gliden64.sh needs little correction.
getRevision.sh is not executable when it is pulled from repo.
Add chmod +x To make the script working:

Code: [Select]
cd src
chmod +x getRevision.sh
./getRevision.sh
Title: Re: GLideN64 Android port
Post by: Gonetz on June 01, 2015, 02:51:06 AM
I've made automatic detection if texture fix for PowerVR/Adreno is needed:
https://github.com/gonetz/GLideN64/commit/c9f62a55e8dabebbf610386165da59301797bc80
PowerVR_SGX_540 define removed.

Separation is made by Renderer name. Currently fix enabled for PowerVR and Adreno GLES2 renders.
 
Title: Re: GLideN64 Android port
Post by: Gonetz on June 01, 2015, 03:39:49 AM
@littleguy I was wrong regarding Anisotropic filtering.
GL_TEXTURE_MAX_ANISOTROPY_EXT and GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT really missing in GL headers, but
glGetString(GL_EXTENSIONS) contains "GL_EXT_texture_filter_anisotropic" string and call to
glGetFloatv(0x84FF, &config.texture.maxAnisotropyF); returns 16.0 as max anisotropy level.
This, MaxAnisotropy setting should be returned.

I've corrected my code for that:
https://github.com/gonetz/GLideN64/commit/37b5a384863f555aab50d036069adbf8983b3859
Title: Re: GLideN64 Android port
Post by: IDSG on June 01, 2015, 06:42:58 AM
This plugins doesnt have Frameskip?
Title: Re: GLideN64 Android port
Post by: Gonetz on June 01, 2015, 07:11:42 AM
no Frameskip
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 01, 2015, 11:45:46 AM
I know, I'm just trying to test other devices.  Actually the NVIDIA Android TV has a better processor (X1) than the other NVIDIA devices (K1).

I've been testing the recent dev builds from here on my Shield Tablet, but I'm going to be getting the Shield Android TV later this week.  Will let you guys know how things go with it on the emulator. 

OpenGLes 3.0 is a mess on my HTC One M8 Snapdragon 801 (Lollipop 5.02).  Pretty much have to stick with OpenGLes 2 on it.  Crappy Adreno drivers again. 
Title: Re: GLideN64 Android port
Post by: IDSG on June 01, 2015, 01:53:29 PM
no Frameskip

Is planned that feature?
Title: Re: GLideN64 Android port
Post by: retroben on June 01, 2015, 03:40:48 PM
Maybe there can be a global frameskip feature added in the near future.
Since Rice freaks out with frameskip anyway by causing a strobe light of non-skipped frameless frames instead of actually skipping them.
The global frameskip could always work much better by lowering the primary usage impact instead of just the gfx plugin.
One other detail is that all plugins have that irritating yellow pattern that appears between some situations.
Smash Bros. on Rice is the strongest condition.

Maybe this has something to do with and possibly causing the screen render "dithering" issue?
Title: Re: GLideN64 Android port
Post by: Gonetz on June 02, 2015, 10:38:43 AM
I've fixed various issues with FB emulation (not all!), mostly with GLES2. Now you may play Mario Tennis, Lego Racers, Jet Force Gemini etc. New apk:
https://drive.google.com/file/d/0B0YqMPjGo3B2cmdnVDhFcXRmUjQ/view?usp=sharing

@IDSG I have no plans about frameskip support.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 02, 2015, 11:07:47 AM
@littleguy have you tried to use NVIDIA Tegra Graphics Debugger with your Shield? I can't attach it. It says
No attachable processes found.

I tried to follow this advice:
https://devtalk.nvidia.com/default/topic/771427/tegra-tools/unable-to-attach-tegra-graphics-debugger-on-shield-tablet/

 
I've added to my Android.mk:
 
Code: [Select]
#------------------
 
 # tgd libs
 include $(CLEAR_VARS)
 LOCAL_PATH := C:\Temp\android-kk-egl-t124-a32 LOCAL_MODULE :=
libTegra_gfx_debugger LOCAL_SRC_FILES := libTegra_gfx_debugger.a
include
$(PREBUILT_STATIC_LIBRARY)
 
 include $(CLEAR_VARS)
 LOCAL_PATH := C:\Temp\android-kk-egl-t124-a32 LOCAL_MODULE :=
Stripped_libNvPmApi LOCAL_SRC_FILES := Stripped_libNvPmApi.Core.so
include
$(PREBUILT_SHARED_LIBRARY)
 
 include $(CLEAR_VARS)
 LOCAL_PATH := C:\Temp\android-kk-egl-t124-a32 LOCAL_MODULE :=
Stripped_libTegra_gfx_debugger LOCAL_SRC_FILES :=
Stripped_libTegra_gfx_debugger.so
include $(PREBUILT_SHARED_LIBRARY) # end tgd libs
 
 LOCAL_STATIC_LIBRARIES += libTegra_gfx_debugger LOCAL_SHARED_LIBRARIES
+= Stripped_libNvPmApi Stripped_libTegra_gfx_debugger
 
 #------------------

C:\Temp\android-kk-egl-t124-a32 folder contains files from "c:\Program Files (x86)\NVIDIA Corporation\Tegra Graphics Debugger 1.3\target\android-kk-egl-t124-a32\"

It gave me nothing. I want to use that tool to find performance issues in my code.
Title: Re: GLideN64 Android port
Post by: retroben on June 02, 2015, 11:54:36 AM
Banjo-Tooie's dynamic shadow works ;D ,paths are still seen through walls though.
A regression too,the black screen issue when no HUD items are on screen has returned.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 02, 2015, 12:19:09 PM
https://youtu.be/ndBquBTPJDY
Title: Re: GLideN64 Android port
Post by: IDSG on June 02, 2015, 02:07:54 PM
I've fixed various issues with FB emulation (not all!), mostly with GLES2. Now you may play Mario Tennis, Lego Racers, Jet Force Gemini etc. New apk:
https://drive.google.com/file/d/0B0YqMPjGo3B2cmdnVDhFcXRmUjQ/view?usp=sharing

@IDSG I have no plans about frameskip support.

Damn =( , well i need a better device then, btw keep up the good work and hope the optimizations would make the games playable on my tablet (Dual Cortex A9 1.32ghz, 1gb ram Mali400 MP2)
Title: Re: GLideN64 Android port
Post by: Mikhail on June 02, 2015, 02:21:20 PM
Strange gles 3.1 is working but 3.0 doesn't and 3.1 is showing the same graphical glitches as gln64.

I noticed some more glitches with gles 2.0 also with f1 world grand prix II,
the circuit map on the paddok computer screen has an odd effect where it keeps switching
between resolutions and angling it like a parallelogram.

The circles that flip around for the course country flags on the course selection split the texture in
half before refreshing / scrolling the texture leftwards when flipping around this happens in rice also.

Some textures also have a extra white halo outline around them, glide64 also has this problem.
Title: Re: GLideN64 Android port
Post by: retroben on June 02, 2015, 02:28:51 PM
Conker actually shows with FBEmulation enabled,and his dynamic shadow is fully intact,but everything is see-through so much that you can see the already mutilated N64 Logo model and chainsaw from underneath the floor in the beginning and Rareware's gold R is missing on the model because it is behind the blue part.
The C*** and Plucker bar has a reflection wrongly visible below from this see-through issue.
At least it is not a black screen anymore with FBEmulation enabled. ;D

Problems were to be expected since issues were seen previously with Conker on the PC plugin,if I remember correctly.

@Mikhail: Those for GLES2 are likely due to the texture size changing issue generally for mostly all games.

I think it is about time to focus on and fix this general texture size changing issue so tons of visual quirks can finally be removed and differentiating issues can be pointed out more easily if any remain afterward.
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 02, 2015, 02:57:15 PM
The coronas in Legend of Zelda OOT shows through solid objects both outside and inside towns and dungeons on my Shield Tablet (Lollipop 5.1) using both the Es2 and Es3.1 renderers with or without HD Textures.  I am using the latest apk provided by Gonetz. 

(http://s15.postimg.org/wu5dsq3ef/Mupen64_Plus_AE_V3_Alpha_20150530_010128.jpg) (http://postimg.org/image/wu5dsq3ef/)(http://s11.postimg.org/wuux5pfn3/Mupen64_Plus_AE_V3_Alpha_20150602_125108.jpg) (http://postimg.org/image/wuux5pfn3/)
Title: Re: GLideN64 Android port
Post by: retroben on June 02, 2015, 03:33:10 PM
Depth needs to be enabled for ES3.x versions for torch fires and sun corona to work properly.

DK64 has the Nintendo logo at the beginning now,yay!
(it needed a certain setting before,but now works on default ES2 profile)

Has polygon offset not been used this whole time on GLideN64?
Can a build be made with it implemented on GLideN64 so I can perhaps test it on GLES2 to see if paths and other things can no longer be seen through walls and floors?
If that's the case,then this could finally fix the see through issue.
I guess since visuals look so identical to glN64 (similar looking when FBEmulation disabled) and Glide64 (Smash Bros. effects like lighting that are not seen on glN64).

Strange how I don't see that mass of squares with FireTV on DK64 underwater with GLideN64 that was there previously.
It was identical to how the Glide64 plugin looks,but now it is identical to how clear the Rice plugin looks in the water.
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 02, 2015, 03:59:00 PM
@retroben

I'm guessing depth compare still needs to be fixed for the Es3.1 plugin since it only shows a black screen with it enabled.  Thank you for the info though.   
Title: Re: GLideN64 Android port
Post by: retroben on June 02, 2015, 05:22:04 PM
Yeah,seems a few blackness issues are creeping up again.

@Gonetz: What did you change in GLideN64 GLES2 to make the visuals look so crystal clear in comparison to Glide64mk2 and even Rice?
On my end,there was a wall of square gridding in DK64 on GLideN64 like it still is in Glide64mk2,but now that is gone on that recently posted apk of yours.
I and more importantly the other devs really need to know what change you made so it can be used on Glide and Rice.

Edit: Got screenshots of DK64...

The ugly scanlined squares of Glide64mk2:
http://www.2shared.com/photo/j0mxFoiN/Glide64mk2.html

And the perfection of GLideN64:
http://www.2shared.com/photo/7Fhsj9Mr/GLideN64.html

You may need to view the images in low light so you can actually see the squares on the Glide64mk2 image.
I often play at night and it is most noticable when dark.

Edit 2: I think browsers are using a filter and blurring the pictures when you view them in one,downloading the images and viewing them in a viewer like "Perfect Viewer" or a good image viewer on a computer should make it look sharper.
Title: Re: GLideN64 Android port
Post by: psberitz on June 02, 2015, 05:25:25 PM
hello maybe it is connected with this issue
https://github.com/gonetz/GLideN64/issues/563 (https://github.com/gonetz/GLideN64/issues/563)
Title: Re: GLideN64 Android port
Post by: littleguy on June 02, 2015, 09:00:38 PM
@littleguy have you tried to use NVIDIA Tegra Graphics Debugger with your Shield? I can't attach it. It says
No attachable processes found.

Unfortunately no I haven't tried.  Realistically I don't think I'll have much time this week to try it.  If that's the biggest thing you need from me right now, I will make it my priority in the time I do have.
Title: Re: GLideN64 Android port
Post by: fzurita on June 02, 2015, 11:39:05 PM
The latest build doesn't work very well with the shield portable (tegra 4), see the screenshots. The previous build used to work almost perfect. Also, with the new build, I have to disable FBE otherwise the screen is just black.
https://docs.google.com/file/d/0B57Ioy26LWegS0dWVW5aVWN3azA/edit?usp=docslist_api
https://docs.google.com/file/d/0B57Ioy26LWegT3hVR2V2Yk5TM0k/edit?usp=docslist_api
https://docs.google.com/file/d/0B57Ioy26LWegbDdxSGxCZnhBVVU/edit?usp=docslist_ap
Title: Re: GLideN64 Android port
Post by: Gonetz on June 03, 2015, 01:00:24 AM
@fzurita - which version of the plugin you use? GLES2, GLES3?
Can you build the project from sources? I can point the exact place in the code, which could cause that problem, but I can't test it.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 03, 2015, 01:10:19 AM
@littleguy have you tried to use NVIDIA Tegra Graphics Debugger with your Shield? I can't attach it. It says
No attachable processes found.

Unfortunately no I haven't tried.  Realistically I don't think I'll have much time this week to try it.  If that's the biggest thing you need from me right now, I will make it my priority in the time I do have.

I got answer from NVIDIA engineer, who promised to look at the problem. Cite:
Code: [Select]
"Sergey,

I am running into an issue; the SDL code links both GLESv1 and GLESv2. Because it is necessary to REMOVE all GLES libraries from linking when linking the TGD stub, I am seeing problems. The TGD stub is only designed to work with ES2 and above. So the function glBlendFuncSeparateOES is a problem, as it does not link when I replace the -lGLESv1 -lGLESv2 with the TGD stub.

I've not dealt with apps before that link both GLESv1 and GLESv2 since there are functions of the same name in both APIs (which is risky).

So I'm trying to figure out the best option. But one reason you might have been seeing issues connecting is that the app was still linking with the original NDK GLESv1 and GLESv2 libs. As soon as I replaced them as per the docs with the stub, there were missing symbols.

We don't generally see GLESv1 apps anymore, at least with TGD.

I'll continue to look into it. Do you ever actually create a GLESv1 context on Tegra?

Lmb"

That answer was surprise for me. Why the project still uses GLESv1? Do we have GLESv1 plugin, or it is used by core?
I need that tool for debugging, please help.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 03, 2015, 01:42:55 AM
Glesv1 is not used anywhere. But for some reason the SDL2 lib seems to require both glesv1 and glesv2 during linking. You should check if it's possible to build a glesv2 only SDL2.
Title: Re: GLideN64 Android port
Post by: fzurita on June 03, 2015, 08:37:39 AM
@fzurita - which version of the plugin you use? GLES2, GLES3?
Can you build the project from sources? I can point the exact place in the code, which could cause that problem, but I can't test it.

Hello Gonetz, I'm using the GLES2 version of the plugin, unfortunately, that's all Tegra 4 supports. I have built the APK before, is there something you want me to try? I can probably try it if you point me exactly where in the code you want me to make changes.
Title: Re: GLideN64 Android port
Post by: fzurita on June 03, 2015, 08:56:37 AM
Odd issues with FBE enabled on super Mario 64. See the screenshot. It looks normal without FBE and it doesn't seem to happen in other games. This is on an Xperia Z Ultra which has a Snapdragon 800 with Adreno 330 GPU. This was also using the OpenGL ES 3.0 version of the plugin.


https://docs.google.com/file/d/0B57Ioy26LWegZndrZEM4MmtoRTA/edit?usp=docslist_api
Title: Re: GLideN64 Android port
Post by: Gonetz on June 03, 2015, 10:31:02 AM
@ fzurita I think Tegra 4 frame buffer emulation was broken in this commit:
https://github.com/gonetz/GLideN64/commit/16530693298c70e96679dd21574d95f840b5bca8

Check  FBOTextureFormats::init() in OpenGL.cpp
Here I'm trying to detect best parameters for FBO textures. You may see, that I wrote special code for Mali-400, since it don't want to use the values, which theoretically "the best". Probably, Tegra also don't like "the best" values.
You may try to use the same values as for Mali-400. If it will work you may try to find, which parameters Tegra don't like. It also would be useful information.

You need to clone littleguy's repo:
$ git clone https://github.com/littleguy77/mupen64plus-ae
select gliden64 branch
$ cd mupen64plus-ae
$ git checkout remotes/origin/gliden64-integration -b gliden64-integration
and pull latest GLideN64 sources
$ cd tools
$ ./pull-gliden64.sh
when script will ask questions use default parameters.
Build the project and try to find the truth :)
Title: Re: GLideN64 Android port
Post by: Gonetz on June 03, 2015, 10:37:10 AM
Odd issues with FBE enabled on super Mario 64. See the screenshot. It looks normal without FBE and it doesn't seem to happen in other games. This is on an Xperia Z Ultra which has a Snapdragon 800 with Adreno 330 GPU. This was also using the OpenGL ES 3.0 version of the plugin.


https://docs.google.com/file/d/0B57Ioy26LWegZndrZEM4MmtoRTA/edit?usp=docslist_api

OpenGL ES 3.0 version of the plugin uses glBlitFramebuffer to copy frame buffer texture to main color buffer. It is known that glBlitFramebuffer works incorrect for Adreno 330 GPU. You may fix it by using FrameBufferList::renderBuffer for GLES2. It is in the same FrameBuffer.cpp. That variant is not as advanced as the main one, but most games will work ok.
Title: Re: GLideN64 Android port
Post by: fzurita on June 03, 2015, 11:37:29 AM
@ fzurita I think Tegra 4 frame buffer emulation was broken in this commit:
https://github.com/gonetz/GLideN64/commit/16530693298c70e96679dd21574d95f840b5bca8

Check  FBOTextureFormats::init() in OpenGL.cpp
Here I'm trying to detect best parameters for FBO textures. You may see, that I wrote special code for Mali-400, since it don't want to use the values, which theoretically "the best". Probably, Tegra also don't like "the best" values.
You may try to use the same values as for Mali-400. If it will work you may try to find, which parameters Tegra don't like. It also would be useful information.

You need to clone littleguy's repo:
$ git clone https://github.com/littleguy77/mupen64plus-ae
select gliden64 branch
$ cd mupen64plus-ae
$ git checkout remotes/origin/gliden64-integration -b gliden64-integration
and pull latest GLideN64 sources
$ cd tools
$ ./pull-gliden64.sh
when script will ask questions use default parameters.
Build the project and try to find the truth :)

OK, this sounds like fun, I'll play around with it when I get home tonight, unless someone gets to it before me.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 03, 2015, 03:00:43 PM
@gonetz I removed the glesv1 dependency on SDL2 library. I hope it will help:
https://github.com/Gillou68310/mupen64plus-ae/commit/5b9257c78c6ffa091ac23dba0517e0b33e3791b6 (https://github.com/Gillou68310/mupen64plus-ae/commit/5b9257c78c6ffa091ac23dba0517e0b33e3791b6)
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 03, 2015, 04:27:17 PM
I also made an experimental tegra-graphic-debugger branch, I don't own a tegra device so this is completely untested:
https://github.com/Gillou68310/mupen64plus-ae/tree/tegra-graphics-debugger (https://github.com/Gillou68310/mupen64plus-ae/tree/tegra-graphics-debugger)

Sorry for the awfull commits message.
Title: Re: GLideN64 Android port
Post by: fzurita on June 03, 2015, 11:15:41 PM
@ fzurita I think Tegra 4 frame buffer emulation was broken in this commit:
https://github.com/gonetz/GLideN64/commit/16530693298c70e96679dd21574d95f840b5bca8

Check  FBOTextureFormats::init() in OpenGL.cpp
Here I'm trying to detect best parameters for FBO textures. You may see, that I wrote special code for Mali-400, since it don't want to use the values, which theoretically "the best". Probably, Tegra also don't like "the best" values.
You may try to use the same values as for Mali-400. If it will work you may try to find, which parameters Tegra don't like. It also would be useful information.

You need to clone littleguy's repo:
$ git clone https://github.com/littleguy77/mupen64plus-ae
select gliden64 branch
$ cd mupen64plus-ae
$ git checkout remotes/origin/gliden64-integration -b gliden64-integration
and pull latest GLideN64 sources
$ cd tools
$ ./pull-gliden64.sh
when script will ask questions use default parameters.
Build the project and try to find the truth :)

That was strange. When following these directions, I ended up with two copies of the source code, on in the project directory and one in the bin directory. I assumed the one in the bin directory was the right one, hopefully it was the right one. The build works fine though...

Another thing... every time I open a file, eclipse gives me a bunch of errors and the APK refuses to install and run until I delete the errors from the list of Problems. After I delete the errors the APK will install fine. It never actually fails to build using the make files. It seems that Eclipse has its own internal build running that keeps failing.

Edit: So I tried several different values for

      colorInternalFormat = X;
      colorFormat = X;
      colorType = X;
      colorFormatBytes = X;

and nothing seems to having any effect. Gonetz, I also tried the Mali-400 ones like you suggested and that seem to do nothing. What are other plugins using?
Title: Re: GLideN64 Android port
Post by: Gonetz on June 04, 2015, 03:23:08 AM
@fzurita - I guess you did something wrong. I have no bin subfolder inside mupen64plus-ae folder
Try again. Remove previous clone of the repository, and clone again. My latest modification is not pulled into the repository, so you may just switch to gliden64-integration and build the project from here. My older apk was built from this point. If it worked for you, then after building the project you also should get version compatible with your Tegra. After that you need to find my commit, which breaks that compatibility. You may clone GLideN64 repository, switch to commit next to e1000ad and copy GLideN64 sources into mupen64plus-ae. Build and test. If it works, switch to next GLideN64 commit and repeat. Thus you will find the wrong commit.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 04, 2015, 05:09:38 AM
I also made an experimental tegra-graphic-debugger branch, I don't own a tegra device so this is completely untested:
https://github.com/Gillou68310/mupen64plus-ae/tree/tegra-graphics-debugger (https://github.com/Gillou68310/mupen64plus-ae/tree/tegra-graphics-debugger)

Sorry for the awfull commits message.

Thanks for the attempt! Unfortunately, it does not help. Build from f5038f4fe commit does not work - any rom crashes on start with any plugin. What is even worse - tegra debugger still does not see suitable apk or process to attach.

I tried to switch to 5b9257c78 and add debugger libs to Android.mk That build works, but tegra debugger still does not want to work with it.
Title: Re: GLideN64 Android port
Post by: fzurita on June 04, 2015, 05:58:16 AM
@fzurita - I guess you did something wrong. I have no bin subfolder inside mupen64plus-ae folder
Try again. Remove previous clone of the repository, and clone again. My latest modification is not pulled into the repository, so you may just switch to gliden64-integration and build the project from here. My older apk was built from this point. If it worked for you, then after building the project you also should get version compatible with your Tegra. After that you need to find my commit, which breaks that compatibility. You may clone GLideN64 repository, switch to commit next to e1000ad and copy GLideN64 sources into mupen64plus-ae. Build and test. If it works, switch to next GLideN64 commit and repeat. Thus you will find the wrong commit.

I'll give this another shot tonight. On the original commit that you pointed out, I can see what the original hard coded parameters were for openGL ES 2. If that doesn't work, I'm going to start walking through commits.
Title: Re: GLideN64 Android port
Post by: littleguy on June 04, 2015, 08:00:38 AM
@fzurita - Please see the step-by-step instructions for building in the README.mk at the root of the repository.  Be sure not to skip any steps.  I am using Eclipse Luna, Android SDK 21, and NDK 10d.  You can probably use more recent versions if you like, but those are at least known to work on both Windows and Linux.  Be sure to cd to the tools directory before calling pull-gliden64.sh.

@all - Sorry I can't be more help lately, I'm working long hours at work this week to meet some deadlines.
Title: Re: GLideN64 Android port
Post by: Mikhail on June 04, 2015, 08:19:08 AM
The inventory screen in re2 with gles 2.0 is overlapped multiple times, it also shows an extra slice on the right side border.



(http://i.imgur.com/1CKn0Vo.jpg)
Title: Re: GLideN64 Android port
Post by: Gonetz on June 04, 2015, 10:22:33 AM
@Mikhail GLideN64 does not support RE2. On any platform.
Title: Re: GLideN64 Android port
Post by: Mikhail on June 04, 2015, 11:06:21 AM
We're only posting supported games? ok which?

Shame re2 is almost playable with retroarch glide64 plugin apart from the characters and fmv not showing up,
where as for mupen64ae it shows the characters but backgrounds are broken.
With gles 3.1 the inventory screen appears as normal the same as gln64.

How am I able to use gles 3.1 though on my gles 3.0 device though? it results are more or less the same as gln64
but gles 3.0 doesn't show up anything.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 04, 2015, 11:36:50 AM
I'd prefer all games related bug reports to be in separate thread.
This thread is for solving technical questions regarding to plugin port.
Currently I do not care about problems in games. I care only about problems with devices.
Title: Re: GLideN64 Android port
Post by: retroben on June 04, 2015, 05:09:21 PM
What about the problem that generally happens in every game with size changing and repeating textures?
No need to mention any further,but it eventually needs attention for fixing since it visually breaks some effects like Samus' charge shot in Super Smash Bros. and many other details and projectiles.

I suggest that Mupen64Plus AE's polygon offset hack should be implemented on GLideN64 GLES2 for testing since there is a general issue with see-through stuff that looks identical to other plugins.
These two problems probably affect most if not all GLES2 limited devices.

Also,I am puzzled at an effect GLideN64 has that is missing in all other plugins.
With FBEmulation on,it is crystal clear,even at smallest resolution,while disabling FBEmulation causes the square gridding also found on framebuffered Glide64mk2.
This is only on my FireTV since my tablet has no square gridding on Glide64mk2.

So the question is,how am I getting a crystal clear image in my FireTV on GLideN64 (FBEmulation enabled) when other plugins (like framebuffered Glide64mk2) have square gridding?
(Glide64mk2 has square gridding despite framebuffer being enabled,but logcat gives me unsupported GL_ARB extension errors and Rice has issues then switches to "legacy" mode)

Sorry if I am rambling on and on. ::) :)
Title: Re: GLideN64 Android port
Post by: littleguy on June 04, 2015, 08:54:37 PM
@retroben We should probably start a new thread for the square gridding issue.  Let me see if I can consolidate all your previous posts into a new one.
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 05, 2015, 02:49:42 AM
Got to tryout the last APK on my Shield TV.  The enableColorxxxxx options run near fullspeed on this device, but it's pretty low resolution so it's better kept off for the moment.  Using the es3.1 render, it runs pretty much everything full speed with framebuffers.  Yoshi's Story is full speed without any slowdown like it was on my Shield Tablet. 
Title: Re: GLideN64 Android port
Post by: fzurita on June 05, 2015, 11:37:03 PM
@fzurita - I guess you did something wrong. I have no bin subfolder inside mupen64plus-ae folder
Try again. Remove previous clone of the repository, and clone again. My latest modification is not pulled into the repository, so you may just switch to gliden64-integration and build the project from here. My older apk was built from this point. If it worked for you, then after building the project you also should get version compatible with your Tegra. After that you need to find my commit, which breaks that compatibility. You may clone GLideN64 repository, switch to commit next to e1000ad and copy GLideN64 sources into mupen64plus-ae. Build and test. If it works, switch to next GLideN64 commit and repeat. Thus you will find the wrong commit.

Ok, I finally got it to work. So thinking that the commit that you pointed out (https://github.com/gonetz/GLideN64/commit/16530693298c70e96679dd21574d95f840b5bca8) was the one that broke it, I reverted using Git and rebuilt everything. After doing that everything worked as expected.

So in the end I went through your code before the commit and found the values that you had defined in the GL ES 2.0 macros. This is what I ended up with and it works fine with Tegra 4.

   monochromeInternalFormat = GL_LUMINANCE;
   monochromeFormat = GL_LUMINANCE;
   monochromeType = GL_UNSIGNED_SHORT_5_6_5;
   monochromeFormatBytes = 4;

   colorInternalFormat = GL_RGB;
   colorFormat = GL_RGB;
   colorType = GL_UNSIGNED_SHORT_5_6_5;
   colorFormatBytes = 4;

   depthInternalFormat = GL_DEPTH_COMPONENT;
   depthFormat = GL_DEPTH_COMPONENT;
   depthType = GL_UNSIGNED_INT;
   depthFormatBytes = 4;

Also, one can detect if we are using a Tegra chipset by using this code:

if (strstr((const char *)glGetString(GL_RENDERER), "Tegra") != NULL)

But this doesn't tell you which revision of the Tegra chipset you have. I tried googling around and I couldn't find an easy way to tell the revision.

See the attached OpenGL.cpp file for my final changes.

Also, another thing, Tegra 4 supports many OpenGL 3.0 es features through nvidia extensions to OpenGL 2.0. So, for that stuff that is missing in OpenGL 2.0, it's possible to implement some of it through the extensions (I think). If you can use these extensions in android, I'm sure you can find many equivalent OpenGL 3.0 calls by going through them.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 06, 2015, 07:54:38 AM
@fzurita:

First:
According to this doc:
http://stackoverflow.com/questions/18688057/which-opengl-es-2-0-texture-formats-are-color-depth-or-stencil-renderable

GL_LUMINANCE texture can't be used as color attachment for FBO. I'm sure that monochrome FBOs do not work for you. You may check dynamic shadows in JFG, CBFD or Banjo Tooie.

That is you should use the same parameters for monochrome textures as for color ones:
   monochromeInternalFormat = GL_RGB;
   monochromeFormat = GL_RGB;
   monochromeType = GL_UNSIGNED_SHORT_5_6_5;
   monochromeFormatBytes = 2;

Second:
 colorInternalFormat = GL_RGB;
 means that your Tegra4 chip, which is newer and more powerful than Mali400 can't output 32bit color. I just can't believe it. May be it's not supported in your drivers, but this is weird.
if condition
Code: [Select]
(strstr(extensions, "GL_OES_rgb8_rgba8") != NULL)is true, your Tegra4 supports 32bit color buffers. If this extension is not supported, then you really may use only 16bit RGB.
Title: Re: GLideN64 Android port
Post by: fzurita on June 06, 2015, 10:22:47 AM
@fzurita:

First:
According to this doc:
http://stackoverflow.com/questions/18688057/which-opengl-es-2-0-texture-formats-are-color-depth-or-stencil-renderable

GL_LUMINANCE texture can't be used as color attachment for FBO. I'm sure that monochrome FBOs do not work for you. You may check dynamic shadows in JFG, CBFD or Banjo Tooie.

That is you should use the same parameters for monochrome textures as for color ones:
   monochromeInternalFormat = GL_RGB;
   monochromeFormat = GL_RGB;
   monochromeType = GL_UNSIGNED_SHORT_5_6_5;
   monochromeFormatBytes = 2;

Second:
 colorInternalFormat = GL_RGB;
 means that your Tegra4 chip, which is newer and more powerful than Mali400 can't output 32bit color. I just can't believe it. May be it's not supported in your drivers, but this is weird.
if condition
Code: [Select]
(strstr(extensions, "GL_OES_rgb8_rgba8") != NULL)is true, your Tegra4 supports 32bit color buffers. If this extension is not supported, then you really may use only 16bit RGB.

My OpenGL understanding is quite limited, I only took a very basic class during school. I'll make the changes you suggested and see if it still works fine. Either way, after making those changes I stopped getting a black screen with FBE enabled and the colors looked correct. I'm sure the changes you suggested would make things better.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 06, 2015, 12:01:19 PM
You can build the project and deploy it to the device. That is enough.

So, you found that if you set texture format for color frame buffer to GL_RGB, it works.
If you also will set texture format for monochrome frame buffers to GL_RGB, you will get working dynamic shadows.

However, I want to find a way to make your Tegra4 work with RGBA texture format. This is important for some games, e.g. Lego Racers. With RGB buffer you will get black squares over racers in that game.

Let's make test version of FBOTextureFormats::init()

Code: [Select]
void FBOTextureFormats::init()
{
#ifdef GLES2
monochromeInternalFormat = GL_RGB;
monochromeFormat = GL_RGB;
monochromeType = GL_UNSIGNED_SHORT_5_6_5;
monochromeFormatBytes = 2;

    depthInternalFormat = GL_DEPTH_COMPONENT;
      depthFormat = GL_DEPTH_COMPONENT;
      depthType = GL_UNSIGNED_INT;
      depthFormatBytes = 2;

const char * extensions = (const char *)glGetString(GL_EXTENSIONS);

if (strstr(extensions, "GL_OES_rgb8_rgba8") != NULL) {
LOG(LOG_ERROR, "GL_OES_rgb8_rgba8 supported. Use RGBA color buffer.\n");
colorInternalFormat = GL_RGBA;
colorFormat = GL_RGBA;
colorType = GL_UNSIGNED_BYTE;
colorFormatBytes = 4;
} else {
LOG(LOG_ERROR, "GL_OES_rgb8_rgba8 not supported. Use RGB color buffer.\n");
colorInternalFormat = GL_RGB;
colorFormat = GL_RGB;
colorType = GL_UNSIGNED_SHORT_5_6_5;
colorFormatBytes = 2;
}
#endif
}

What do you use to build the project? Eclipse? Do you know how to open adb log and see device output?
I put log messages to know if GL_OES_rgb8_rgba8 extension is supported.
Please check for that string in the log. It should be printed on rom start.
Title: Re: GLideN64 Android port
Post by: fzurita on June 06, 2015, 09:38:18 PM
You can build the project and deploy it to the device. That is enough.

So, you found that if you set texture format for color frame buffer to GL_RGB, it works.
If you also will set texture format for monochrome frame buffers to GL_RGB, you will get working dynamic shadows.

However, I want to find a way to make your Tegra4 work with RGBA texture format. This is important for some games, e.g. Lego Racers. With RGB buffer you will get black squares over racers in that game.

Let's make test version of FBOTextureFormats::init()

Code: [Select]
void FBOTextureFormats::init()
{
#ifdef GLES2
monochromeInternalFormat = GL_RGB;
monochromeFormat = GL_RGB;
monochromeType = GL_UNSIGNED_SHORT_5_6_5;
monochromeFormatBytes = 2;

    depthInternalFormat = GL_DEPTH_COMPONENT;
      depthFormat = GL_DEPTH_COMPONENT;
      depthType = GL_UNSIGNED_INT;
      depthFormatBytes = 2;

const char * extensions = (const char *)glGetString(GL_EXTENSIONS);

if (strstr(extensions, "GL_OES_rgb8_rgba8") != NULL) {
LOG(LOG_ERROR, "GL_OES_rgb8_rgba8 supported. Use RGBA color buffer.\n");
colorInternalFormat = GL_RGBA;
colorFormat = GL_RGBA;
colorType = GL_UNSIGNED_BYTE;
colorFormatBytes = 4;
} else {
LOG(LOG_ERROR, "GL_OES_rgb8_rgba8 not supported. Use RGB color buffer.\n");
colorInternalFormat = GL_RGB;
colorFormat = GL_RGB;
colorType = GL_UNSIGNED_SHORT_5_6_5;
colorFormatBytes = 2;
}
#endif
}

What do you use to build the project? Eclipse? Do you know how to open adb log and see device output?
I put log messages to know if GL_OES_rgb8_rgba8 extension is supported.
Please check for that string in the log. It should be printed on rom start.

Yes, I'm using Eclipse. I know how to view the adb log and view device output. OK, I'll try this when I get a chance and tell you what it looks like.
Title: Re: GLideN64 Android port
Post by: fzurita on June 07, 2015, 12:54:25 AM
You can build the project and deploy it to the device. That is enough.

So, you found that if you set texture format for color frame buffer to GL_RGB, it works.
If you also will set texture format for monochrome frame buffers to GL_RGB, you will get working dynamic shadows.

However, I want to find a way to make your Tegra4 work with RGBA texture format. This is important for some games, e.g. Lego Racers. With RGB buffer you will get black squares over racers in that game.

Let's make test version of FBOTextureFormats::init()

Code: [Select]
void FBOTextureFormats::init()
{
#ifdef GLES2
monochromeInternalFormat = GL_RGB;
monochromeFormat = GL_RGB;
monochromeType = GL_UNSIGNED_SHORT_5_6_5;
monochromeFormatBytes = 2;

    depthInternalFormat = GL_DEPTH_COMPONENT;
      depthFormat = GL_DEPTH_COMPONENT;
      depthType = GL_UNSIGNED_INT;
      depthFormatBytes = 2;

const char * extensions = (const char *)glGetString(GL_EXTENSIONS);

if (strstr(extensions, "GL_OES_rgb8_rgba8") != NULL) {
LOG(LOG_ERROR, "GL_OES_rgb8_rgba8 supported. Use RGBA color buffer.\n");
colorInternalFormat = GL_RGBA;
colorFormat = GL_RGBA;
colorType = GL_UNSIGNED_BYTE;
colorFormatBytes = 4;
} else {
LOG(LOG_ERROR, "GL_OES_rgb8_rgba8 not supported. Use RGB color buffer.\n");
colorInternalFormat = GL_RGB;
colorFormat = GL_RGB;
colorType = GL_UNSIGNED_SHORT_5_6_5;
colorFormatBytes = 2;
}
#endif
}

What do you use to build the project? Eclipse? Do you know how to open adb log and see device output?
I put log messages to know if GL_OES_rgb8_rgba8 extension is supported.
Please check for that string in the log. It should be printed on rom start.

This code worked fine. And I'm getting this in logcat:

06-07 01:52:22.393: D/GLideN64(23138): GL_OES_rgb8_rgba8 supported. Use RGBA color buffer.

Also, i just realized that this code is identical to Mali 400. i must had done something wrong first time i tried that.
Title: Re: GLideN64 Android port
Post by: retroben on June 07, 2015, 02:21:16 PM
I find it strange that Native resolution (1080P for me) runs sluggishly while setting it to one size below at 960x720 causes a major speed increase.
I have Yoshi Story running at 60fps on 960x720 on zoom with FBEmulation enabled while it was a
pathetically slow 30-20fps or less at Native resolution.

Maybe there is a remedy to fix that Native resolution bottleneck?
Title: Re: GLideN64 Android port
Post by: Gonetz on June 08, 2015, 06:59:00 AM

This code worked fine. And I'm getting this in logcat:

06-07 01:52:22.393: D/GLideN64(23138): GL_OES_rgb8_rgba8 supported. Use RGBA color buffer.

Also, i just realized that this code is identical to Mali 400. i must had done something wrong first time i tried that.

Excellent! Yes, you're right. If GL_OES_rgb8_rgba8 extension is supported, the setup is identical to Mali 400.
Thus, your GPU drivers have the same issue as Mali-400 ones - texture internal format must be the same as texture format in glTexImage2D call. Otherwise texture won't initialize. Actually, this issue is not a problem [have lack of words here]. I mean, if I'll use this code for all GLES2 devices, it should work. I'll make an update asap.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 08, 2015, 07:03:46 AM
I find it strange that Native resolution (1080P for me) runs sluggishly while setting it to one size below at 960x720 causes a major speed increase.
I have Yoshi Story running at 60fps on 960x720 on zoom with FBEmulation enabled while it was a
pathetically slow 30-20fps or less at Native resolution.

Maybe there is a remedy to fix that Native resolution bottleneck?

Do you have speed increase/decrease only with 2D games like Yoshi Story, or with all titles?
Title: Re: GLideN64 Android port
Post by: retroben on June 15, 2015, 11:08:22 PM
Just my luck when the forum went down. ::)

Even Banjo-Tooie is faster with fluid smooth 60fps in Heggy's on GLideN64 while FBEmulation is enabled.
(no frameskip code 8007913F 0001)
It still does go slower on my FireTV when in the same situations as other plugins,such as looking at a large distance.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 16, 2015, 08:52:44 AM
The forum is finally recovered! Great!

I've made few important fixes while it was dawn:
- fixed issues in GLES3.1 shaders. Now my shaders compiled not only on Shield.
- add optimization for read from color frame buffer to RAM, commit 68941f6c
Speed increased circa 4 times and now EnableCopyColorFromRDRAM can be used in some games without noticeable speed drop. Thanks to Lars Bishop from NVidia, who discovered the source of the slowdown in my code and fixed it.

Title: Re: GLideN64 Android port
Post by: retroben on June 16, 2015, 11:11:14 AM
Would this speed increase include GLES2 and despite native resolution bottleneck?

Glad to see you're still here even with all the lost time from the forum being down. ;D
Title: Re: GLideN64 Android port
Post by: Gonetz on June 17, 2015, 05:58:54 AM
No, buffers read disabled for GLES2.
Title: Re: GLideN64 Android port
Post by: retroben on June 17, 2015, 10:41:54 AM
So only in relation to that feature,I see.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 17, 2015, 11:05:57 AM
@Gonetz master won't build on android here's the log ;) 

Code: [Select]
17:59:32 **** Build of configuration Default for project SplashActivity ****
"C:\\Android\\android-ndk-r10e\\ndk-build.cmd" all
Android NDK: WARNING: APP_PLATFORM android-9 is larger than android:minSdkVersion 7 in ./AndroidManifest.xml   
[armeabi-v7a] Install        : libSDL2.so => libs/armeabi-v7a/libSDL2.so
[armeabi-v7a] Install        : libae-exports.so => libs/armeabi-v7a/libae-exports.so
[armeabi-v7a] Install        : libae-imports.so => libs/armeabi-v7a/libae-imports.so
[armeabi-v7a] Install        : libfreetype.so => libs/armeabi-v7a/libfreetype.so
[armeabi-v7a] Install        : libmupen64plus-audio-sdl.so => libs/armeabi-v7a/libmupen64plus-audio-sdl.so
[armeabi-v7a] Install        : libmupen64plus-audio-sles.so => libs/armeabi-v7a/libmupen64plus-audio-sles.so
[armeabi-v7a] Install        : libmupen64plus-core.so => libs/armeabi-v7a/libmupen64plus-core.so
[armeabi-v7a] Install        : libmupen64plus-input-android.so => libs/armeabi-v7a/libmupen64plus-input-android.so
[armeabi-v7a] Install        : libmupen64plus-rsp-hle.so => libs/armeabi-v7a/libmupen64plus-rsp-hle.so
[armeabi-v7a] Install        : libmupen64plus-ui-console.so => libs/armeabi-v7a/libmupen64plus-ui-console.so
[armeabi-v7a] Install        : libmupen64plus-video-glide64mk2.so => libs/armeabi-v7a/libmupen64plus-video-glide64mk2.so
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= 3DMath.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= Combiner.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= CommonPluginAPI.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= Config.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= CRC.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= DepthBuffer.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= F3D.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= F3DDKR.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= F3DEX2CBFD.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= F3DEX2.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= F3DEX.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= F3DPD.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= F3DSWSE.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= F3DWRUS.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= FrameBuffer.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= GBI.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= gDP.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= GLideN64.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= glState.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= gSP.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= Keys.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= L3D.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= L3DEX2.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= L3DEX.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= MupenPlusPluginAPI.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= N64.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= OpenGL.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= PostProcessor.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= RDP.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= RSP.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= S2DEX2.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= S2DEX.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= Textures.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= Turbo3D.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= VI.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= ZSort.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= ShaderUtils.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= CommonAPIImpl_common.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= CommonAPIImpl_mupenplus.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= Config_mupenplus.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= MupenPlusAPIImpl.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= OpenGL_mupenplus.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= TextDrawer.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= UniformSet.cpp
[armeabi-v7a] Compile++ arm  : mupen64plus-video-gliden64-gles20 <= GLSLCombiner_gles2.cpp
jni/./mupen64plus-video-gliden64/src/GLES2/GLSLCombiner_gles2.cpp: In member function 'void ShaderCombiner::_locateUniforms()':
jni/./mupen64plus-video-gliden64/src/GLES2/GLSLCombiner_gles2.cpp:281:16: error: 'struct ShaderCombiner::UniformLocation' has no member named 'uPrimitiveLod'
  LocateUniform(uPrimitiveLod);
                ^
jni/./mupen64plus-video-gliden64/src/GLES2/GLSLCombiner_gles2.cpp:253:13: note: in definition of macro 'LocateUniform'
  m_uniforms.A.loc = glGetUniformLocation(m_program, #A);
             ^
jni/./mupen64plus-video-gliden64/src/GLES2/GLSLCombiner_gles2.cpp: In member function 'void ShaderCombiner::updateLOD(bool)':
jni/./mupen64plus-video-gliden64/src/GLES2/GLSLCombiner_gles2.cpp:435:15: error: 'struct ShaderCombiner::UniformLocation' has no member named 'uPrimitiveLod'
    m_uniforms.uPrimitiveLod.set(gDP.primColor.l, _bForce);
               ^
make.exe: *** [obj/local/armeabi-v7a/objs/mupen64plus-video-gliden64-gles20/./mupen64plus-video-gliden64/src/GLES2/GLSLCombiner_gles2.o] Error 1

18:00:43 Build Finished (took 1m:10s.986ms)

Title: Re: GLideN64 Android port
Post by: Gonetz on June 18, 2015, 01:11:05 AM
Fixed in rev. db38b2f
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 18, 2015, 02:55:56 AM
Thanks ;)

I updated master with latest gliden64 changes.
Title: Re: GLideN64 Android port
Post by: retroben on June 18, 2015, 05:24:44 AM
Conker now has proper model visibility on FBEmulation with GLES2,but the pause menu image doesn't render,it is just solid white background.
Still think polygon offset hack should be made available on GLideN64 to clean up the remaining see-through issues that appear to match when compared to the other plugins.
Title: Re: GLideN64 Android port
Post by: Gonetz on June 18, 2015, 07:54:41 AM
Thanks ;)

I updated master with latest gliden64 changes.
Please update again. I've made important fixes in mip-maping, which affects GLES2 as well.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 18, 2015, 08:52:21 AM
Please update again. I've made important fixes in mip-maping, which affects GLES2 as well.

Done.
Title: Re: GLideN64 Android port
Post by: rocketskates on June 18, 2015, 10:25:34 AM
Hi,

Does anyone have an apk of latest version of mupen with gliden64 built in. I am not a developer and don't know how to build it myself.

Thanks
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 18, 2015, 10:27:14 AM
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/
Title: Re: GLideN64 Android port
Post by: rocketskates on June 18, 2015, 10:46:50 AM
thanks
Title: Re: GLideN64 Android port
Post by: Kam on June 19, 2015, 12:56:21 PM
Hello,

Congratulations to all for your work.

I wonder if it will be possible to play with texture pack with this new plugin ??? For some Zelda pack (Djipi) only work with this plugin (or Glide64). I download the latest version from the link you give and I do not see anywhere to activate the texture pack. This only works with Rice plugin.

Thanking you.
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 19, 2015, 01:06:23 PM
Hello,

Congratulations to all for your work.

I wonder if it will be possible to play with texture pack with this new plugin ??? For some Zelda pack (Djipi) only work with this plugin (or Glide64). I download the latest version from the link you give and I do not see anywhere to activate the texture pack. This only works with Rice plugin.

Thanking you.

Texture packs work with the latest builds with the plugin, but you'll need to copy the default "emulation profile" for GlideN64.  Then you can edit the options to enable Texture Loading.  Also, Glide64 texture packs don't work with the new plugin unless you extract the textures first as the file cache format that GlideN64 supports is different. 

Title: Re: GLideN64 Android port
Post by: Kam on June 19, 2015, 01:15:55 PM
Can you tell me how to extract the textures? I would like to play with Zelda Pack (Cellpack) of Djipi but only work with Glide64.

Another question: The texture pack that works with GLideN64 are the same as those who work with Rice?
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 19, 2015, 03:16:42 PM
Can you tell me how to extract the textures? I would like to play with Zelda Pack (Cellpack) of Djipi but only work with Glide64.

Another question: The texture pack that works with GLideN64 are the same as those who work with Rice?

I'd much rather use the older 2009 Cell OOT pack from Djipi than bother with extracting, but you can find the tutorial on how to extract the .DAT file texture packs here:
http://www.emutalk.net/threads/55257-GUIDE-Extract-dat-Glide64-Texture-Packs

And yes, Rice format texture packs are supported, but there are various issues with textures being the wrong dimensions on some of the packs which make them not load all the textures correctly. 

Here' s a video I made of Banjo Kazooie with HD Textures on GlideN64.
https://www.youtube.com/watch?v=0yyD7d0o8NY
Title: Re: GLideN64 Android port
Post by: Kam on June 19, 2015, 03:57:41 PM
I am unable to activate the HD texture on the emulator. I copy the plugin then I check "txHiresEnable" but I still can not load a texture pack, no option will allow me. Can you give me walking to follow?
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 19, 2015, 04:11:25 PM
Where did you extract your Texture folder?  It needs to be extracted into the following path on Android:

"sdcard\mupen64plusae-v3-alpha\CoreConfig\UserData\mupen64plus\hires_texture"

-5



Title: Re: GLideN64 Android port
Post by: Kam on June 20, 2015, 09:04:34 AM
Yes it is here that I put the texture file. But this is the new texture pack djipi that is made to work with GLideN64.

http://www.emutalk.net/threads/55311-Djipi-Zelda-OOT-2014

Just one file (.htc). But it does not work, no texture loads. Yet it works with Rice texture pack.
Title: Re: GLideN64 Android port
Post by: fivefeet8 on June 20, 2015, 12:13:39 PM
Yes it is here that I put the texture file. But this is the new texture pack djipi that is made to work with GLideN64.

http://www.emutalk.net/threads/55311-Djipi-Zelda-OOT-2014

Just one file (.htc). But it does not work, no texture loads. Yet it works with Rice texture pack.

If it's a Texture Pack in .HTC format, which is basically a "Cache" of textures file, put it in the following directory:

"sdcard\mupen64plusae-v3-alpha\CoreConfig\UserCache\mupen64plus\cache"

For regular file folder Texture packs, they go into the previous directory I posted.  Once the emulator Plugin loads the textures from the folder/files, it caches them into the folder above for faster access in .HTC format. 
Title: Re: GLideN64 Android port
Post by: Kam on June 21, 2015, 10:41:07 AM
thank you,

This in well. A few bug on texture but overall it works. Deeply Official Version (public release) of the emulator with this plugin. Why not activate the possibility of texture pack with Glide64 too.

Again thank you.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 22, 2015, 08:14:30 AM
@Gonetz I opened an issue concerning a GLES2 issue and another one concerning zelda's missing heart ;)

https://github.com/gonetz/GLideN64/issues/586 (https://github.com/gonetz/GLideN64/issues/586)
https://github.com/gonetz/GLideN64/issues/588 (https://github.com/gonetz/GLideN64/issues/588)
Title: Re: GLideN64 Android port
Post by: retroben on June 22, 2015, 12:18:15 PM
The missing heart is different than the Rice issue,it is caused by the major "wrong size texture" issues.
However,another issue is the same as other plugins with the polygon offset,so maybe adding that as an option for GLideN64 would make a difference.

The polygon offset problem is an issue on the emulator's side,as Mupen64Plus in general,or at least the Android one from GLES2 limits.

Is there any way to approach this and fix it for all devices?
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 22, 2015, 01:53:54 PM
The missing heart is different than the Rice issue,it is caused by the major "wrong size texture" issues.

At least the same hack from rice fix the issue in gliden64.
What exactly is the "wrong size texture" issues? Do have screenshots?
Also I don't have any issue with polygon offset on my device. Again do you have screenshots ;)
Title: Re: GLideN64 Android port
Post by: retroben on June 22, 2015, 02:08:22 PM
At least in GLES2 on older/limited devices,the issues is present.

There is a problem with emulator screenshots on GLideN64 that causes them to be solid black,so I will have to use a screenshot app (as I have done before) to get you the screenies.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 22, 2015, 02:19:35 PM
I just double checked the polygon offset issue and I don't have issues because the hardcoded value match the required value for my devices so this explains why it works for me, no need to make a screenshot ::)

A screenshot app is just fine for me BTW ;)
Title: Re: GLideN64 Android port
Post by: retroben on June 22, 2015, 02:29:07 PM
I still want you to see the result of Banjo-Tooie via GLideN64 GLES2 variant on my end.

Meanwhile,two Paper Mario screens,enjoy my orange circle cursor on them.

This first one is nightmare fuel and shows so many things going wrong.

http://www.2shared.com/photo/Fs4HSVA6/Paper_Mari-Oh_No.html

This one is the wrong screen size during Bowser's battle cutscenes...

http://www.2shared.com/photo/tpDS7uno/Paper_Too_Big.html

Finally,my visual of "polygon offset" likeness in Banjo-Tooie,which required keeping the HUD there to prevent the black out screen issue.

http://www.2shared.com/photo/p32PuVC0/Tooie_Polygon_Offset.html

As you can see,it looks identical to what other plugins show if the offset is disabled or wonky.
(at least on my device)
Conker looks even worse with see-through walls.
Also,wall and floor textures along with some elements in many games including Super Smash Bros. and Zelda Ocarina are switching to the wrong size frequently as you move around.
For instance,Zelda Ocarina's HUD button icons are smaller at times.

Edit: I saw the texture uniform issue you posted on Github,and it matches what I see.
I also see this in game select on Banjo-Tooie,yet on the wall texture when starting the Banjo portrait save.
When can a build to test be available?
Maybe the fix also makes all this other stuff render correctly.
Such as the top-left dot in Yoshi's Story that changes size and the Paper Mario speech bubble also has the same kind of issue on the left end.

Most of these seem to be related to the top left corner of the screen,while other visual quirks can happen anywhere and even be triggered by certain actions.
And Super Smash Bros. has model texture alignment oddities where some things go missing and you can see Kirby's face change size and position whenever changing P2's character,the other issue is that stage textures change size whenever you move to make the camera zoom in and out.
The face oddity may be related to the glN64 face issue.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on June 23, 2015, 01:40:09 PM
I just updated master with latest gliden64 fixes.

This issue has been fixed:
https://github.com/gonetz/GLideN64/issues/586

Please test an report :)
Title: Re: GLideN64 Android port
Post by: retroben on June 23, 2015, 02:37:53 PM
Congratulations!

As I expected,all texture size changing quirks including the worst Kirby flipped ones are all fixed up.
Edit: Paper Mario's speech bubble and Star icon work correctly now,and no more nightmare fuel,but the resolution glitch in Bowser's battle cutscenes is still there.

Edit2: Conker's BFD shadows are glitchy at times and normal otherwise,strange how Tooie's shadows are just fine.

Now we know the Zelda Ocarina heart is similar to Rice's issue,or possibly "Polygon Offset" related.
Also,the Zelda aiming cursor is still missing unfortunately.

My suggestion is to first implement the "Polygon Offset" hack on the GLES2 variant to allow fixing see-through and bring the other remaining issues out into the open so they can be fixed more effectively.
No harm doing it since there is an option to disable the hack anyway.
Title: Re: GLideN64 Android port
Post by: Mikhail on June 23, 2015, 04:02:25 PM
Also fixed size issues from
www.paulscode.com/forum/index.php?PHPSESSID=73810299749ceb63a2b2447a0f0afcbc&topic=3163.msg16631#msg16631

The halo outline effect and circle flip texture remains though.

(http://i.imgur.com/hIybeqW.png)
Title: Re: GLideN64 Android port
Post by: Mikhail on June 23, 2015, 06:06:21 PM
(http://i.imgur.com/pm3x6QC.png)
Title: Re: GLideN64 Android port
Post by: retroben on June 24, 2015, 02:58:32 AM
Various games' text font still glitches out when using the 5xBRz enhancement.
This is a different issue.
Title: Re: GLideN64 Android port
Post by: retroben on July 02, 2015, 12:58:50 AM
A new problem with the same blackness issue for Banjo-Tooie.
The screen becomes solid blue when underwater and no HUD items onscreen,even after the warp pad exploit to alleviate the blackness issue.

Not sure if this still happens after the latest changes that have yet to be added to any newer build,as none have been created in a while,but i'd also like to see if there is any global speed increase from that SM64-related tweak mentioned on github.

On a sorta unrelated note,can someone undergo the test of running Banjo-Tooie on Nvidia Android Shield TV
with "no frameskip" (8007913F 0001) and CountPerOp=1 set,and also using Pure Interpreter?
Primarily with Pure Interpreter to see if it STILL runs full speed.
Trying all gfx plugins including all three GLideN64 variants would also be nice.
Checking HailFire Peaks Icy Side's oil rig ledge view would be the highest priority to test performance.
If slow,see how fast it is on Recompiler just to compare it.
Title: Re: GLideN64 Android port
Post by: fivefeet8 on July 02, 2015, 10:05:25 AM
@retroben

I'd be willing to test the game at that spot if you get me a savestate or savegame.  It is a lot slower(half speed mostly) with the Pure Interpreter just in the opening title scenes, but at least the game doesn't crash.  It's full speed with the Recompiler, but the game tends to crash the emulator.  This is with any of the render plugins available using the Recomp.  It gets ingame with the interpreter modes, but it's a lot slower.     
Title: Re: GLideN64 Android port
Post by: Roger Carvalho on July 02, 2015, 12:54:29 PM
Why not link has the android version?
almost every day has alualização the GLideN64 Git fixes for android but do not know where to find ... ???

GLideN64 Git - Update / Changelog:
http://www.emucr.com/search/label/GLideN64?&max-results=12
Title: Re: GLideN64 Android port
Post by: retroben on July 02, 2015, 01:05:47 PM
Wait... is Banjo-Tooie crashing on Android Shield TV?
If it is,that REALLY really sucks. :'(
Perhaps Aarch64 could be the one to blame,or the annoying Lollipop. >:(
Why would the strongest Android device to-date be crashing?
Such a shame if Interpreter still goes slow,even on Nvidia Shield TV,that just proves it needs a major overhaul to greatly increase performance of the RSP/core/emulator itself.

I also replied to "Free Emulator" on YT to ask if he could make a video testing it extensively.

I hope if FireTV gets a custom rom with later Qualcomm drivers and  *sigh* Lollipop,that it doesn't decide to start crashing.
Right now,Banjo-Tooie is crashless on FireTV from my test with new game through all the way to before fighting Weldar,collecting everything possible along the way in one all-nighter non-stop test session.

Would be nice to see more activity on here,but you know,Summer.
I was hoping the Glover games (also Glover 2 Beta) could finally be looked into for fixing on Recompiler.
Maybe I should ask directly on upstream.

@Roger Carvalho: I too wish there was a build with those changes to test the possible speed increase.
Title: Re: GLideN64 Android port
Post by: fivefeet8 on July 02, 2015, 01:30:09 PM
Wait... is Banjo-Tooie crashing on Android Shield TV?
If it is,that REALLY really sucks. :'(
Perhaps Aarch64 could be the one to blame,or the annoying Lollipop. >:(
Why would the strongest Android device to-date be crashing?
Such a shame if Interpreter still goes slow,even on Nvidia Shield TV,that just proves it needs a major overhaul to greatly increase performance of the RSP/core/emulator itself.


To clarify a few things after more testing, the "no frameskip" code you showed above and I was using caused the game to slowdown in general because it was try to render the game at 60 FPS on my Shield ATV.  When I disabled that code, the game ran mostly at full speed(20/30 fps) even with the Interpreter mode.  The game still crashes though even without the code on the Dynarec.
Title: Re: GLideN64 Android port
Post by: retroben on July 02, 2015, 03:21:39 PM
As in slowdown,do you mean that you can hear slowed down music and the resulting crackling and stutter?
Are you sure you are using the right version of the code? (8007913F 0000)
Please try that one above.

I am able to keep it mostly around 25-30fps/60fps with Rice and Dynarec on my x86 tablet on CountPerOp=1 and without crashing.
It should only so much as softlock during cutscenes with the code on.
The whole point was that I wanted to see if it could run at maxed out speeds on Shield TV's Tegra X1 chipset.
How is the performance so underpowered though?
Does this perhaps mean Android/Mupen64Plus AE has reached its global limit?
Maybe it is the same case that various PJ64 versions have,where 1.6 and 1.7(.0.50b23) are slower compared to 2.x which can run Tooie quite a bit faster.
This would mean Mupen64Plus needs certain improvements to combat the sluggishness.

Such a crying shame it is crashing in one of the most desired Android devices.
Hopefully Gillou or anyone else can check this out.

Also,if you are using it,DON'T use auto resume!
It causes the split-up pads to trigger a crash,so you'll have to always hit restart instead.

P. S. you can grab my "funpleted" save file from PJ64 forums and rename it to match the game filename to apply the save,I did this myself so I could use my save dependant "Groggy Cloner" code again.

The post with it...

http://forum.pj64-emu.com/showpost.php?p=53597&postcount=261
Title: Re: GLideN64 Android port
Post by: fivefeet8 on July 02, 2015, 05:18:59 PM
@retroben

When the game slows down, the sound stutters and crackles.  I was using the code "8007913F 0001" before.  Just tried the code you posted, "8007913F 0000" and still the same.  The game slows down with the unlocked FPS, but full speed without sound issues when the code is disabled.  The game seems to normally run at 20 FPS in a lot of places.  If there was a code to keep the FPS at 30 FPS, it should be fine as that is what the frames hover around with the FPS unlocked to 60 FPS.

I'm always restarting the games when I run them.    I'll check out your save file and report back.  Maybe if I have some time, I'll post a video of the game. 
Title: Re: GLideN64 Android port
Post by: retroben on July 02, 2015, 06:38:04 PM
The game actually runs at 30FPS in almost every area,just drops some when CountPerOp rises.
It actually hits 60FPS max naturally in the giant cheese wedge,but if you take damage,it drops to a horrendous 15FPS.
Slow even on Dynarec,or is that causing crashing?
Thanks for testing as I am unable to since the lack of having one of those "beasts".

I still can't wrap my head around the fact it goes slow on that beast. (how is that even possible?)
Any chance you have too much stuff going on in the background like dozens of syncing options or a chance of bloatware?
Maybe there is an unfair clocking limit on Mupen64Plus AE causing any and every device to go slow in that situation.
If true,then it may need more Ghz access on CPU and more Mhz on GPU and maybe also a high priority feature.

I think I just figured it out,maybe it needs an optimized version for Aarch64 architecture in the off-chance that is causing performance issues.

Edit: Try every GFX plugin (Rice is the fastest for Banjo-Tooie) and make sure audio buffer is set to 2048 to maximize performance as a trade-off,it might be a large cause of slowdown if you have it set to a low number.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on July 03, 2015, 09:17:27 AM
I just updated master with latest gliden64 fixes.
Title: Re: GLideN64 Android port
Post by: retroben on July 03, 2015, 12:33:03 PM
Welcome back,thank you. :)

I know this should be asked in upstream,but what do you think about the Glover and Glover 2 dynarec crashing/broken interpreter issues?
The 2.4.4 interpreter runs both perfectly fine while alpha's interpreter has Glover 2 beta's characters frozen in place and uninteractable.
Despite the interpreter issues,GLideN64 actually has the best framerate for Glover 2 in interpreter mode,not just the smoothness but the speed as well.
Dynarec works briefly if you resume,but crashes once you change areas,maybe revealing an easy fix.
Just hoping you wanted to try something for these two games.

Edit: The polygon offset situation is still see through on GLES2 and wondering if the hack will ever be enabled.
(I am guessing by geometry,you meant that Rat Attack game?)

Also,DK64 has the white texture segments issue on the pile of coins in Gloomy Galleon.

http://www.2shared.com/photo/O3CCsm5d/DK64_Coinpile.html
Title: Re: GLideN64 Android port
Post by: Gillou68310 on July 03, 2015, 03:46:03 PM
Sorry retroben I doesn't have much time these days I spend some hours this week working with gonetz in order to improve the gles2 variant of gliden64. Concerning glover games please test it on PC and open an issue upstream if it fails. It will be much easier for me to track core regression  ;)

I'll create a branch for the polygon offset so you can make some experiments.

Also I'll check dk64 on PC to see if it's a gles specific issue. Could you send me a savestate?

I'm out for the weekend so I won't be able to work on the emu until monday.
Title: Re: GLideN64 Android port
Post by: retroben on July 03, 2015, 10:56:53 PM
I'm stuck as well until Sunday or Monday kinda.
Would a Mupen64Plus AE savestate work on PC?
I ask because the PC Mupen64Plus is a major pain to deal with from lack of a GUI,and any other alternate ones with a GUI have no support for DK64.
Title: Re: GLideN64 Android port
Post by: fzurita on July 04, 2015, 11:35:14 PM
I was finally able to get the x86 version of Mupen64plus to work with GLideN64, but the way I did it makes no sense to me.

To get it to work, I had to add the line:
Code: [Select]
LOG(LOG_VERBOSE, "TEST\n");
   

right before

Code: [Select]
triangles.num = 0;

in OpenGL.cpp at void OGLRender::_initData() and then recompile. I tried adding the logging in other places during initialization of the plugin and they seem to work as well. I have tried replacing the LOG line with a various sleep durations and that doesn't seem to work, so it seems to be related to the logging itself.

So, after getting it to work, performance seems to be not that great in the Nexus Player (Power VR 6 GPU). One thing I have noticed so far is that whenever text appears on the screen when talking to NPC in super mario 64, the frame rate drops to less than 10 FPS (estimate). Text appears above an alpha blended box, maybe that operation is slow for some reason in the PowerVR GPU?
Title: Re: GLideN64 Android port
Post by: fzurita on July 04, 2015, 11:54:19 PM
Another thing. On my nvidia shield portable. HW lighting does not seem to be working correctly, see this screenshot:

https://drive.google.com/file/d/0B57Ioy26LWegQ1lrOTNkS250OVE/edit?usp=docslist_api

Also FBE also seems to have issues, see these screenshots:

https://drive.google.com/file/d/0B57Ioy26LWegckdRVEgxX2pGVEk/edit?usp=docslist_api
https://drive.google.com/file/d/0B57Ioy26LWega0w1N1JhTm5fMmc/edit?usp=docslist_api
Title: Re: GLideN64 Android port
Post by: Gillou68310 on July 05, 2015, 03:53:09 AM
Which gles version are you using on your shield?

Zelda subscreen FB issue will be fixed as soon as this pull request will be merged:
https://github.com/mupen64plus/mupen64plus-core/pull/125

I think the second issue is caused by copyfromrdram option, try disabling it.

Also thanks for opening an issue for the x86 problem ;)
Title: Re: GLideN64 Android port
Post by: Metalmusic3000 on July 05, 2015, 06:07:00 AM
I have a missing texture issue on goldeneye gles 2 the soldures guns are missing textures everything else works fine
Title: Re: GLideN64 Android port
Post by: fzurita on July 05, 2015, 06:09:42 AM
Which gles version are you using on your shield?

Zelda subscreen FB issue will be fixed as soon as this pull request will be merged:
https://github.com/mupen64plus/mupen64plus-core/pull/125

I think the second issue is caused by copyfromrdram option, try disabling it.

Also thanks for opening an issue for the x86 problem ;)

The shield uses GL ES 2.0. By second issue, do you mean third screenshot? Also, no problem in opening up the issue on the x86 problems.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on July 05, 2015, 07:16:57 AM
Quote
By second issue, do you mean third screenshot?

Yes I do.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on July 05, 2015, 07:18:58 AM
Metalmusic enable frambuffer emulation. This fixed the issue for me.
Title: Re: GLideN64 Android port
Post by: Metalmusic3000 on July 05, 2015, 10:26:21 AM
Enabled framebuffer emulation on shield portable no effect on soldures guns what settings besides fbe are you using gillou
Title: Re: GLideN64 Android port
Post by: Gillou68310 on July 05, 2015, 03:25:30 PM
Metalmusic sorry I misunderstood your issue. I also have the soldures guns. I'll take a look at it this week!
Title: Re: GLideN64 Android port
Post by: retroben on July 05, 2015, 06:13:49 PM
Should I test the GL Context build of July 3rd with GLideN64 on my x86 Acer Iconia tablet to see if it runs?
Title: Re: GLideN64 Android port
Post by: fzurita on July 05, 2015, 09:34:56 PM
Should I test the GL Context build of July 3rd with GLideN64 on my x86 Acer Iconia tablet to see if it runs?

Gonetz hasn't checked in the x86 build fix yet.
Title: Re: GLideN64 Android port
Post by: fzurita on July 05, 2015, 11:54:57 PM
Hmmm. Is there an easy way to get a core dump or back trace out of ndk code? I'm getting a crash on x86 when enabling EnableN64DethCompare in GLideN64.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on July 06, 2015, 03:02:07 AM
@Metalmusic the soldures guns issue is also present on PC so I recommend opening on issue here: https://github.com/gonetz/GLideN64/issues (https://github.com/gonetz/GLideN64/issues)

Quote
Would a Mupen64Plus AE savestate work on PC?
@retroben yes of course!

Quote
Another thing. On my nvidia shield portable. HW lighting does not seem to be working correctly
@fzurita this is probably a driver issue with shaders because everything's fine on my device.
Title: Re: GLideN64 Android port
Post by: Gillou68310 on July 06, 2015, 07:31:38 AM
@retroben the polygon offset branch has been pushed ;)
Title: Re: GLideN64 Android port
Post by: retroben on July 06, 2015, 01:00:48 PM
Okay. :)

The savestate for DK64 like you asked...

http://www.2shared.com/file/wBGjBGeg/DK64_coin_stack.html

Edit: As I expected,there is no longer any sign of wall see-through with the polygon offset hack enabled.
I tried Banjo-Tooie,DK64,and Conker and their walls now look just fine.

What would really be great is if this general polygon offset problem (affects all GFX plugins) could now actually be fixed in a way that makes it no longer need any hacks.
Though I wouldn't expect that to happen,I can only hope it is at least possible and that there is a chance a fix could be found.

...
Now I can confirm the GLideN64 Conker's BFD shadow issues relate to a plugin issue.
Conker's shadow is clipping through the ground in several instances while some spots have a perfect shadow.
The earliest time seeing it is the main chainsaw intro where the shadow is glitchy the entire time.
Title: Re: GLideN64 Android port
Post by: retroben on July 07, 2015, 01:39:22 PM
In case it was neglected (by me),Conker BFD's pause screen is missing and solid white with rainbow sparkle edges.
As usual,noticed on the GLES2 variant since I can't access the others.

I used the multiplayer Heist to test.
Good news is the respawn lighting in multiplayer mode is working,but I think the red lighting for damage might be missing,or maybe I am just stupid and didn't do the right action to trigger it.

Also,I saw the aiming issue where the other players are invisible when 1st person aiming the bazooka.
I thought this one was fixed,unless it is a regression or it (regression) is caused by Android.

Oh yeah,Zelda Ocarina now has the targeting cursor since that Z-axis fix has been done for the missing heart.
Title: Re: GLideN64 Android port
Post by: Mikhail on July 07, 2015, 03:13:57 PM
Was the offest patch pushed to the recent RetroArch release with the new xmb interface?
I have no idea how to set the offset units, how do test for it?, for the offeset factor I used the
Mario64 tree shadows. The lateset release has broken a few things various missing textures etc and re2 now instantly crashes on boot.
Title: Re: GLideN64 Android port
Post by: retroben on July 14, 2015, 12:36:09 PM
My results on my x86 device are good now,thanks.

Now for the status,Banjo-Tooie has the black screen issue like my FireTV,which must mean the other issues are also there.
How is this issue going to be handled?
One version that broke Conker was the one that didn't have a black screen issue on Tooie.

Furthermore,will the SM64 hack texture issue ever be fixed?
You could always add another feature to toggle for using a different texture handling method that works for these hacks,such as replicating Glide64's method.
Title: Re: GLideN64 Android port
Post by: retroben on July 26, 2015, 12:05:56 AM
Both debug versions of Majora's Mask and Zelda OOT have major issues with the required color to and from RDRAM.
While "copy color to rdram" works fine and fixes the pause delay,the "copy color from rdram" is not so lucky.

I got a rather bizarre screenshot of Hyrule castle's entrance area being solid black with Lin's pause model at the top-right corner.
Apart from that,there is a white square on the button display and the whole screen goes white when pressing a button because of the debug HUD showing the button pressed.
And IMO the worst part (even without the RDRAM copies) is that the level select menu is entirely unreadable and just solid colors,making it impossible to read what area you are in.
(I can't read Japanese,but some things have numbers)

A weird screenshot.

http://www.2shared.com/photo/pYc9jjHr/Zelda_OOT__U__Master_Quest_Deb.html

Edit: It seems it could be related to github issue #617 like Superman 64,but I am not entirely sure.
Title: Re: GLideN64 Android port
Post by: rocketskates on August 03, 2015, 07:51:58 AM
Hi chaps,

I have an LG G3 with the latest build of mupen and I struggling to get games to work.

Is there a compatibility list anywhere or any specific settings i need to change to use gliden64 effectively?

Looks like only a nexus 9 tablet does the trick.

Thanks
Title: Re: GLideN64 Android port
Post by: fzurita on August 03, 2015, 08:33:29 AM
Hi chaps,

I have an LG G3 with the latest build of mupen and I struggling to get games to work.

Is there a compatibility list anywhere or any specific settings i need to change to use gliden64 effectively?

Looks like only a nexus 9 tablet does the trick.

Thanks

GLideN64 has compatibility issues with Adreno GPUs. If you disable frame buffer emulation they go away.
Title: Re: GLideN64 Android port
Post by: rocketskates on August 03, 2015, 09:39:42 AM
I can't see an option to disable frame buffer?

Thanks
Title: Re: GLideN64 Android port
Post by: retroben on August 03, 2015, 01:00:14 PM
What version of Adreno do you even have? (possibly searchable via "device name specs" on Google)
No running issues on my end with framebuffer,but as Adreno 320,I am on JellyBean via FireTV.
Unless you mean sluggish framerates,which requires you to pick a fairly small resolution like 640x480 to get better speeds with FBEmulation on GLideN64.
The performance issue (at least the GLES2 variant) is actually caused by the sheer quality GLideN64 provides with FBEmulation enabled,where all other plugins have that ugly square gridding (which ruins the 3D depth perception) if used on a TV.
Even my Intel x86 tablet (not Adreno obviously) with normal Glide64 showed signs of gridding,but the squares are only a fourth the size of what the FireTV renders.

Also,I do hope the Color To and From RDRAM can both be fixed since they make Zelda OOT run better with the faster pause menu and Link's pause model.
If only all of the other plugins could have these two features added,as they don't impact performance somehow.
I love how amazing supported games look with HW Lighting enabled.
Title: Re: GLideN64 Android port
Post by: fzurita on August 03, 2015, 03:23:22 PM
What version of Adreno do you even have? (possibly searchable via "device name specs" on Google)
No running issues on my end with framebuffer,but as Adreno 320,I am on JellyBean via FireTV.
Unless you mean sluggish framerates,which requires you to pick a fairly small resolution like 640x480 to get better speeds with FBEmulation on GLideN64.
The performance issue (at least the GLES2 variant) is actually caused by the sheer quality GLideN64 provides with FBEmulation enabled,where all other plugins have that ugly square gridding (which ruins the 3D depth perception) if used on a TV.
Even my Intel x86 tablet (not Adreno obviously) with normal Glide64 showed signs of gridding,but the squares are only a fourth the size of what the FireTV renders.

Also,I do hope the Color To and From RDRAM can both be fixed since they make Zelda OOT run better with the faster pause menu and Link's pause model.
If only all of the other plugins could have these two features added,as they don't impact performance somehow.
I love how amazing supported games look with HW Lighting enabled.

I have an XPeria Z Ultra which has an Adreno 330. Maybe the driver version in my phone is outdated. Frame rate in OpenGL ES 3.0 is actually pretty good for me. The only issue I have is that the viewport is cropped too small when FBE is enabled. So I see only a small portion of the game right in the middle.

I do have terrible performance issues in OpenGL ES 3.1 on my Nexus player which has a PowerVR Rogue Series6 GPU.

I think I'm going to try to tackle the viewport issue next. I may be able to come up with the fix, at least I think I see in the code where the issue is happening.
Title: Re: GLideN64 Android port
Post by: retroben on August 03, 2015, 11:25:12 PM
*snickers* The FireTV drivers are ancient! ;D ...  :'(
It says V@15.0 from PPSSPP's information details.

The lowest should have been V@66.0 while the newest one is really wanted more.
I'd like to have V@95.0 or later on FireTV for superb performance along with less "overheating" issues.
(massive heat sink prevents overheating,yet kernel panic reset triggered by Reicast and heavy 3D three.js games)
Title: Re: GLideN64 Android port
Post by: Metalmusic3000 on August 08, 2015, 12:41:29 PM
How good will emulation be for the w3d i think it has gles es 3.1 iam looking to upgrade to something better than the shield portable any opinion will be appreciated
Title: Re: GLideN64 Android port
Post by: fivefeet8 on August 10, 2015, 12:48:37 PM
How good will emulation be for the w3d i think it has gles es 3.1 iam looking to upgrade to something better than the shield portable any opinion will be appreciated

Are you talking about the Snail Mobile W3D Gaming Phone?
Title: Re: GLideN64 Android port
Post by: Metalmusic3000 on August 10, 2015, 02:08:47 PM
Yes that's it
Title: Re: GLideN64 Android port
Post by: fivefeet8 on August 10, 2015, 02:44:43 PM
Yes that's it

It's running on a ImagineTech PowerVR 6xxx GPU with only 2 cores.  I'm not sure, but from the reviews I've seen, that makes it on par with a Snapdragon 320 GPU.  Unfortunately, that doesn't bode well for it's performance in GlideN64 which seems to have issues with PowerVR devices. 

http://gliden64.blogspot.com/2015/06/android-port-current-results.html

"Currently the main problem is performance. GL ES 2.0 devices are too week to run GLideN64 full speed. Performance depends on GPU. Mali-400 devices work not bad, some games run full speed. PowerVR GPU has slide show performance. GL ES 3 devices usually run full speed." - Gonetz

I guess depending on the quality of drivers for OpenGL es3, you may get decent performance.  I'm actually curious as well about PowerVR devices as I don't have one to test with.
Title: Re: GLideN64 Android port
Post by: Metalmusic3000 on August 10, 2015, 06:01:32 PM
What chipsets run gliden64 the best
Title: Re: GLideN64 Android port
Post by: fivefeet8 on August 11, 2015, 09:30:54 AM
What chipsets run gliden64 the best

Nvidia Tegra devices.  They have better drivers than the other SOCs.  Unfortunately, the newer Tegra K1/X1 chips aren't in phone devices. 
Title: Re: GLideN64 Android port
Post by: fzurita on August 11, 2015, 09:49:39 AM
What chipsets run gliden64 the best

Nvidia Tegra devices.  They have better drivers than the others SOCs.

Also, the Tegra 4 is limited to only OpenGL ES 2.0. So the full feature set of GLideN64 is not available.
Title: Re: GLideN64 Android port
Post by: Metalmusic3000 on August 11, 2015, 05:43:56 PM
I kind of figured it was tegra hopefully rumors of the shield portable 2 are true new info just surfaced in the nvidia portable forum a portable has been approved by the fcc pics wont be released till oct 8
Title: Re: GLideN64 Android port
Post by: retroben on August 13, 2015, 12:05:13 AM
Both debug versions of Majora's Mask and Zelda OOT have major issues with the required color to and from RDRAM.
While "copy color to rdram" works fine and fixes the pause delay,the "copy color from rdram" is not so lucky.

A screenshot of Hyrule castle's entrance area being solid black with Link's pause model at the top-right corner.
Also a white square on the button display and the whole screen goes white when pressing a button because of the debug HUD showing the button pressed.
And IMO the worst part (even without the RDRAM copies) is that the level select menu is entirely unreadable and just solid colors,making it impossible to read what area you are in.
(I can't read Japanese,but some things have numbers)

A weird screenshot.

http://www.2shared.com/photo/pYc9jjHr/Zelda_OOT__U__Master_Quest_Deb.html

Really think this should get some attention please. :)
It may also happen in the normal versions.
The Debug versions are really fun to mess with,you can't initially do as much until modding the config to allow 4 players and using a blank input profile on the three to enable those slots so you can use debug movement and the level select menu plus other features.
Thanks for the option to stop the reminder for multiplayer controller selection,allowing me to leave the other three empty.

Edit: It does happen in Zelda OOT 1.0 as well,meaning this should be considered a high priority problem.

Really bummed out at the severe lack of activity in the past few weeks. :(
Title: Re: GLideN64 Android port
Post by: retroben on August 22, 2015, 04:31:27 PM
Another random Banjo-Tooie lag test for you Nvidia Shield Android TV owners out there.

http://www.2shared.com/file/8BMSrPSt/lag_60fps_clonezooie.html

Place the file in /mupen64plusae-v3-alpha/GameData/BANJO TOOIE (U)/UserSaves and load it to see how it runs.
The "no frameskip" (60fps) and "lag fix" codes are enabled for maximum smoothness,and of course the clone code.
It is in HailFire Peaks (Icy Side) with 7 Kazooie clones and yourself looking at the distant surroundings of the oil rig ledge.

On my FireTV (OS 3),I get a mere 05fps with the clones and not much better without them.

The codes used are these...

No Frameskip and Lag Fix
8003F4F2 000D
D0081084 0008
8003F4F2 0002
D207913F 0000
8007913F 0001

Kazooie Cloner
800F9D87 000F
Clockwork egg destruction triggers cloning.

You can also leave through the door to get rid of the clones to check your speed in the same spot without them.
Title: Re: GLideN64 Android port
Post by: rocketskates on August 23, 2015, 12:06:36 PM
-

Title: Re: GLideN64 Android port
Post by: retroben on August 23, 2015, 12:42:07 PM
Y U NO have post anymore!?! (Troll: yuhhhhhh yuh yuh yuh ahh ahh ahhhhhh ahhhh ah ah)

Nice! I know Dolphin now runs awesomely with Brawl on Nvidia Shield Android TV being showcased full speed 60fps with perfect graphics,minus the green results image,but no more distorted character models.

The autobuild page to get the latest build...

www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/

Code: [Select]
I personally think someone should throw together an easy guide with images for Mupen64Plus AE's interface.

There's two modes for settings,it starts on auto,and the two are standard and big-screen mode.
There is a profile system that you can either pick a pre-existing one if you have the controller for it,or make your own custom one.
The graphics profile,you can copy the premade ones to make custom copies for changing settings.

The main thing to try the lag test with is GLideN64's 2.0 variant with reolution set to 640x480 and "zoom" scale for maximum performance,as Native resolution is really slow from framebuffer strain,but this resolution still looks good.
If you still end up with slowdown,then that means it is definitely the emulator itself actually being too slow.
If it is not slowing down,then awesome,but then you could try the Native resolution to see how badly it can impact performance.

You can even use enhacnement 13 for 6xBRZ in the latest build,it still runs really well,but one minor visual issue with text.
All letters "i" are glitched out as well as periods "." while other shaders have different text glitching.
Hopefully Gonetz or fzurita can fix this issue.

The other fast one is Rice with custom settings to choose the "first CI" render type in the settings.
Fast because less CPU usage,no shadows on Banjo though.

Still,please anyone with "Nvidia Shield Android TV" try this lag test and write back your framerate or mention whether it is slowing down or not.
Title: Re: GLideN64 Android port
Post by: retroben on August 24, 2015, 02:42:47 AM
A really frustrating issue,Conker doesn't like it when I use native resolution with GLideN64,it makes everything creepily see-through again. Using both 640x480 AND 960x720 works fine. I wanted to see the full beauty of 6xBRZ,but the scaling glitch exclusive to Conker is ruining it for me. :-( Can maybe someone add a pickable 1080 resolution?
Maybe this and a few other issues like the enhancements having garbled text will get sorted out soon.

Still really hoping for a nice person with an "Nvidia Shield Android TV" to try the Banjo-Tooie lag test I posted and report back the results if it slowed down or not.
This is a selling point for me to attempt buying one for myself,even though Dolphin emulator at full speed is already more than enough of a reason to get one.
Title: Re: GLideN64 Android port
Post by: fzurita on August 24, 2015, 09:57:57 AM
A really frustrating issue,Conker doesn't like it when I use native resolution with GLideN64,it makes everything creepily see-through again. Using both 640x480 AND 960x720 works fine. I wanted to see the full beauty of 6xBRZ,but the scaling glitch exclusive to Conker is ruining it for me. :-( Can maybe someone add a pickable 1080 resolution?
Maybe this and a few other issues like the enhancements having garbled text will get sorted out soon.

Still really hoping for a nice person with an "Nvidia Shield Android TV" to try the Banjo-Tooie lag test I posted and report back the results if it slowed down or not.
This is a selling point for me to attempt buying one for myself,even though Dolphin emulator at full speed is already more than enough of a reason to get one.

I don't think Gonetz has posted his changes to support 6xBRZ.
Title: Re: GLideN64 Android port
Post by: fivefeet8 on August 24, 2015, 10:07:04 AM
@retroben

I took your save and got the following results with my Shield TV:

8 FPS with the duplicates
15 FPS when looking down without them

I had to use Interpreter mode for the r300 emulation though.  The game still crashes with it otherwise.  This is with the latest dev build.
Title: Re: GLideN64 Android port
Post by: retroben on August 24, 2015, 01:08:39 PM
Why did it crash?!?
Unless my FireTV is just that lucky to run it on Recompiler crashless.
Maybe it is some BS from Lollipop and/or Aarch64 causing it,if so,it needs some compatibility fixes or an extra version dedicated to that architecture type even though ARMv7 is supported.
Well,that kinda stinks,hope we can reach out to Gillou to see if he can look through it and try to get it universally fixed for more Android devices.
I am really curious about the framerate if Recompiler worked.

@fzurita: But it had beautiful visuals on enhancement #13 with a different text garble compared to #12's 5xBRZ.
Plus,I looked at the autobuild changes and saw the 6xBRZ in green.
The 5xBRZ has all letters jumbled up while 6xBRZ only has "i" and "." garbled with yellow area text looking flawless.
The Conker issue happens regardless of enhancement,even without any,I had just forgotten about how it happens since an older build.
Title: Re: GLideN64 Android port
Post by: fzurita on August 24, 2015, 05:04:57 PM
OK, I guess it must be there then. In the past where i looked, it wasn't there. Gonetz must had not added it to every part of the code.
Title: Re: GLideN64 Android port
Post by: retroben on August 25, 2015, 01:04:47 AM
My response of a github reply about async...
I am curious if GLideN64's old async buffer method could be faster on Android as well.
It is normally not there because of issues,but having it with games that don't have issues with it would be nice.
Especially if it makes the plugin even faster than all of the other ones and fixes the "Native resolution" slowdown.
Title: Re: GLideN64 Android port
Post by: retroben on September 04, 2015, 12:59:47 PM
Man,this forum is really lonely. :(

I really want the screenshot feature to be fixed for GLideN64.
You may have to change the method to a similar one that screenshot apps use.
I use "Screenshot Easy" on GLideN64 currently,b​ut the cursor and black borders always appear when taking screenshots​.
I want clean screenshots so I can take images of my Banjo-Tooie "artwork" codes in 1080P HD so I can post them in the Banjo's Backpack forum.
Other plugins have that pixel mesh around the entire game screen,ruin​ing the quality.

I really want this for the max quality images I can get from it,so please try to fix it. :)

Edit: I have another GLideN64 issue in Paper Mario.

In the Shy Guy Toy Box,when you enter the room where the screaming Shy Guys ran to,it is black and white,but the HUD and the menus are invisible,and when I exit the room,it is still black and white until I use Goombario's Tattle out of battle. (heh,it rhymes)

Please see this,Gonetz.

Edit2: It is supposed to be solid black darkness with a small circle on Mario,it works properly on Glide64mk2.
Goombario says it is dark when using Tattle.
Title: Re: GLideN64 Android port
Post by: SuperL on September 11, 2015, 11:29:11 AM
I can't get this to work at all on my new x86 Android tablet. No picture, no sound no nothing. The device is Lollipop.

I've seen other people who've had this problem and fixed it, but I don't know how to do it for myself. What do I do?

https://github.com/gonetz/GLideN64/issues/604
Title: Re: GLideN64 Android port
Post by: ganons on November 29, 2015, 09:47:02 AM
I'd much rather use the older 2009 Cell OOT pack from Djipi than bother with extracting

Whats the difference between 2009 and 2011? Surely 2011 must be better and updated
Title: Re: GLideN64 Android port
Post by: fivefeet8 on December 03, 2015, 01:21:17 PM
I'd much rather use the older 2009 Cell OOT pack from Djipi than bother with extracting

Whats the difference between 2009 and 2011? Surely 2011 must be better and updated

The textures are sometimes slightly different, but it all comes down to preferences I think.  I played almost the entire game with the 2009 version and it was just as excellent as the 2011 version.