Rice's Plugin Source <discussion>

Iconoclast · Jun 25, 2007

Some questions for Rice; he's worked on the plugin longer than anyone else. Strange, very strange, signs of frame buffer emulation in both Banjo-Kazooie and especially issues in Banjo-Tooie. I would like to be enlightened to the science of the causes to what I state below, and I'm sure, should Rice have even a possible explanation, mudlord of course would use this information more than I could.

[Tested using latest official version of Rice's plugin, 6.1.1 beta 10.]

One of my biggest confusions is the frame buffer emulation. In Banjo-Kazooie, you can emulate the pause screen frame buffer drawing by using the Basic Framebuffer setting and at least Basic & Write Back for rendering-to-texture emulation. In Tooie, this does not work, but what works in both regardless of frame buffer settings is the combination of Normal Blender and Normal Combiner, even shows some form of motion blur. A screenshot of the same exact result in Banjo-Tooie, working more often than does in Kazooie.

Even with both frame buffer emulation and rendering-to-texture emulation completely set to None (not Default even), the black bg seems to disappear to uncover the plane behind it as the in-game geometry rather than a rendered bitmap.

Also...wtf:

His ass is (literally) hanging out, that huge bulge on his left buttock goes into his right buttock and back every step he makes. I owned this game cartridge, and I swear to God, I never saw Klungo with any assbreasts. (Below notes are for mudlord's development.) Near Plane Z Hack does not fix this severe diversion affecting game playability, but it fixes some wiggling in the left digger tracks pane, side effects weren't worth it.

...Low polys.

Things that happen no matter what setting (I now have a GeForce 6150 LE HAL card):

(okay, now obviously, I joke a little too much, so just focusing on the screenshots I guess)

Rice · Jun 26, 2007

Frame buffer emulation was still considered as WIP in 6.1.1 beta 10 version. I didn't anaylze the reason why some setting working for BK but not Tooie. These two games were using different ways for frame buffer effects.

I am glad to do some explanation for the C++ class architecture for the source code
This plugin does both DirectX and OGL, this is the primary reason why I use virtual C++ classes. All reusable codes are defined in the base classes, and only device specific codes are defined in the derived classes.
Some of you may see many unnecessary code in OGL only Linux port of the project, that was because all DirectX codes may have been removed.
C++ class architecture may initially look very confusing and unnecessary at the beginner, but it makes very easy to implement new APIs, for example, to support DirectX 9, or DirectX 10, to support new OGL APIs. A new class can be just derived from previous classes, only changes need to be implemented for the new APIs.

The reason goes for all virtual classes in the project, including CRender, CColorCombiner, CAlphaBuilder, CTexture, ....

I should say that even with such multiple layer class derivation, the code was still very efficient and fast. All most important code section had been optimized to their maximal speed.

The DLPaser_Process is the function to decode and execute all ucodes.

jackschmidt · Jun 26, 2007

Thanks for the explanation Rice. I've read some parts of the code and yeah, there are a lot of virtual classes. I've managed to trace the code using printfs and I do think I understand a bit how this works now. It's still kind of curious how the wrestlers in Tohkon Road 2 would be missing when currentUcode (I think) directly points to what I think is the RDRAM array structure.

currentUcode (I think) would hold all calls to the rendering functions for different OGL and OGLExtended functions.

I'm getting a better grip on things but not quite yet. I hope to be able to figure out what went wrong with the rendering functions (at least that's where I think things went wrong).

I think most of the Windows code is actually still intact, or at least there are some parts of it intact. With Hacktarux's port, some of the source files have Windows parts and Linux parts (There's also this definition on XBOX :O though I don't know what that means and I won't trouble myself thinking about what that is

).

I'm going to take this slow and learn the code. Thanks again Rice.

Iconoclast · Jun 26, 2007

Still learning C++ online, so I'm not fully comprehensive of things like classes yet.

