GLideN64 Android port

[fivefeet8]

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

[retroben]

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.

[psberitz]

hello maybe it is connected with this issue
newbielink:https://github.com/gonetz/GLideN64/issues/563 [nonactive]

[littleguy]

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

[fzurita]

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

[Gonetz]

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

[Gonetz]

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

[Gillou68310]

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.

[fzurita]

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

[fzurita]

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

[Gonetz]

@ 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

[Gonetz]

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.

[fzurita]

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

[Gillou68310]

@gonetz I removed the glesv1 dependency on SDL2 library. I hope it will help:
https://github.com/Gillou68310/mupen64plus-ae/commit/5b9257c78c6ffa091ac23dba0517e0b33e3791b6

[Gillou68310]

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.