What's new

Rice to OpenGL 2.1 (and potentially ES)

OP
Narann

Narann

Graphic programming enthusiast
After a lot of investigation, I realize the original demuxer (I "kind of" skip it for now because it rely on a lot of deprecated stuff) had a hack for Top Gear Rally. The idea was to change tex1 (the weird ramp gradient) to tex0 (the actual sprite for texts). I've done a test with this and text appear!

I didn't commit this change as I through it's time to go in "DecodedMux". My intentions was to remove it but there is too many things that depend on it and some hacks seems relevant. So I read a lot this "DecodedMux" object and start to clean it, starting by old optimizations for limited hardware.

Once again, I've very impressed by the work made by the original author to support low end graphic card (somes are card specific). Specially all functions that try to merge some primitive colors if some stuff (shade color for example) was not used in the combiner mode. I don't know the english word for this but in French we said: "Respect!" I removed a lot of this functions as they are not relevant anymore (and make the code very complex) but the amount of work this guy did is massive.
 

death--droid

Active member
Moderator
Hmmm yeah the Mux decoder actually does a pretty good job for the most part :p Rice was a genius with this stuff, and its a shame he did not stay around in the N64 scene.
Finally got a few days to code again so will post here if i find any common code that can be cleaned up or fixed!! Or if i have any concepts :p

This is a good topic we should definitely keep up, would be good if we could get the Daedulus guys in here as well, they seem quite knowledgeable
 
OP
Narann

Narann

Graphic programming enthusiast
On my side, I'm about to totally remove DecodedMux. As now, my ColorCombiner only depends on the various sources types. I'm slowly removing every dependencies to DecodedMux. Only few of them are relevant but I will use ColorCombiner class directly to ask them and avoid one indirection. Before the way was something like:

m_pRender->m_pColorCombiner->m_pDecodedMux->isUsed(TEXEL0)

This kind of call was very important all around the Rice code because there was no way to reproduce the color combiner equation simply with OpenGL. Now we have shaders, a massive amount of code that extract informations to tweak the renderer are not relevant anymore.

So cleanup after cleanup, I've been able to remove a lot of DecodedMux->isUsed() stuff. Only Texel0, Texel1 and LODFrac are still needed.

Now it will look like:

m_pRender->m_pColorCombiner->m_bTex0Enabled

So the ColorCombiner class is now responsive to provide what it has.

Now every important calls "isUsed" calls are done by the ColorCombiner, a big step has been reached (not pushed yet): Here, I've been able to totally comment the SetMux() function call! (Notice the SetCombineMode() which is my own demuxer and the one I rely on.

SetMux() was responsive to inject the color combiner mode muxes to the old DecodedMux class that do all it's massive job. Comment it make the DecodedMux class totally useless from a technical POV. This is a massive advancement as it should simplify the code a lot in the futur. I'm still hesitant to totally remove the DecodedMux files as it contain a lot of hack and I guess I will need to inject some of them at some points. I will keep the file on side.

I also do a lot of "trash remove this, see if it work, and go back". The point is to quickly test the relation between some part of the code when I guess there is not but don't do the final modification before know exactly how the code works. And I realized a lot of textures was created and modified depending on the ColorCombiner parameters. I suspect this textures are no more modified now as my ColorCombiner shaders do the job but the update process to send them to the GPU is still done. I need to check that! The texturing code of Rice need a whole code review (it has been wrote when the number of texture unit was very limited) but it will be as massive as ColorCombiner so I will wait for that.

I will also start an important part: Until now, There was a lot of inheritance in the ColorCombiner. I've been able to remove A LOT of them but there is still CColorCombiner->COGLCombiner->COGLSecondFragmentShaderCombiner.

The COGLCombiner has no sens anymore so I will put the COGLSecondFragmentShaderCombiner content inside the COGLCombiner and remove everything that is deprecated in COGLCombiner.

This way we will have a nice and simple: CColorCombiner->COGLCombiner.

Notice it's how it was supposed to be but time make a proliferation of COGL14Combiner, COGL141Combiner, COGLEnvCombiner, etc...! :D

