[WIP] Color Combiner Refactoring

[Narann]

And here we are.

Here is the "new" Color Combiner. A lot of old fixed pipeline gl calls have been remove. A lot of classes supporting various OpenGL version on have been removed and the main class OGLColorCombiner is now OpenGL 2.1/OpenGLES 2 and rely on GLSL.

This commit make Rice incompatible with < OpenGL2.1. OpenGLES 2 use the same code path than the OpenGL one. OpenGLES 2 still need some fixes but it compile and run on OGLES 2 hardware.

From my various regression tests we should not have lost anything.

I've update config file update process so you should not lost anything regarding your config.

There is still some work to do. OGLFragmentShader and OGLESFragmentShader files are still here but should be removed safely. Demuxer is sooooo integrated deep into Rice code that I'm not able to remove yet but I'm not too far. Only few calls in the deep of Rice still need it.

Feel free to discuss, compile, test, etc...

[Narann]

@Nebuleon, yes, sorry. Thanks for the information.

@gizmo98 Cool!

The one on the left is the bad one. And on the right it's the fixed one. Am I right?

If so, I see some ARM_NEON stuff on vertex processing.

This would mean Pandora code has some improvement in the vertex processing code. I will create a ticket for this. (Vertex processing code in a mess in Rice and having dig into some vertex processing code of some N64 plugins. it seems to always be a mess...).

[gizmo98]

@Narann Correct! I don't know if the neon stuff fixes it. I will recompile without neon. There are more differences like an aspect ratio option and a widescreen hack (in game menu is 4:3 and the rest 16:9). I also added a "fullscreen=native screen resolution" option for broadcom's videocore IV. But all these other changes should not fix shading problems.

Update: Even without ARM_NEON shading is correct.

[gizmo98]

@Narann texture colors are correct now. Shading is still broken.

[Narann]

Thanks! Fix shading will be hard it can be anything.

[littleguy77]

@Narann Progress on Android. Some polygons are rendering now, though a lot are missing. Here is the fork: https://github.com/littleguy77/mupen64plus-ae/commits/test-narann-rice and here are some screenshots:

[Narann]

Cool but weird at the same time other GLES hardwares seems to work with textures. Any warning during compilation? And during runtime? Are you using real hardware?

Could you try the first commit reported as "working" on real GLES hardware? Just to see if textures are there.

Thanks in advance!

[littleguy77]

Sure, I'll try when I can find some time. Yes, these are screenshots taken on a real device (nexus 7 2012). It's a good test device since it always runs vanilla OS and has very good drivers.

[richard42]

I just compiled under MSVC2013 and it builds now (yay!) I also see the same artifacts as littleguy77. Here's a sample from mario kart:

I redirected the OPENGL_CHECK_ERRORS macro to use the OutputDebugString() command to get opengl error messages in the debugger, and it did not report any errors. Are you using FBOs?

[richard42]

I tried to build the fix_gles branch under OSX, and clang returned quite a few warnings and errors:

http://pastebin.com/xS53pRRv

OSX unfortunately only supports OpenGL 2.1 and older in a 'compatibility' context, and requires a 'core' context to use OpenGL 3.2 and newer functions. As such, the GLSL functions are extensions, and are named with the ARB suffix.

[Narann]

Thanks a lot Richard, this texture problem look weird.

Are you using FBOs?

No I'm not. I will try to setup a Windows tool chain on my tiny laptop but its such weak hardware...

OSX unfortunately only supports OpenGL 2.1 and older in a 'compatibility' context, and requires a 'core' context to use OpenGL 3.2 and newer functions. As such, the GLSL functions are extensions, and are named with the ARB suffix.

error: unknown type name 'PFNGLSHADERSOURCEPROC'; did you mean 'PFNGLSHADERSOURCEARBPROC'?

This kind of freak me out...

I mean, I can load function pointers to all of those ARB equivalents. But I'm not sure the ARB function get the exact same inputs than the ARBless ones (ARB_shader_objects actually does have some tiny modifications).

I will try to blind-fix this but it's quite inconsistent. Any OSX dev suggestion to handle this is welcome. How if we try to use a core context on OSX? What would happened?

Notice I don't use any OpenGL 3.+ function. All I use is 2.1. Reading this page I get some infos:

MacOSX gives you a choice: core profile for versions 3.2 or higher, or just version 2.1. There is no way to get access to features after 2.1 and still access the Fixed Function Pipeline.

That's supposed to be great! So if we use this trick that should work right?

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_COMPATIBILITY);

:pray:

[richard42]

It's strange that most of the textures are all black, yet it doesn't throw any GL errors. I asked about the FBOs because that's one feature I've used where I've seen this type of failure mode. Since you're using shaders it seems likely to be an incompatibility in the GLSL code.

I think loading the function pointers to the ARB functions should work in the vast majority of cases. A few months ago at work I ported our very extensive media processing software under OSX from opengl 2.1 to opengl 3.2 (and back). There were hundreds if not thousands of function name renames for this. :) I think there was only one or two functions which took different parameters.

