Author Topic: GLideN64 Android port  (Read 123314 times)

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 558
    • View Profile
Re: GLideN64 Android port
« Reply #300 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?
« Last Edit: June 04, 2015, 01:21:51 AM by fzurita »

Offline Gonetz

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

Offline Gonetz

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

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.

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 558
    • View Profile
Re: GLideN64 Android port
« Reply #303 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.

Offline littleguy

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

Offline Mikhail

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



« Last Edit: June 04, 2015, 08:42:49 AM by Mikhail »

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #306 on: June 04, 2015, 10:22:33 AM »
@Mikhail GLideN64 does not support RE2. On any platform.

Offline Mikhail

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

Offline Gonetz

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

Offline retroben

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

Offline littleguy

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

Offline fivefeet8

  • byte
  • *
  • Posts: 40
    • View Profile
Re: GLideN64 Android port
« Reply #311 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. 

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 558
    • View Profile
Re: GLideN64 Android port
« Reply #312 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.
« Last Edit: June 05, 2015, 11:40:31 PM by fzurita »

Offline Gonetz

  • Developer
  • long
  • *****
  • Posts: 104
    • View Profile
Re: GLideN64 Android port
« Reply #313 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.
« Last Edit: June 06, 2015, 10:04:21 AM by Gonetz »

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 558
    • View Profile
Re: GLideN64 Android port
« Reply #314 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.
« Last Edit: June 06, 2015, 10:25:31 AM by fzurita »