This will be a big job as I need to check every and calls to COGLCombiner and see if they are still relevant (most of them are not, if so, I need to clean the calling code). The only virtual functions in COGLSecondFragmentShaderCombiner seems to be InitCopy InitFill and Init12Cycle. So we could hope to have only three virtual functions.

After this, I bought the Raspberry Pi B+ :p I would like to compile mupen64plus and Rice for OpenGL ES 2 with it. I still have no idea how to do that but from the backport mupen64plus-ae OGL ES 2 commits of LittleGuy (thanks to him and the rest of the team) it should be pretty straightforward.

Still a lot of work to do...
 

death--droid

Active member
Moderator
Wowsers actually sounds like you have a lot of work to do, though if i was you i would strip out all of the normal combiners and focus completely on your new fragment shader combiner. You'd be surprised how much that helps you clean up the code as well. The fragment shader / pixel shader is more than enough to fully emulate the Nintendo 64's colour combiner accurately
 
OP
Narann

Narann

Graphic programming enthusiast
if i was you i would strip out all of the normal combiners and focus completely on your new fragment shader combiner. You'd be surprised how much that helps you clean up the code as well.
This is exactly what I'm doing (or I miss something, could you develop?). Now the combiner is fully GLSL it can be considered "accurate" (not from a low level perspective of course but from the execution logic). So I'm removing everything that has been here to bypass the lack of flexibility I know have (constant color textures, old COGLCombiner class etc...).
This task is actually more tricky that it look like because I need to choose if I fight to let some hacks that where here to "maybe" bypass the old Combiner limitation (and so, are irrelevant now) or which are totally legitimate (Top Gear Rally). More I think about it more I think I will remove every combiner hack but keep the DecodedMux file as a doc if a weird effect appear.
 
OP
Narann

Narann

Graphic programming enthusiast
After too much time, I finally finish a boring task that where needed to keep mupen64plus cross platform compatibility. I've send a message on the mupen64plus mailing list that I copy paste here:

Hi guys!

I've finally push the most boring code part to do on a open source
project: Prepare extension calls! :D

This was necessary to bring back the cross platform stuff m64p project
is supposed to be.

So at this stage, the repo should compile at the same cross platform
level than before all my changes.

Next: "From what I understand", you "should" be able to compile in
OpenGL ES. I say should because for now, the only way I've been able to
tests for OGLES is hardcoding the driver flag in the Makefile:196, use
USE_GLES, and maybe hide some #if SDL_VIDEO_OPENGL stuff in osal_opengl.h.

I know, this does not seem sexy. Everything would became easier once
your feedbacks will came and the Makefile will be more consistent.

Why it take so long?

1) I've not been able to prepare a building env with my Raspberry Pie.
So the OpenGL ES code is not truely tested. I've tested actually
"forced" the Mesa GL ES driver of my chipset. It was working but I have
no idea if this is a relevant test case.

2) Seriously, the way to create OpenGL callbacks is a pain. So I have to
find "huge" amount of motivation to spend my little personal time to do
such boring stuff... But it's done now!

So now guys, I need you!

There is a true lack of "nice" OGLES way to compile

If anyone could compile this on various platform (I'm specially
interested by ES hardware) and report what they have to fight for etc...
If you also could compile the original repo to be sure it's a problem
coming from my modifications:

https://github.com/Narann/mupen64plus-video-rice << Mine

https://github.com/mupen64plus/mupen64plus-video-rice << official repo
(my modifs are not pushed yet)

There is still some code cleanup to do. I also know Zelda 64 as a tiny
clamping problems on the shader side (bringing to some dark dots in the
screen) but it should be ok for testing.

Any feedback is welcome. I'm also interested about performance feedbacks
(slower? faster?). I have the impression it's a little faster.

Once again, a big thanks to LittleBoy77. Your code really help me to
follow the good direction! :)

A big thanks in advance for all of you that could help me on this last
(but not easy) step!

Hope you like.

So if any of you have a way to compile mupen64plus on a OGLES hardware it would be really helpful to feedback.
 

Top