Author Topic: GLideN64 Android port  (Read 141037 times)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #180 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.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #181 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.)
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #182 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.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #183 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.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #184 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.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #185 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.
« Last Edit: May 22, 2015, 03:08:29 PM by retroben »

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #186 on: May 22, 2015, 11:31:48 AM »
@retroben ok, thanks!

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #187 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.

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #188 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.
« Last Edit: May 22, 2015, 12:48:53 PM by Gonetz »

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #189 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.
« Last Edit: May 22, 2015, 02:23:35 PM by retroben »

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: GLideN64 Android port
« Reply #190 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.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #191 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?
« Last Edit: May 23, 2015, 08:48:51 AM by Gonetz »

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #192 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.

Offline Gillou68310

  • Developer
  • long
  • *****
  • Posts: 112
    • View Profile
Re: GLideN64 Android port
« Reply #193 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.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: GLideN64 Android port
« Reply #194 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. :-\