If you use a Core (3.2) profile, you can not use any of the legacy (compatibility) stuff. Everything must be done with shaders (vertex and fragment), no fixed function pipeline stuff, no matrix stuff, no environment, no lighting. And (the most unfortunate part) is that all vertices must be given with VBOs. No glVertex or glTexCoord.

The SDL_GL_SetAttribute code which you pasted will request a compatibility (2.1) context, which is exactly what you get without that code. In order to get a 3.2 (Core) context, you must request M64P_GL_CONTEXT_PROFILE_CORE for the profile mask and major/minor version 3.2. I added these symbols to the core video extension for Gonetz to use his 4.1 stuff for gliden64.

[Narann]

Thanks a lot for experience sharing Richard!

It's strange that most of the textures are all black, yet it doesn't throw any GL errors. I asked about the FBOs because that's one feature I've used where I've seen this type of failure mode. Since you're using shaders it seems likely to be an incompatibility in the GLSL code.

I think it's related to glActiveTexture. The glActiveTexture is only manually defined in Windows because Linux already define it. Maybe WIN32 is not defined in your compilation process. Could you try to remove the #ifdef WIN32...#endif from OGLExtentions.cpp and OGLExtentions.h and try again? Same for you @littleboy77

I think there was only one or two functions which took different parameters.

Very pleasant to hear! I will do this asap.

And (the most unfortunate part) is that all vertices must be given with VBOs. No glVertex or glTexCoord.

Current Rice code is not too far from being able to send datas using VBO. There is (hum... should be) no more fixed pipeline stuff in Rice. For now it use glVertexAttribPointer to send datas which is supposed to be compatible with 3+ and 4+.

I would be very interested to actually get the OSX compile log run with core (3.2) profile to get the list of latest deprecated stuff in Rice. There shouldn't be too much and it should happen in few corners.

[richard42]

Hi Narann, I made the change you suggested with the #ifdef in my win32 build, and it still showed the same rendering problem. Looking at it a little bit, I realized that all of the polygons which should be textured with bitmaps are black, and the only polygons which are not black are those that are shaded with solid colors or gradients. Hope this helps.

Sorry I wrote VBO when I should have written VAO - vertex array objects. You have to handle all of the vertex coordinate transformations by yourself (ie with a vertex shader) - no matrix operations allowed.

I found that I was able to build your fix_gles branch under OSX by removing all the function pointer stuff completely:

http://pastebin.com/wDm3KUPQ

Unfortunately it doesn't look very good though. It has the missing textured polys similar to Win32 (and apparently GLES too) plus it also has some pretty severe flashing.

I would suggest first fixing the texture problem, which should hopefully take care of the worst problem in all 3 platforms, and then fix the remaining problems on all of the platforms before tackling the OpenGL 3.2 core profile thing.

[Narann]

Thanks Richard!

I made the change you suggested with the #ifdef in my win32 build, and it still showed the same rendering problem.

This mean my latest commit will not fix the problem...

I found that I was able to build your fix_gles branch under OSX by removing all the function pointer stuff completely

This mean my latest commit will build under OSX (the __APPLE__ block has been created empty in order to be feeded later but I will maybe let it as it if it build correctly). :)

But that's weird. If you were able to build removing any gl function declaration, this mean gl functions were already declared... If so: Where? Does it mean you are in full OpenGL 3.2 core profile?

I will try to fix Windows texture with my tiny laptop using VS2013 asap.

[richard42]

OSX's OpenGL 2.1 has all of the GLSL stuff defined natively. Some things are only acessible as extensions (ARB or EXT) but it is present. It's different than Windows. In Windows, you only have the OpenGL 1.0 or 1.1 functions. So Win32 is extremely primitive; it does not have definitions for any of the GLSL stuff.

The biggest changes in OpenGL 3.2 core under OSX are the removal of all the legacy ("compatibility") functions. It also has a newer version of GLSL, harmonized version numbers between the GLSL language and the OpenGL context, and support for some new things like integer textures.

[Narann]

OSX's OpenGL 2.1 has all of the GLSL stuff defined natively.

Great! Rice is supposed to only use OpenGL 2.1 subset used in OpenGL ES 2. This mean no fixed pipeline function.

The biggest changes in OpenGL 3.2 core under OSX are the removal of all the legacy ("compatibility") functions.

So my work should work with OpenGL 3.2 as it does not use fixed pipeline functions (maybe one or two at some corner of the code).

As soon all those problems are fixed I will try to gather which are the Rice gl functions considered as deprecated in core profile and try to remove them.

[richard42]

Hi Narann, I just tested with Win7 and MSVC 2013, and your branch compiles and runs now. It is missing the VS2013 project file however, and the OSD doesn't work right. But otherwise it looks good.

[richard42]

Unfortunately there are a lot of build errors in OSX.. Here's the log: http://pastebin.com/mkxeN4KQ

