GLideN64 Android port

[Gonetz]

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.

[xperia64]

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.

[littleguy]

@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

[Gonetz]

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.

[littleguy]

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.

[Gillou68310]

I may have some free times in the following weeks, I would be happy to help integrating gliden64 in the android branch.

[littleguy]

@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

[Gonetz]

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.

[Gonetz]

One more question: I checked project file for Glide64 port. GlideHQ texture library is disabled. Why? Is it possible to build Boost for Android?

[littleguy]

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 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 thread in case you're curious.)

[littleguy]

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

[retroben]

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.

[Gonetz]

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.

[Gillou68310]

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

I will try to build it and report any issues I came across

[Gillou68310]

@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.