Although, I now realize a misjudgement I made in that last screenshot. It's not vertex misplacement; I think it's adding a vertex directly above another vertex forming the bump in the bottom of the road (not visible to user without the levitation cheat) where this new vertex is in the same plane as the road, forming that dissolved angle. I shouldn't presume this dynamic class structure might be causing this? From what I've observed, it seems to be consistent; happens every time you walk on that spot on the road and flickers back to normal in an instant.

mudlord · Jun 27, 2007

There's also this definition on XBOX :O though I don't know what that means and I won't trouble myself thinking about what that is

Thats for a XBox port

All render code for that is in D3D of course.

'm going to take this slow and learn the code.

Sounds great

.

jackschmidt · Jun 28, 2007

I find this a bit strange in the way Rice's plugins behave.

Here's a snippet of my debug logs on the DLParser_Process loop on the stack

Code:

RSP::start of loop
LOGUCODE: 0x002a8698: f5601000 00080200 1
RSP::next iteration
RSP::start of loop
LOGUCODE: 0x002a86a0: f2000000 001fc0fc 1
RSP::next iteration
RSP::start of loop
LOGUCODE: 0x002a86a8: e4390380 00190280 1
OGLRender::SetCurrentTexture.
OGLExtRender::ApplyTextureFilter
OGLRender::SetAlphaTestEnable.
OGLRender::SetZCompare.
OGLRender::SetZUpdate.
OGLExtRender::SetTextureUFlag
OGLExtRender::EnableTexUnit
OGLExtRender::BindTexture
OGLExtRender::SetTexWrapS
OGLExtRender::SetTextureVFlag
OGLExtRender::EnableTexUnit
OGLExtRender::BindTexture
OGLExtRender::SetTexWrapT
OGLExtRender::SetTextureUFlag
OGLExtRender::EnableTexUnit
OGLExtRender::BindTexture
OGLExtRender::SetTexWrapS
OGLExtRender::SetTextureVFlag
OGLExtRender::EnableTexUnit
OGLExtRender::BindTexture
OGLExtRender::SetTexWrapT
OGLRender::PostProcessSpecularColor.
OGLRender::PostProcessDiffuseColor.
OGLRender::TurnFogOnOff.
OGLExtRender::ApplyTextureFilter
OGLRender::ApplyRDPScissor.
OGLRender::RenderTexRect.
OGLRender::glViewportWrapper.
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::ApplyTextureFilter
OGLRender::TurnFogOnOff.
OGLExtRender::ApplyTextureFilter
OGLRender::ApplyRDPScissor.
OGLRender::RenderTexRect.
OGLRender::glViewportWrapper.
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::ApplyTextureFilter
OGLRender::TurnFogOnOff.
RSP::next iteration
RSP::start of loop
LOGUCODE: 0x002a86b8: e7000000 00000000 1
RSP::next iteration

I wonder why at some iteration, there is no OGL functions being called. Could it be a NOOP line?

mudlord · Jun 28, 2007

Well, that log doesnt seem to look right. Seems quite possibly one microcode isnt decoded.....could be a NOP operation.

I'm just curious, what debugger did you use to trace the operations? I am super curious in this, as it would be helpful in tracing exactly how the render engines operate and how things are processed in more detail. (which I am very curious in)

Rice · Jun 28, 2007

The log looks right. What do you mean that there is no OGL functions called?

RenderTextRect is the one to perform actually drawing.

mudlord · Jun 28, 2007

The log looks right. What do you mean that there is no OGL functions called?

RenderTextRect is the one to perform actually drawing.

Thanks for correcting me Rice, I must admit, assembly language is not one of my strengths

.

I guess what he means is that no OGL functions are called in the loop here:

Code:

RSP::next iteration
RSP::start of loop
LOGUCODE: 0x002a86b8: e7000000 00000000 1
RSP::next iteration

jackschmidt · Jun 28, 2007

Rice said:
The log looks right. What do you mean that there is no OGL functions called?

