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 - Gonetz

Pages: [1]
1
General Discussion / Re: GLideN64 Android port
« on: June 18, 2015, 07:54:41 AM »
Thanks ;)

I updated master with latest gliden64 changes.
Please update again. I've made important fixes in mip-maping, which affects GLES2 as well.

2
General Discussion / Re: GLideN64 Android port
« on: June 18, 2015, 01:11:05 AM »
Fixed in rev. db38b2f

3
General Discussion / Re: GLideN64 Android port
« on: June 17, 2015, 05:58:54 AM »
No, buffers read disabled for GLES2.

4
General Discussion / Re: GLideN64 Android port
« on: June 16, 2015, 08:52:44 AM »
The forum is finally recovered! Great!

I've made few important fixes while it was dawn:
- fixed issues in GLES3.1 shaders. Now my shaders compiled not only on Shield.
- add optimization for read from color frame buffer to RAM, commit 68941f6c
Speed increased circa 4 times and now EnableCopyColorFromRDRAM can be used in some games without noticeable speed drop. Thanks to Lars Bishop from NVidia, who discovered the source of the slowdown in my code and fixed it.


5
General Discussion / Re: GLideN64 Android port
« on: June 08, 2015, 07:03:46 AM »
I find it strange that Native resolution (1080P for me) runs sluggishly while setting it to one size below at 960x720 causes a major speed increase.
I have Yoshi Story running at 60fps on 960x720 on zoom with FBEmulation enabled while it was a
pathetically slow 30-20fps or less at Native resolution.

Maybe there is a remedy to fix that Native resolution bottleneck?

Do you have speed increase/decrease only with 2D games like Yoshi Story, or with all titles?

6
General Discussion / Re: GLideN64 Android port
« on: June 08, 2015, 06:59:00 AM »

This code worked fine. And I'm getting this in logcat:

06-07 01:52:22.393: D/GLideN64(23138): GL_OES_rgb8_rgba8 supported. Use RGBA color buffer.

Also, i just realized that this code is identical to Mali 400. i must had done something wrong first time i tried that.

Excellent! Yes, you're right. If GL_OES_rgb8_rgba8 extension is supported, the setup is identical to Mali 400.
Thus, your GPU drivers have the same issue as Mali-400 ones - texture internal format must be the same as texture format in glTexImage2D call. Otherwise texture won't initialize. Actually, this issue is not a problem [have lack of words here]. I mean, if I'll use this code for all GLES2 devices, it should work. I'll make an update asap.

7
General Discussion / Re: GLideN64 Android port
« on: June 06, 2015, 12:01:19 PM »
You can build the project and deploy it to the device. That is enough.

So, you found that if you set texture format for color frame buffer to GL_RGB, it works.
If you also will set texture format for monochrome frame buffers to GL_RGB, you will get working dynamic shadows.

However, I want to find a way to make your Tegra4 work with RGBA texture format. This is important for some games, e.g. Lego Racers. With RGB buffer you will get black squares over racers in that game.

Let's make test version of FBOTextureFormats::init()

Code: [Select]
void FBOTextureFormats::init()
{
#ifdef GLES2
monochromeInternalFormat = GL_RGB;
monochromeFormat = GL_RGB;
monochromeType = GL_UNSIGNED_SHORT_5_6_5;
monochromeFormatBytes = 2;

    depthInternalFormat = GL_DEPTH_COMPONENT;
      depthFormat = GL_DEPTH_COMPONENT;
      depthType = GL_UNSIGNED_INT;
      depthFormatBytes = 2;

const char * extensions = (const char *)glGetString(GL_EXTENSIONS);

if (strstr(extensions, "GL_OES_rgb8_rgba8") != NULL) {
LOG(LOG_ERROR, "GL_OES_rgb8_rgba8 supported. Use RGBA color buffer.\n");
colorInternalFormat = GL_RGBA;
colorFormat = GL_RGBA;
colorType = GL_UNSIGNED_BYTE;
colorFormatBytes = 4;
} else {
LOG(LOG_ERROR, "GL_OES_rgb8_rgba8 not supported. Use RGB color buffer.\n");
colorInternalFormat = GL_RGB;
colorFormat = GL_RGB;
colorType = GL_UNSIGNED_SHORT_5_6_5;
colorFormatBytes = 2;
}
#endif
}

What do you use to build the project? Eclipse? Do you know how to open adb log and see device output?
I put log messages to know if GL_OES_rgb8_rgba8 extension is supported.
Please check for that string in the log. It should be printed on rom start.

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

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

10
General Discussion / Re: GLideN64 Android port
« on: June 04, 2015, 10:22:33 AM »
@Mikhail GLideN64 does not support RE2. On any platform.

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

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

13
General Discussion / Re: GLideN64 Android port
« on: June 03, 2015, 10:37:10 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

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.

14
General Discussion / Re: GLideN64 Android port
« on: June 03, 2015, 10:31:02 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 :)

15
General Discussion / Re: GLideN64 Android port
« on: June 03, 2015, 01:10:19 AM »
@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.

Pages: [1]