[Narann]

Thanks a lot Richard! No flicking on Windows? I will investigate OSX problems.

[Narann]

From the pastebin you provide, it seems that some PFNGLCREATESHADERPROC are not defined. But those are defined in the OSX SDL_opengl.h your provided to me. How is it possible OSX doesn't use SDL_opengl.h header?

[Narann]

While, at the same time, few line after, you can read /opt/local/include/SDL2/SDL_opengl.h:6459:25: note: 'PFNGLSHADERSOURCEARBPROC' declared here. I must miss something.

[Narann]

Oh! I think I finally get it! Yeah! As gl functions are natively defined on OSX we don't need their pointers! Fixing this now!

[tony971]

Is this still WIP?

[Narann]

I just need confirmation it work with Mac and Windows and we should be able to merge it into the master. We lack of testers actually. :)

[tony971]

I'm a git noob. If I could get a compiled version, I'll test on Windows for you.

[richard42]

I just tested your branch with Win32, and it crashed until I added one line:

diff --git a/src/OGLExtensions.cpp b/src/OGLExtensions.cpp index 359c99c..c9647ef 100644 --- a/src/OGLExtensions.cpp +++ b/src/OGLExtensions.cpp @@ -107,6 +107,7 @@ void OGLExtensions_Init(void)

ifdef USE_GLES

else

if defined(WIN32)

• INIT_GL_FUNC(PFNGLCREATESHADERPROC, glCreateShader) INIT_GL_FUNC(PFNGLACTIVETEXTUREPROC, glActiveTexture) INIT_GL_FUNC(PFNGLSHADERSOURCEPROC, glShaderSource) INIT_GL_FUNC(PFNGLCOMPILESHADERPROC, glCompileShader)

Also, the OSD doesn't work right. But otherwise it looks good.

[richard42]

I just tested under OSX as well, and it compiles and runs fine here, except the OSD also seems to not work under OSX.

[Narann]

Thanks Richard! Sorry for delay, I was in vacation.

Good catch for the Windows missing declaration. I will patch this asap.

About the OSD, I must confess I never really figured out into how it works but I guess fixing it on one platform will fix it everywhere.

[richard42]

No problem; sorry it took so long for me to test. But it looks like you're pretty close now.

[Narann]

Fix done! I realize OSD doesn't work on Linux too. :(

[richard42]

Hi Narann, I merged your branch into a new branch in this repo called Narann-master, and I pushed the new branch to github. Unfortunately there is some kind of a problem with the shaders. Under Linux (I haven't tested Win32/OSX yet), the video plugin only seems to render flat or gradient polygons. None of the textured polygons appear. Can you take a look at this?

[Narann]

Thanks Richard! I just tested the Narann-master branch of the original repo and I don't have any texture issue. You said there was no problem before(tm) have you compile the branch on the same workstation than before? Could you give me your Linux distro version? Doest it look like the same problem than littleguy or the windows build you tried few month ago? Have you any warning during compilation?

This problem seems to be related to a missing glActiveTexture() declaration but it's not supposed to be used on Linux (as Linux is shipped with OpenGL 1.3 header which already declare glActiveTexture()).

Could you try to add:

INIT_EMPTY_FUNC(PFNGLACTIVETEXTUREPROC, glActiveTexture)

and:

INIT_GL_FUNC(PFNGLACTIVETEXTUREPROC, glActiveTexture)

in OGLExtensions.cpp and:

extern PFNGLACTIVETEXTUREPROC glActiveTexture;

in OGLExtensions.h both on the Linux side (the last else statement) and try again?

Maybe try on OSX and Windows without any modification could also give a hint on where the problem is.

Last and not least, have you any warning in the terminal about OpenGL that can't reach function pointer?

Thanks in advance! :)

[richard42]

OK, in the course of my testing this suddenly started working. My machine is running Gentoo linux, with an AMD Radeon R9 280 GPU. I had previously tried a bunch of older builds from your branch and they all had the same texture problem. But this morning I deleted everything in my test folder and re-built it all from scratch, and then it started working. This seems a little bit suspicious because I did a full rebuild yesterday before testing, but didn't delete the test dir beforehand. It makes me think there's something that's not getting copied/overwritten by the makefiles. But regardless of that, all your hard work is finally in the master branch. Congratulations! Thanks for this huge effort on the Rice Video plugin.

[Narann]

Thanks Richard!

But I was not sure merge was a good idea, I will explain why:

After some time, I realize fixed pipeline to dynamic one break a lot of compatibility fixes implemented for years and that almost every hack as to be rewritten so I can understand peoples don't wanted to see rice broken again. OpenGL Dynamic pipeline state a lot of changes in the ways depth and vertex clipping it handle.

I'm very sorry, I should have closed this PR but I was expecting to try to tackle those hacks at a time. :(

[richard42]

Oh well, we gotta move forward at some point. Now you can work on it in the master branch :)