RenderTextRect is the one to perform actually drawing.

Yes. RenderTextRect is the one that renders. I was referring to what mudlord was quoting.

Code:

RSP::next iteration
RSP::start of loop
LOGUCODE: 0x002a86b8: e7000000 00000000 1
RSP::next iteration

Here's what the code looks like right now, complete with my comments.

Code:

                        Gfx *pgfx = (Gfx*)&g_pRDRAMu32[(gDlistStack[gDlistStackPointer].pc>>2)];

                        //this will hold lots of interesting stack info.
                        printf("LOGUCODE: 0x%08x: %08x %08x %d\n",
                                gDlistStack[gDlistStackPointer].pc, pgfx->words.w0, pgfx->words.w1, (gRSP.ucode!=5&&gRSP.ucode!=10)?1:0);

                        gDlistStack[gDlistStackPointer].pc += 8;
                        //I'm not sure about the bitwise shift operation.
                        //currentUcodeMap is a set of RDP instructions.
                        currentUcodeMap[pgfx->words.w0 >>24](pgfx); //This must do the actual render. :p

So with the debug log above, it only seems that pgfx is referenced to the g_pRDRAMu32 structure and when it does currentUcodeMap[] (pgfx), nothing happens. (I do presume as of this moment that the OGL render calls happen at the currentUcodeMap line.

Rice · Jun 29, 2007

I cannot remember off my head, but the E7 code seems to be the end of DList. The plugin executes whatever RSP/RDP code run by the game.

jackschmidt · Jun 29, 2007

That does mean there's still a lot to unearth.

e7 code is the end of the DList... hmmm... I probably should find out what each code does.

Can anyone tell me the significance of this bit shift operation?

Code:

currentUcodeMap[pgfx->words.w0 >>24]

I think it shifts to get the actual reference of the RSP/RDP operation. I could be wrong though.

mudlord · Jun 30, 2007

That does mean there's still a lot to unearth.

True, I am still reading through the render code and other things....:sombrero:

I think it shifts to get the actual reference of the RSP/RDP operation. I could be wrong though.

I have to admit I haven't really looked at the RDP/RSP code much, and I apologise for not being much help in that regard

jackschmidt · Jun 30, 2007

mudlord said:
True, I am still reading through the render code and other things....:sombrero:

I have to admit I haven't really looked at the RDP/RSP code much, and I apologise for not being much help in that regard

Don't be too hard on yourself. I understand that this code is pretty complex in its own right. We'll just churn on slowly and figure it out. My theory right now is that some of the rendering is somehow missed by the game... not sure where nor how though.

EDIT:
While trying to understand and study the code behaviour, I find very little information given the log. Take a look.

Code:

bc000006
06000000
e7000000
03800010
b6000000 - set cullmode, etc.
bb000000
b7000000 - set cullmode, etc.
bc000404 - apply scissor clip
bc000c04 - apply scissor clip
bc001404 - apply scissor clip
bc001c04 - apply scissor clip
ba001402
ba001701
ed000000 - apply scissor clip, update scissor clip, glviewport wrapper, setviewportrender
ba001001
ba000e02
ba001102
ba001301 - apply texture filter
ba000c02 - apply texture filter
ba000903 - apply texture filter
fcffffff
ba000801
b9000002
b900031d - set zcompare, set zupdate, set alphatestenable
ba000602 - apply texture filter
ba000402 - apply texture filter
b8000000
e7000000
b900031d
ba001402 - apply texture filter
fcffffff
fe000000
ff10013f
f7000000
f64fc3bc - clear buffer
e7000000
ff10013f
f7000000
f64fc3bc - render

I think I'm going to analyze RenderRect function in the mean time. After all, Rice did say this is what does the actual rendering.

mudlord · Jul 2, 2007

Don't be too hard on yourself. I understand that this code is pretty complex in its own right. We'll just churn on slowly and figure it out.

Yeah I guess. I got the main DX and OGL renderers figured out, while experimenting with some new features I intend to add. Its the ucode handlers that are giving me the most grief. Everything else is quite straightforward tho.

In the meantime, I got some extremely promising results with porting the plugin to 2 new compiler targets. I'm hoping to make it 3 extremely soon. Which means now, we get a new IDE to play with when compiling, and not just MSVC2003 or MSVC2005...:king: , which means now more people can contribute. I posted up some alphas in "the usual spot" if people want to play with them. (of course, they are not public....yet)

jackschmidt · Jul 2, 2007

mudlord said:
Yeah I guess. I got the main DX and OGL renderers figured out, while experimenting with some new features I intend to add. Its the ucode handlers that are giving me the most grief. Everything else is quite straightforward tho.

In the meantime, I got some extremely promising results with porting the plugin to 2 new compiler targets. I'm hoping to make it 3 extremely soon. Which means now, we get a new IDE to play with when compiling, and not just MSVC2003 or MSVC2005...:king: , which means now more people can contribute. I posted up some alphas in "the usual spot" if people want to play with them. (of course, they are not public....yet)

I wish I could get some positive results but I don't have any results yet. Congrats though for making it happen.

Rice · Jul 2, 2007

jackschmidt said:
I think I'm going to analyze RenderRect function in the mean time. After all, Rice did say this is what does the actual rendering.

RenderTextRect is only one of the drawing function, and one of the easiest ones.

I can see that you have a lot of code to read and to understand before being able to able to make modifications on the plugin.

Good luck.

jackschmidt · Jul 3, 2007

I'm sorry to disappoint, Rice.

Code:

LOGUCODE: 0x002a83b8: e44f01f0 002f00f0 1
OGLRender::SetCurrentTexture.
OGLExtRender::ApplyTextureFilter
OGLRender::SetAlphaTestEnable.
OGLRender::SetZCompare.
OGLRender::SetZUpdate.
OGLExtRender::SetTextureUFlag
OGLExtRender::EnableTexUnit
OGLExtRender::BindTexture
OGLExtRender::SetTexWrapS
OGLExtRender::SetTextureVFlag
OGLExtRender::EnableTexUnit
OGLExtRender::BindTexture
OGLExtRender::SetTexWrapT
OGLExtRender::SetTextureUFlag
OGLExtRender::EnableTexUnit
OGLExtRender::BindTexture
OGLExtRender::SetTexWrapS
OGLExtRender::SetTextureVFlag
OGLExtRender::EnableTexUnit
OGLExtRender::BindTexture
OGLExtRender::SetTexWrapT
OGLRender::PostProcessSpecularColor.
OGLRender::PostProcessDiffuseColor.
OGLRender::TurnFogOnOff.
OGLExtRender::ApplyTextureFilter
OGLRender::ApplyRDPScissor.
OGLRender::RenderTexRect.
OGLRender::glViewportWrapper.
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::TexCoord
OGLExtRender::ApplyTextureFilter
OGLRender::TurnFogOnOff.
RSP::next iteration

Taking a look at the final sections of rendering from the debug where the wrestlers are terribly missing. I have to wonder if this is a culling problem.

Anyway, lots of stuff to read and not a lot of time to do that means everything moves very slooooowly.

mudlord · Jul 3, 2007

Anyway, lots of stuff to read and not a lot of time to do that means everything moves very slooooowly.

Remember, slow and steady wins the race

.

Cyberman · Jul 3, 2007

mudlord said:
Remember, slow and steady wins the race.

Then I've got it in the bag!

Erstwhile (much cursing at software ocures).

Cyb

Rice's Plugin Source <discussion>

New member

Emulator Developer

EmuTalker

New member

Banned

EmuTalker

Banned

Emulator Developer

Banned

EmuTalker

Emulator Developer

EmuTalker

Banned

EmuTalker

Banned

EmuTalker

Emulator Developer

EmuTalker

Banned

Moderator