Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - fzurita

Pages: 1 ... 26 27 [28]
406
General Discussion / Re: GLideN64 Android port
« 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.

407
General Discussion / Re: GLideN64 Android port
« 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.

408
General Discussion / Re: GLideN64 Android port
« 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.

409
General Discussion / Re: GLideN64 Android port
« 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?

410
General Discussion / Re: GLideN64 Android port
« 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.

411
General Discussion / Re: GLideN64 Android port
« 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

412
General Discussion / Re: GLideN64 Android port
« 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.

413
General Discussion / Re: GLideN64 Android port
« 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

414
General Discussion / Re: GLideN64 Android port
« 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.

 

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.

415
General Discussion / Re: GLideN64 Android port
« 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?

416
General Discussion / Re: GLideN64 Android port
« 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.

417
General Discussion / Re: GLideN64 Android port
« 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

418
General Discussion / Re: 3.0 Alpha Testing
« on: April 24, 2015, 04:45:38 PM »
@scorpio - Stick with Alpha 19 for now - the autobuild versions are experimental, and the ActionBar is one of the things that is being redesigned/replaced in the April 20 build.

One thing you might try doing is to copy/create a new controller profile, and map the menu and/or back buttons.  The menu button should allow you to toggle the ActionBar in the game.  Or are you having an issue with the ActionBar in the front-end screens?

I'm personally having issues with the actionbar at the front-end screen. I looked at scorpio's video and mine doesn't seem to get that far. Also, I'm running the alpha 19 version.

419
General Discussion / Re: 3.0 Alpha Testing
« on: April 16, 2015, 11:45:41 PM »
Hello, I'm having some strange issues with the nexus player. I can't seem to get the action bar to show up, so there is no way to change settings or scan for games. Is there something obvious I'm missing?

Pages: 1 ... 26 27 [28]