Black screen on real OpenGL ES device

[Narann]

@littleguy77 report he can't see anything on Android port since the combiner refactoring, discussion here.

[littleguy77]

@Narann Anything else I can test for you right now? Have you ever considered picking up an Android device? You might like it :D

[Narann]

For now I'm using my small time in making mupen64plus working with my raspberry pi. But it take time (fail on fail but I will eventually succeed). If I can reproduce the black screen on raspberry pi I would be able to fix it. I've send a mail to one of the dolphin dev about a cheap hardware with OpenGL ES 2 and he send me a nice mail with a list of ES GPUs with what he think about each of them. The cheapest one is ODROID-C1. Android compliant. :D

So raspberry pi for now. If it doesn't work I will check for a dev board.

[littleguy77]

That is a cool little board :) If I had more time I'd probably be tinkering with rpi ;)

[Narann]

There is finally some improvement on this side. I've finally tried to don't rely on "custom" function pointer to use those provided by SDL and it seems to work (thanks to @Nebuleon for it's constant help and devotion on IRC). I asked if we could build fix_gles like a release and @richard42 is working on it.

[fzurita]

This is still an issue with Android. @Nebuleon experienced shader compilation errors, so this is the first thing I'm going to check with Android, when I get a chance.....

Edit: All fragment shaders seem to be compiling and linking correctly. There are also no errors when creating or using shader programs. I guess next thing to check would texture loading. Something must be going wrong there....

[richard42]

I have the same problem with the latest Rice code in the git repo on my gentoo linux system with an AMD GPU. Only the non-textured polygons are drawn.

[Narann]

This problem seems to be related to glActiveTexture.

[richard42]

Interesting. Does your code in rice video support more than 1 active texture at a time?

[Narann]

Interesting. Does your code in rice video support more than 1 active texture at a time?

I'm not sure to understand. Technically, you can only have one active texture at a time.

I tried to remove glActiveTexture() in favor of glBindTexture() (I guess it's what you suggest) but had some issues at this time so I didn't do the change as it was not mandatory for OpenGL ES 2.

The only use of glActiveTexture() is here. As you can see there is OPENGL_CHECK_ERRORS macro you could try to define and report potential errors here.

I have no PC yet to investigate but I know it's a annoying problem. I will tackle it when I technically can.

[richard42]

The GL model supports multiple texture units which can be used at the same time, with either the old-school fixed pipeline or with shaders. The glActiveTexture function is used to tell the GL context which of these texturing units should be the target for the following commands. It is at a higher level of abstraction than glBindTexture. For example, you can do something like the following:

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, texBottomLayer);
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, texMiddleLayer);
glActiveTexture(GL_TEXTURE2);
glBindTexture(GL_TEXTURE_2D, texTopLayer);

And then you can run a shader which uses all 3 textures to produce a single output pixel. In the code that you referenced, is there any way that m_maxTexUnits can be more than 1? If not, then the loop is unnecessary.. But if so, and this is the only place that glActiveTexture is used, then it doesn't make sense. This code is only setting the filtering types for the texture units. There should be other code somewhere which is assigning textures (with glBindTexture) to each unit.

[Narann]

Thanks, there is a lot of legacy in the m_maxTexUnits concept here is my version of the history:

N64 TMEM can store a maximum of eight texture tile descriptors, each one holding a texture with it's informations (size, border flags, format and adress). The N64 texture tile descriptors concept is quite near the OpenGL texture unit.

The Color Combiner can combine two textures (tile 0 and tile 1) and here are the problems: Now, Color Combiner emulation use GLSL to dynamically generate shader combining textures so we only need two texture unit (and this it match the OpenGL 2 requirement youhou!). But before this, there were two way to combine textures:

• CPU Texture baking: This was the ugliest (while still technically impressive). When the code detect two texture would be combined and the GPU didn't support multitexturing, Rice was creating a new independant texture combining textures on the CPU.
• OpenGL multitexturing combined with generated CPU baked textures. At those times GPUs provide various number of texture unit and Rice tried to used them as much as it can to properly emulate Color Combiner (a good example is to have two colors + two textures in two cycles, something impossible with < OpenGL 2).

Those two ways have been removed from the code: There is no more texture baking involved neither old school multitexturing.

But because of this original complexity, texture management code is mess (I can't understand it yet). All my attempts to clean things failed.

To answer you question:

is there any way that m_maxTexUnits can be more than 1?

Yes, at a minimum: Everytime the Color Combiner is in a mode using two textures. A good example (with original comment):

This image put a different color for every part of the Color Combiner. The Color Combiner equation is: (A-B)*C+D. Here, A is red, C is green and D is blue. It reveal how Rareware devs blend a single texture (red and blue) with different mapping scale to create memory efficient multisurfacing and avoid repeated and blurred textures.

At a maximum: m_maxTexUnits is clamped to 8. OpenGL ES 2 spec states a minimal number of texture unit of 8 and OpenGL 2.1 states 2.

ApplyTextureFilter() do two things: Set filter on textures that will be used in combiner (what the method name mean). And implicitly set to texture units (because it useglActiveTexture() instead of glBindTexture()).

This code is only setting the filtering types for the texture units. There should be other code somewhere which is assigning textures (with glBindTexture) to each unit.

I just found it. But what I suspect is that changing glActiveTexture() to glBindTexture() in ApplyTextureFilter() would break some games because BindTexture() is not always called when it should...

Once again there is a lot of legacy here, all texture code should be rewritten at some point.

[Narann]

Should be fixed by https://github.com/mupen64plus/mupen64plus-video-rice/commit/e82afa7cf70616c9c96ff3ffc8aaf55e3007b3df, can anyone confirm OpenGL ES textures works?

[fzurita]

I will try this in Android when I get a chance.

[fzurita]

I think it's working! I did a clean build and everything just to make sure and I haven't had the issue happen again.

[Narann]

Amazing! Does this mean you can use rice directly? I mean, in the android sdk and on real hardware? :)

My next work will be to clean code and prepare a good rpi toolchain. :)

[fzurita]

Yes, I built it for Android and ran it using mupen64plus-ae. I don't see any faults at this point. I do remember reading that a lot of game specific hacks were removed, so I'm sure those will make a come back.

Also, I only used real hardware, I didn't try the emulator.

[Narann]

I do remember reading that a lot of game specific hacks were removed, so I'm sure those will make a come back.

Yes it was so linked to the old (fixed pipeline) way that I can't keep the fixes. But in those case we will have to create per game problem. :)

I wait for @Nebuleon to confirm everything work on it's toolchain and real hardware and I will finally close this bloddy issue!

[fzurita]

Oh, gotcha, now I see what you mean by real hardware. Well, I will say that it works correctly using the Android build scripts.

[richard42]

this fixed the missing textured problem on my linux machine. it looks correct now. great job!

[Narann]

I (finally!) close this one. @fzurita confirmed me he pushed the main rice code to the mupen64plus FZ app. I just tested it (nice app!) and it work smoothly on my smartphone.