Rice's Plugin Source <discussion>

[jackschmidt]

just a notice, Hacktarux posted the Linux source code to the plugin :)...

Yeah. I've built it and am surprised it's easy to build. I've done some slight peek into the code, and am starting to brainstorm how to debug this code... I'm thinking of adding support for one microcode, but right now... don't know where to start.

It's a very interesting read though. I've also tested the plugin and it does perform as well as the last time I tried it. :)

[mudlord]

Yeah. I've built it and am surprised it's easy to build. I've done some slight peek into the code, and am starting to brainstorm how to debug this code... I'm thinking of adding support for one microcode, but right now... don't know where to start.

It's a very interesting read though. I've also tested the plugin and it does perform as well as the last time I tried it.

Wow...thats quite a plan :)....

Indeed, the code is quite interesting to peruse, and quite modular, which is helping things along for what I'm doing for okaygo........

I've started to port over some of the 6.1.1 code to Linux, it needs to be tested tho....

[jackschmidt]

Well, my primary goal is to get the wrestlers to appear for Toukon Road 2. I figure that the ucode jumps from 12 and 19... 19 is marked in the RSP code as Last Legion UX ucode mapping. This is the RSP parser end though, so I really doubt the problem will surface itself there.

I read before that the problem with Toukon Road 2 is the missing ucode support and I really played this game to death back on a real N64... it's fuelling my desire now to fix it on emulation.

Any help right now is appreciated. I know it's not much of a plan but I've been thinking about doing it for a while. Hacktarux's 6.1.0 plugin was very promising so I really wanted to use it as a code base.

I also downloaded the n64dev documentation from sourceforge, but it seems to elaborate on N64 development directly on the hardware. The rom mapping is helpful though when I opened the rom on hexedit.

As of now, I'm still not sure where to debug. Printfs can only go so far.

Mudlord, I can also test your code base if you wish. :)

I've been tracing the DLParser_Process which seems to be the function that deals with the rendering in the RSP code. There are some things that I can't follow with this code, and stuff like BeginRendering() which seems to only increment CRender::gRenderReferenceCount...

Anyway, I'm going to poke around and see what I can unearth.


EDIT:
This is giving me quite a headache. I'm not sure where BeginRendering is defined but the rendering code is definitely confusing me.

I really hope somebody can shed some light.:cry: :bye3:

[mudlord]

I've been tracing the DLParser_Process which seems to be the function that deals with the rendering in the RSP code. There are some things that I can't follow with this code, and stuff like BeginRendering() which seems to only increment CRender::gRenderReferenceCount...


Well, the classes can be a bit hard to follow if you haven't poked around thoroughly. I know I had issues when I was looking through comprehending how things work.


but the rendering code is definitely confusing me.
Which code is confusing you, the API-specific classes, the render classes?

[jackschmidt]

Well, the classes can be a bit hard to follow if you haven't poked around thoroughly. I know I had issues when I was looking through comprehending how things work.


Which code is confusing you, the API-specific classes, the render classes?

The CRender class in particular. I know that some of the methods are implemented by inherited classes defined in OGLRender.c. Strangest of things is that some of the function implementations seem missing. For example, the only BeginRendering() function I found is defined as virtual void in render.c. It's also marked "For DirectX" which means it isn't the function.

I am having a bit of trouble understanding how the plugin works in general. I understand that it does extract the ucode of whatever the game demands and it does some remapping and somehow renders the polygons. It's just that with not much information handy, it's hard to decipher what is going on.

[Cyberman]

Well, the classes can be a bit hard to follow if you haven't poked around thoroughly. I know I had issues when I was looking through comprehending how things work.Everyone's got issues. Lately I've been having them with Microsoft's method of code, it's quite anoying. What they call Rapid Application Developement (RAD) is more AAD (Anoying Application Developement). Ok enough whining from me :D I'm much closer than I was. So for relaxation tomorrow I'll be twiddling some of the code I mentioned before, hopefully SQLite will integrate happily into VC++. What are the settings for the project VS 2005 confuses me (heh confessions), so I assume you are using the C++ compilor right? (Expect the usual MFC fun I guess at least it's predictable).

Cyb

PS your new avatar, is that you after exams I take it? :)

[mudlord]

I've been tracing the DLParser_Process which seems to be the function that deals with the rendering in the RSP code. There are some things that I can't follow with this code, and stuff like BeginRendering() which seems to only increment CRender::gRenderReferenceCount


Hmmm, in a week I'll take a look and help you out. At the moment, I got way too much on my plate to deal with this.


What they call Rapid Application Developement (RAD) is more AAD (Anoying Application Developement). Ok enough whining from me I'm much closer than I was. So for relaxation tomorrow I'll be twiddling some of the code I mentioned before, hopefully SQLite will integrate happily into VC++. What are the settings for the project VS 2005 confuses me (heh confessions), so I assume you are using the C++ compilor right? (Expect the usual MFC fun I guess at least it's predictable).
Yep, using the C++ compiler. What I find annoying is the RAM usage. Quite frankly, the VS2005 IDE is bloated as hell, I have more fun using VC6, thats for sure....



PS your new avatar, is that you after exams I take it?
Indeed, after my exams I'll have much more free time to tinker with things. Which will be a week.

[jackschmidt]

Thanks! In the mean time, I'll poke around the code to see what I find.

[mudlord]

Thanks! In the mean time, I'll poke around the code to see what I find.

Groovy. I'll be back in around a week.
Ciao, for now....

[jackschmidt]

I look forward to it. :)

I'm tracing Video.cpp and noticing that ProcessDList seems to be the starting point function mostly dealing with video rendering.

What makes the code slightly more confusing is the multiple possible entry points, because one is for Windows and one is for Linux. I wonder if ProcessDList is a function that the plugin allows for dlsym()...

EDIT:
Some more digging. I am a bit more confident in thinking DLParser_Process is the rendering function. It seems to set up currentUcodeMap using support functions and currentUcodeMap is the actual set of RDP instructions executed. After which, the different OpenGL calls are done. This is repeated until the stack (DList?) is depleted, or at least that's what I think.

[Iconoclast]

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.

http://i78.photobucket.com/albums/j112/rswedlo/Nintendo%2064%20Screenshots/BANJOTOOIE-4.jpg

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:

http://i78.photobucket.com/albums/j112/rswedlo/Nintendo%2064%20Screenshots/BANJOTOOIE-0.jpg

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. :D

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

http://i78.photobucket.com/albums/j112/rswedlo/Nintendo%2064%20Screenshots/BANJOTOOIE-2.jpg

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

[Rice]

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]

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 :D).

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

[Iconoclast]

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]

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]

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


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]

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]

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

RenderTextRect is the one to perform actually drawing.

[mudlord]

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:

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

[jackschmidt]

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.



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.



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]

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]

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?

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]

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]

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.



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]

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]

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]

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]

I'm sorry to disappoint, Rice.



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]

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]

Remember, slow and steady wins the race:).Then I've got it in the bag! ;)

Erstwhile (much cursing at software ocures).

Cyb

[mudlord]

Then I've got it in the bag!

Erstwhile (much cursing at software ocures).


lol, true...well, it seems now I got some form of preliminary Vista support, thanks to klasa helping me with testing my brand new compiles with the new compiler sets. So, things for this are now are starting to improve on that front..Hopefully, I can get a Vista public beta out soon.

[jackschmidt]

RDP::ExtractedUcode: 12
RDP::New ucode has been detected:
RSP Gfx ucode F3DEX 1.23 Yoshitaka Yasumoto Nintendo., ucode=12RDP_SetUcodeMap - ucode: 12


Hmm... I saw this on the dump... if anything... it's a direct confirmation that the ucode is unsupported. The function called is: DLParser_CheckUcode.

I don't know how significant this progress is, but to me, it's kind of exciting though it's really just scratching the surface.



RDP::ExtractedUcode: 19
RDP::New ucode has been detected:
, ucode=19RDP_SetUcodeMap - ucode: 19
RDP::SetUcode:bUseModifiedUcodeMap is set.
RDP::Forcing to set Ucode as 19.


I'll have to check what used ucode table does...

[mudlord]

Hmm... I saw this on the dump... if anything... it's a direct confirmation that the ucode is unsupported. The function called is: DLParser_CheckUcode.

I don't know how significant this progress is, but to me, it's kind of exciting though it's really just scratching the surface.

Yep, seems your at the surface of the RDP/RSP parsing. Its great your getting progress with what your doing, it really is :).

I have uploaded a test VC6 build, to the end of the stickied topic.

[jackschmidt]

Thanks, mudlord. I'm also wondering that you mentioned earlier that you were going to port it to Linux. Is that also posted on your stickied topic?

[mudlord]

Thats the thing.

My progress on updating the Linux port is going quite slow, mainly due to the fact I don't have a decent Linux distribution installed to test as I go. I was hoping a live Linux CD/DVD might be of use, then I won't have to repartition/format my HD. When its finished, of course it will be stickied too.

[jackschmidt]

Hmm... you could try cygwin... or maybe wubi but they are in beta.

[mudlord]

Hmmmm, I suppose I can give that a shot :)

EDIT: Okay, I got my hands on a distribution of Kubuntu...the fun now begins in my 1st attempts at dual-booting a Linux/Windows system..

[The Siskoo]

Emulator : 1964 0.9.9
Plugins : Mudlord's Rice Video Build (Developpement) - VC6

Eikou No Saint Andrews (J) [!] --> seems playable, there are just some GFX problem (Pic 3 and Pic 4).
World Driver Championship (E) (U) [!] --> For the first time, with this new plugin, World Driver displays summit ^^ (Pic 1 and Pic 2).

Nice job

[jackschmidt]

RDP::ExtractedUcode: 12
RDP::New ucode has been detected:
RSP Gfx ucode F3DEX 1.23 Yoshitaka Yasumoto Nintendo., ucode=12RDP_SetUcodeMap - ucode: 12


Hmm... I saw this on the dump... if anything... it's a direct confirmation that the ucode is unsupported. The function called is: DLParser_CheckUcode.

I don't know how significant this progress is, but to me, it's kind of exciting though it's really just scratching the surface.



RDP::ExtractedUcode: 19
RDP::New ucode has been detected:
, ucode=19RDP_SetUcodeMap - ucode: 19
RDP::SetUcode:bUseModifiedUcodeMap is set.
RDP::Forcing to set Ucode as 19.


I'll have to check what used ucode table does...

I haven't confirmed this but I'm having doubts with this being a breakthrough. I think UsedUcodes is just a stack of ucodes used during the game session.

Means, this one only saves the ucode data extracted and does nothing else. I'm going to test it on Super Mario 64 to see if I get similar results.

[The Siskoo]

Emulator : 1964 0.9.9
Plugins : Rice video build Stabe VC6

Top Gear Hyper-Bike (E) (J) (U) [!] --> now works, some GFX bugs in game and with intro.

[mudlord]

I haven't confirmed this but I'm having doubts with this being a breakthrough. I think UsedUcodes is just a stack of ucodes used during the game session.

Means, this one only saves the ucode data extracted and does nothing else. I'm going to test it on Super Mario 64 to see if I get similar results.

That would make sense, but Rice knows the source more than us :). Maybe he can help us get in the right direction in regards to understanding ucode handling. I got all the others things tho well understood.


Emulator : 1964 0.9.9
Plugins : Rice video build Stabe VC6

Top Gear Hyper-Bike (E) (J) (U) [!] --> now works, some GFX bugs in game and with intro.

Thanks for this testing ^^ One of my hopes is to build up a nice comprehensive compatibility list. This will surely help.

[The Siskoo]

Thanks for this testing ^^ One of my hopes is to build up a nice comprehensive compatibility list. This will surely help.

Are you interesting by a report bugs ?

[mudlord]

Absolutely, the more reports, the better :).

[The Siskoo]

Emulator : 1964 0.9.9
Plugins : Mudlord's Rice Video Build (Stable) - VC6

Bio Hazard 2 (J) [!] --> On the menu screen, it seems there is a problem of refresh or a plane problem (pic 1, 2). In game, GFX messed (pic 3)
Eikou No Saint Andrews (J) [!] --> background is black if you don't push a button (pic 4).
GoldenEye 007 (J) [!] --> don't boot (black screen)
Nightmare Creatures (U) [!] --> don't boot (black screen).
Nintama Rantarou 64 Game Gallery (J) [!] --> Vi's goes to 0 on the main screen.
South Park - Chef's Luv Shack (U) [!] --> GFX messed (pic 5)
Star Wars Episode I - Battle for Naboo (E) (U) [!] --> texts are messed (pic 6) and crash after the screen.
Stunt Racer 64 (U) [!] --> crash on this error message "8009D2FC - Execption in emulation thread"

[majinvegeta2]

Maybe you can fix that too?
First pic is "Legend of Zelda, The - Ocarina of Time - Master Quest (U) (Debug Version)" with Jabo's Plugin.
And the second one is the same but with the Rice-Plugin.

[The Siskoo]

Emulator : 1964 0.9.9
Plugins : Mudlord's Rice Video Build (Stable) - VC6

California Speed (U) [!] --> texts are not displayed properly (pic 1)
Command Conquer (E) (G) (U) [!] --> Some GFX problems (pic 2, 3)

[mudlord]

The RE2/Biohazard 2 bugs are well known, they are due to depth buffer emulation probs and other things. The trick is how to draw things directly in the depth buffer. Ziggy worked out how to do this for RE2 in the wrapper under OGL (so Glide64 can do this with HWFBE), and it will be hard doing it in DX8/9, but then there has to be a way to do it nice and fast.....

I guess posting a list of games in my docs that use unimplemented graphics ucodes will help lower the list to be checked, since all of them are unplayable due to this.

Keep the reports coming! I really appreciate your help!

[The Siskoo]

The RE2/Biohazard 2 bugs are well known, they are due to depth buffer emulation probs and other things. The trick is how to draw things directly in the depth buffer. Ziggy worked out how to do this for RE2 in the wrapper under OGL (so Glide64 can do this with HWFBE), and it will be hard doing it in DX8/9, but then there has to be a way to do it nice and fast.....
Thanks for this explanation... If I understand, the problem is about plugins and not the emulator ?


I guess posting a list of games in my docs that use unimplemented graphics ucodes will help lower the list to be checked, since all of them are unplayable due to this.
Yup, it will be good :)

Keep the reports coming! I really appreciate your help!
My pleasure ^^

Emulator : 1964 0.9.9
Plugins : Mudlord's Rice Video Build (Stable) - VC6

All Star! Dairantou Smash Brothers (J) [!] --> small texts problem (pic 1)

Here is my settings to get DrMario Works. Add this, in the rice ini.
{134d9d76fe3f23da-45}
Name=DR.MARIO 64
FastTextureCRC=2
FrameBufferEmulation=7
RenderToTexture=3
ScreenUpdateSetting=1

[mudlord]

Thanks for this explanation... If I understand, the problem is about plugins and not the emulator ?

Correct, the graphics problems are all to do with the video plugins, while the sound problem is with the core and RSP timing.


Here is my settings to get DrMario Works. Add this, in the rice ini.

Thanks, I'll let Icono know, since he's the one thats doing the INI updates.

[The Siskoo]

Correct, the graphics problems are all to do with the video plugins, while the sound problem is with the core and RSP timing.
Okay, Core depends of the emulator so the sound depends of the emulator, right ?
By the way, I post a new non official ini for 1964 ^^

[mudlord]

Yes, it depends on the emulator itself, as well as the RSP plugin. A timing issue with MusyX, which is what this game uses for compressed sound, causes the speech glitches. It also causes glitches in some other games. To a degree, most of these errors are fixed in the current Mupen64 and PJ64 builds (private beta).

[The Siskoo]

Yes, it depends on the emulator itself, as well as the RSP plugin. A timing issue with MusyX, which is what this game uses for compressed sound, causes the speech glitches. It also causes glitches in some other games. To a degree, most of these errors are fixed in the current Mupen64 and PJ64 builds (private beta).
Okay thanks again to explain this :) I'm not confortable with all technical stuff ^^
I prefer to test with 1964 0.9.9. 'Cause I was a 0.9.9 beta tester, and I know this emulator. Mupen seems a nice emu too. I try to give the better compatibility ini to 1964. About PJ64 1.7, I don't know, I'm not a beta tester.

[mudlord]

I prefer to test with 1964 0.9.9. 'Cause I was a 0.9.9 beta tester, and I know this emulator. Mupen seems a nice emu too. I try to give the better compatibility ini to 1964.

Ah I see, best keep to your strengths. I think I might let Jabo know of these RE2 bugs, to see if he can fix them in the beta...

[The Siskoo]

I was interested to be beta testing PJ64, but donations are down ^^ I like beta testing (Satourne, Saturnin, Nestopia,...).

[mudlord]

Kool!

Anyways, can you test this config pls?


{134d9d76fe3f23da-45}
Name=DR.MARIO 64
AccurateTextureMapping=1
FastTextureCRC=1
NormalAlphaBlender=2
NormalColorCombiner=1
TexRectScaleHack
FrameBufferEmulation=10
RenderToTexture=3
ScreenUpdateSetting=5

[The Siskoo]

Seems perfect now. Fix a gfx error :)

[jackschmidt]

I haven't confirmed this but I'm having doubts with this being a breakthrough. I think UsedUcodes is just a stack of ucodes used during the game session.

Means, this one only saves the ucode data extracted and does nothing else. I'm going to test it on Super Mario 64 to see if I get similar results.

I haven't posted for a while. Been extremely busy with different stuff and I don't see myself making time for this yet, but I ran a test and it does confirm my fears.



Video::ProcessDListStep2
RSP::DLParser_Process
RDP::ExtractedUcode: 0
RDP::New ucode has been detected:
RSP SW Version: 2.0D, 04-01-96, ucode=0RDP_SetUcodeMap - ucode: 0


This is from Super Mario 64. That means this part of the code is really just nabbing the ucodes as they come. And hence, this isn't where the problem is. At least I don't think so.

[The Siskoo]

Emulator : 1964 0.9.9
Plugins : Mudlord's Rice Video Build (Stable) - VC6

Bakuretsu Muteki Bangaioh (J) [!] --> Big problem in game. FPS decrease and that's unplayable.

[Cyberman]

Emulator : 1964 0.9.9
Plugins : Mudlord's Rice Video Build (Stable) - VC6

Bakuretsu Muteki Bangaioh (J) [!] --> Big problem in game. FPS decrease and that's unplayable.
So... do you know if this is the plugin or emulation?
Is this different from other plugins (Rice or otherwise) performance with the same game?

Please be specific, it's very helpful IE if it normally is slow in said game, it MAY be something to do with the video plugin.

Mudlord
On a seperate subject how about a dummy mode for the plugin? IE it just displays what it's being told (IE status information), to do. This can eliminate slowdowns as being a problem with the plugin.
Or I could see if I can make an intermediating plugin that runs the other plugin (clear as mud right?) and logs statistics (FPS and performance information).

Erstwhile it's a busy weekedn BLEAH! I hate consultant work! :)

Cyb

[The Siskoo]

So... do you know if this is the plugin or emulation?
Is this different from other plugins (Rice or otherwise) performance with the same game?

Please be specific, it's very helpful IE if it normally is slow in said game, it MAY be something to do with the video plugin.

The problem comes from the plugin. With Ziggy, that's "perfect". ^^
What is IE (guess it's not Internet Explorer ^^) ?

[smcd]

What is IE (guess it's not Internet Explorer ^^) ?
http://www.getitwriteonline.com/archive/061801.htm id est (i.e.) latin for "that is" though i think e.g. might be more appropriate for his statement :P

[The Siskoo]

http://www.getitwriteonline.com/archive/061801.htm id est (i.e.) latin for "that is" though i think e.g. might be more appropriate for his statement :P
Thanks for the link and explanation :)

[mudlord]

I haven't posted for a while. Been extremely busy with different stuff and I don't see myself making time for this yet, but I ran a test and it does confirm my fears.

Its okay, I've been busy too (been at a university seminar this weekend, and having celebrations due to my very high academic grades I got awarded for last semester). Have you been poking around the ucode handling headers by any chance? I might have a looksee too, in the RDP/RSP handling, to see how they are done. I really should invest in time to spend more with this too. Atm, its all just been in my spare time, really, which I had little off this last week, due to Real Life(tm).


Mudlord
On a seperate subject how about a dummy mode for the plugin? IE it just displays what it's being told (IE status information), to do. This can eliminate slowdowns as being a problem with the plugin.
Or I could see if I can make an intermediating plugin that runs the other plugin (clear as mud right?) and logs statistics (FPS and performance information).

Erstwhile it's a busy weekedn BLEAH! I hate consultant work!


Well, there already is a OCD for DList, FPS, and other core information =] , maybe a log based on that?:unsure:

Stats logging, I should have done ages ago, but never got around to :saddam:
I should look into a proper log too, but I had that planned and it not quite made it in. I'm hoping to make a real update 10, when your "idea" has been finished :king: , though. I might add the logs in the later RC's (I think there will be quite a few more till the big 10)

[The Siskoo]

Emulator : 1964 0.9.9
Plugins : Mudlord's Rice Video VC6

Battlezone - Rise of the Black Dogs (U) [!] --> GFX problems (remanence ?!?)(pic 1)

[dartdude6]

When someone starts with the source code, can someone please put in a way to import/export character models?

[jackschmidt]

Its okay, I've been busy too (been at a university seminar this weekend, and having celebrations due to my very high academic grades I got awarded for last semester). Have you been poking around the ucode handling headers by any chance? I might have a looksee too, in the RDP/RSP handling, to see how they are done. I really should invest in time to spend more with this too. Atm, its all just been in my spare time, really, which I had little off this last week, due to Real Life(tm).


I've got some theories on how it works. Basically for every frame the ucode is extracted. There's an array called LoadedUcode, I think and this basically points to different functions for performing several rendering calls to be performed by the RDP/RSP. Check the source, you should see that every rendering function entry point is prepended with the RSP tag. The RSP render functions will eventually be broken down into Open GL calls or in your case, DirectX calls. So when DLParser_Process gets busy with the actual rendering on the posts I placed a couple of posts back, it should go through these loaded ucode functions when needed. These also seem to be referenced by hex digits on array. That's as far as I see right now.

For the TR 2 problem, I perceive this to be a possible cause of problem. Last Legion UX ucode and TR 2 ucode are assumed to be the same in terms of mapping, and I wonder if that is the case.

I hope this helps you a bit. I'm sorry I've not been helpful (nor productive at all). Real life is a real b*tch at times.

By the way, congrats on the high marks there.

[olivieryuyu]

I've got some theories on how it works. Basically for every frame the ucode is extracted. There's an array called LoadedUcode, I think and this basically points to different functions for performing several rendering calls to be performed by the RDP/RSP. Check the source, you should see that every rendering function entry point is prepended with the RSP tag. The RSP render functions will eventually be broken down into Open GL calls or in your case, DirectX calls. So when DLParser_Process gets busy with the actual rendering on the posts I placed a couple of posts back, it should go through these loaded ucode functions when needed. These also seem to be referenced by hex digits on array. That's as far as I see right now.

For the TR 2 problem, I perceive this to be a possible cause of problem. Last Legion UX ucode and TR 2 ucode are assumed to be the same in terms of mapping, and I wonder if that is the case.

I hope this helps you a bit. I'm sorry I've not been helpful (nor productive at all). Real life is a real b*tch at times.

By the way, congrats on the high marks there.

Dark Rift, TR 1 and 2, Last Legion UX are using the same microcode :-)

[jackschmidt]

Dark Rift, TR 1 and 2, Last Legion UX are using the same microcode :-)

I wonder if anyone of those were emulated 100%, because if not, that would mean the loaded ucode setup is suspect.

[Doomulation]

Dark Rift has always had emulation problems I think. Unknown or difficult ucode perhaps?

[mudlord]

I've got some theories on how it works. Basically for every frame the ucode is extracted. There's an array called LoadedUcode, I think and this basically points to different functions for performing several rendering calls to be performed by the RDP/RSP. Check the source, you should see that every rendering function entry point is prepended with the RSP tag. The RSP render functions will eventually be broken down into Open GL calls or in your case, DirectX calls. So when DLParser_Process gets busy with the actual rendering on the posts I placed a couple of posts back, it should go through these loaded ucode functions when needed. These also seem to be referenced by hex digits on array. That's as far as I see right now.

Ah I see. :) However, in the Windows port, we can also use OGL too.

I've heavily updated the debugger plugin, which might be of assistance in code tracing. Though, its only for Windows.


Unknown or difficult ucode perhaps?

According to the output from my updated debugger build, its a unknown microcode to the plugin. So, its not in the plugin's ucode tables.


I hope this helps you a bit. I'm sorry I've not been helpful (nor productive at all). Real life is a real b*tch at times.

By the way, congrats on the high marks there.

Its okay, this info certainly has helped me in understanding more on the internal structures, and how things tick. And thanks for the kudos, I appreciate it. I hope this semester is just as productive as the last. :)

[jackschmidt]

Ah I see. :) However, in the Windows port, we can also use OGL too.

I've heavily updated the debugger plugin, which might be of assistance in code tracing. Though, its only for Windows.


Debuggers are going to be extremely useful. My problem was when I started pouring so much effort on the plugin, I was focusing on the parts that could not possibly be wrong, like DLParser_process which, if it was incorrectly coded, would result in the plugin not working at all regardless of the game. I strongly believe the ucode mapping is incomplete at the very best case. Unfortunately in Linux, it's very difficult to debug this code without resorting to insane amounts of printfs. I've been contemplating on loading the RSP not implemented function definitions on the ucode map for ucode 19, but I am not entirely sure of the side effects of this. Chances are the plugin will crash, which isn't a problem for me. But finding the time to scrutinize the information is going to be difficult.

It would be a lot easier if I could find out what particular array indices of the ucode map is being referenced, as that would give a clear view of what the problem is. Alas, I am stuck again though.



According to the output from my updated debugger build, its a unknown microcode to the plugin. So, its not in the plugin's ucode tables.

Or at least partially defined. Without the code Rice put in on microcode 19, TR or other games for that matter would probably crash at first sight. At least that's what I think.



Its okay, this info certainly has helped me in understanding more on the internal structures, and how things tick. And thanks for the kudos, I appreciate it. I hope this semester is just as productive as the last. :)

School is a long way gone for me, and somehow I miss it. Thinking of going back to school for phd, but that's probably going to take some convincing for me to get back to school.

In any case, I think we should try to share as much info as we can. I'm obviously moving at an extremely painful pace with this. Sometimes, I can't stomach seeing the code, but at times it feels like it's worth a peek. Hopefully, you will be able to unearth more info and improve your plugin.

[mudlord]

I strongly believe the ucode mapping is incomplete at the very best case. Unfortunately in Linux, it's very difficult to debug this code without resorting to insane amounts of printfs. I've been contemplating on loading the RSP not implemented function definitions on the ucode map for ucode 19, but I am not entirely sure of the side effects of this. Chances are the plugin will crash, which isn't a problem for me. But finding the time to scrutinize the information is going to be difficult.

Hmm, well we could try adding the function defs and see what happens. No harm in that.



Or at least partially defined. Without the code Rice put in on microcode 19, TR or other games for that matter would probably crash at first sight. At least that's what I think.


True, some screens show, but the 3D models are still invisible, which is the main issue...


School is a long way gone for me, and somehow I miss it. Thinking of going back to school for phd, but that's probably going to take some convincing for me to get back to school.

Ah alright, I guess the motivation is what your going to get out of that PhD anyway, sometimes I wonder about stuff like that too, whether I'll do more education after university..Oh well.


In any case, I think we should try to share as much info as we can. I'm obviously moving at an extremely painful pace with this. Sometimes, I can't stomach seeing the code, but at times it feels like it's worth a peek. Hopefully, you will be able to unearth more info and improve your plugin.

Absolutely. Collaboration is definitely a good thing, especially on something as complex as this :). Some of the code is quite easy to digest, while others is quite cryptic. This has been a great learning experience for me and I definately aim to keep working on this, as Rice gave out the code for a reason.

[jackschmidt]

Hmm, well we could try adding the function defs and see what happens. No harm in that.

Exactly. But of course, we are treading unknown grounds here. If you check the loadedUcode array, not every index is defined with input. Quite curious on how this could turn out though.



True, some screens show, but the 3D models are still invisible, which is the main issue...

I am assuming the same is true for Dark Rift and co. Not too sure though.



Ah alright, I guess the motivation is what your going to get out of that PhD anyway, sometimes I wonder about stuff like that too, whether I'll do more education after university..Oh well.

Right. It takes a good deal of time to complete it and it's quite the money sucking endeavor. I think the university life was the best time of my life. You should enjoy it too. ;)



Absolutely. Collaboration is definitely a good thing, especially on something as complex as this :). Some of the code is quite easy to digest, while others is quite cryptic. This has been a great learning experience for me and I definately aim to keep working on this, as Rice gave out the code for a reason.

I 100% agree. This is a difficult piece of code and hopefully we can figure this thing out.

[modifier314]

Hi, I'd like to request a feature. Specifically, 3D anaglyph rendering. Basically, it renders everything twice, once using only red, with the camera slightly to the left of its actual position, and then again using only blue and green, with the camera slightly to the right of its actual position. Thus, it takes twice as much graphics power, but gives the illusion of depth perception. It also requires some cheap paper 3D glasses. There are websites that will mail them to you for free, if you send them a self addressed stamped envelope.

I'm not too familiar with the underlying concepts of N64 emulation, so I don't know how to do this in a graphics plugin. Here's how it would look in a general OpenGL program though:

If the draw function in your non-anaglyph program looks like this:


glClear(GL_COLOR_BUFFER_BIT);
glClear(GL_DEPTH_BUFFER_BIT);

DrawPolygons();

SwapBuffers(hDC);


Then the anaglyph version would look something like this:


glClear(GL_COLOR_BUFFER_BIT);

//left eye
glClear(GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glPushMatrix();
glTranslatef(+0.1f, 0.f, 0.f);
glColorMask(GL_TRUE, GL_FALSE, GL_FALSE, GL_FALSE);

DrawPolygons();

glMatrixMode(GL_PROJECTION);
glPopMatrix();

//right eye
glClear(GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glPushMatrix();
glTranslatef(-0.1f, 0.f, 0.f);
glColorMask(GL_FALSE, GL_TRUE, GL_TRUE, GL_FALSE);

DrawPolygons();

glMatrixMode(GL_PROJECTION);
glPopMatrix();

SwapBuffers(hDC);

[mudlord]

Thats quite a interesting feature, I'll have to take a deeper look in the OGL side of things if I want to make a implementation based on that code..I know it will need to be modified somewhat heavily, though.

[The Siskoo]

With the last Release, there is an error message : need to get a MSVCP60D.dll, MSVCRTD.dll. RiceVideoDebugger.dll is the guilty ^^

So could you add these 2 dll in the next release ?

By the way, I tested the former games and I can't see no difference.

I saw my name in credits, thank you :) (could you change The Siskoo --> Benjamin Siskoo).

[jackschmidt]

Hi, I'd like to request a feature. Specifically, 3D anaglyph rendering. Basically, it renders everything twice, once using only red, with the camera slightly to the left of its actual position, and then again using only blue and green, with the camera slightly to the right of its actual position. Thus, it takes twice as much graphics power, but gives the illusion of depth perception. It also requires some cheap paper 3D glasses. There are websites that will mail them to you for free, if you send them a self addressed stamped envelope.

I'm not too familiar with the underlying concepts of N64 emulation, so I don't know how to do this in a graphics plugin. Here's how it would look in a general OpenGL program though:

If the draw function in your non-anaglyph program looks like this:


glClear(GL_COLOR_BUFFER_BIT);
glClear(GL_DEPTH_BUFFER_BIT);

DrawPolygons();

SwapBuffers(hDC);


Then the anaglyph version would look something like this:


glClear(GL_COLOR_BUFFER_BIT);

//left eye
glClear(GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glPushMatrix();
glTranslatef(+0.1f, 0.f, 0.f);
glColorMask(GL_TRUE, GL_FALSE, GL_FALSE, GL_FALSE);

DrawPolygons();

glMatrixMode(GL_PROJECTION);
glPopMatrix();

//right eye
glClear(GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glPushMatrix();
glTranslatef(-0.1f, 0.f, 0.f);
glColorMask(GL_FALSE, GL_TRUE, GL_TRUE, GL_FALSE);

DrawPolygons();

glMatrixMode(GL_PROJECTION);
glPopMatrix();

SwapBuffers(hDC);


It's an interesting take, but that may create as much visibility as 3D Hot Rally did for the Family Computer. Wouldn't you need to have the goggles to make this illusion work?

The underlying concept is easy to understand. The implementation is difficult to pull off because the rendering functions are scattered throughout the source. It's a nifty feature and something worth considering though. There's definitely a graphical performance hit.

[mudlord]

By the way, I tested the former games and I can't see no difference.

Well, Icono hasn't given me his updated INI for them yet, he told me he got some more games working right, but I didnt get it unfortunately.


With the last Release, there is an error message : need to get a MSVCP60D.dll, MSVCRTD.dll. RiceVideoDebugger.dll is the guilty ^^

So could you add these 2 dll in the next release ?

Sure, no problem. I'll add them into the installer. I might repack it now.


I saw my name in credits, thank you (could you change The Siskoo --> Benjamin Siskoo).

Sure, no problem too.


Off topic: I also noticed your credits in the Nestopia changelog for beta testing the early builds.


The implementation is difficult to pull off because the rendering functions are scattered throughout the source.

Yep definately, I had similar troubles with this when I first added a prelim. implementation of custom aspect ratios.

[Doomulation]

With the last Release, there is an error message : need to get a MSVCP60D.dll, MSVCRTD.dll. RiceVideoDebugger.dll is the guilty ^^

So could you add these 2 dll in the next release ?

Those are debug dlls and are illegal to distribute under Microsoft license. You'll need to purchase Visual Studio to get those dlls.
I image this is a simple mistake on the developer's part, since this is a debug build and not a release build (exe was linked against the debug library).

[mudlord]

I image this is a simple mistake on the developer's part, since this is a debug build and not a release build (exe was linked against the debug library).

Phew, thanks for letting me know! I better change it ASAP to not use those libraries..

EDIT: The Siskoo, can you try this please?

[The Siskoo]

Well, Icono hasn't given me his updated INI for them yet, he told me he got some more games working right, but I didnt get it unfortunately.

Sounds good :).



Off topic: I also noticed your credits in the Nestopia changelog for beta testing the early builds.
Martin is a great developper and Nestopia is an excellent Nes emu.
Take a look in the 1964 doc too ^^


Those are debug dlls and are illegal to distribute under Microsoft license. You'll need to purchase Visual Studio to get those dlls.
I image this is a simple mistake on the developer's part, since this is a debug build and not a release build (exe was linked against the debug library).

Ok, that was the goal of my report too ^^


Phew, thanks for letting me know! I better change it ASAP to not use those libraries..

EDIT: The Siskoo, can you try this please?

same problem, need dll

[mudlord]

Ok, I'll not redistribute the required DLLs. To save my skin, the devs should have VC already if they want to use the debugger plugin.

[Doomulation]

You should be able to compile against the retail library. I admit it's been a long time since I used MSVC6, so I don't remember much, but in project settings, compiler settings (or maybe linker?) I believe, you can choose to what runtime library you want to link against.
In Visual Studio 2007, you can choose Multi-threaded and Multi-threaded DLL, plus the Debug versions of these. Debug is only good for developers when building the DLL, when distributing to people who do not have Visual Studio installed, you should link against the non-debug library. This is usually done with the Debug/Release configuration of your solution/project.

Have you forgotten this or are you simply not used to MSVC6? The non-debug runtime libraries are find to distribute, but not the debug libraries.

[mudlord]

You should be able to compile against the retail library. I admit it's been a long time since I used MSVC6, so I don't remember much, but in project settings, compiler settings (or maybe linker?) I believe, you can choose to what runtime library you want to link against.

I have already done this. The debugger plugin is linked now against the multithreaded DLL version of the runtimes, and not the debug ones.

[Cyberman]

When someone starts with the source code, can someone please put in a way to import/export character models?
May I ask a simple question, do you have any idea what you are talking about? Sad to say that is one ugly ball of wax since the models et al are not the same thing as a texture (and by coincidence it's likely possible to do but I don't believe it to be practical). How do you plan on animating any new models is the first thing you should consider.
Unless you hack the original ROM data this is just too much work to be worth any effort. Then you may get into the same issues that have been croping up with yaz0r and his model/texture ripping utils. (yaz0r droped all the forums and distribution of his tools as a result of kids ripping textures and models that are copyrighted and uploading them to sites for distribution THAT is BLATENTLY ILLEGAL PERIOD). So this is close to one of those pitch black areas that no longer covers emulation at all. I personally would NOT put such a feature in because of this type of immature behavior sorry I don't think you should ask for that kind of thing again I can see people using LOZ models from Wii games already. C&D's will happen (those are cheap for the company and no one wants the hastle of fighting such things).

IF you wish to do it, go ahead, but don't ask someone else to jepardize there work and future for something people will not conduct themselves properly with. "Oh yeah they are original models I ripped from Twilight Princess!" there is your reason why this isn't a good idea.

Cyb

[mudlord]

When someone starts with the source code, can someone please put in a way to import/export character models?

Have to agree with Cyb on this. I don't want to get in legal crap for something I do in my spare time as a side project. I cannot afford legal battles atm with Nintendo and other mobs, so I'd have to say no. I personally just can't take the risk.
Plus, there's the loads of ethical reasons Cyberman also elaborated on.

.......

[squall_leonhart]

lol, don't wanna get pwned by a mesh :P

[mudlord]

lol, don't wanna get pwned by a mesh

Heehehehehe, I just knew you'll do a witty remark like that.

Seriously, I don't want to get into trouble with Nintendo, over what some idiots do with releasing meshes and models. I can't afford the risks or troubles.

[mudlord]

bump.

Just a notice, now got a mirror and SVN server on BountySource.

[Cyberman]

Well mudlord I know you aren't rich etc. :)
This might give me time to play catchup and get a recent chunk of code from the SVN server.

Cyb

[mudlord]

This might give me time to play catchup and get a recent chunk of code from the SVN server.


Indeed :king:

[Cyberman]

Ok I will try the new source tree and see what I need to install to get it to compile (getting the SDK's to install under win2K is possible MS is really being silly these days but what else is new with them? See Vista see OSX copy DOH).

Anyhow OpenGL 3.0 spec is soon to be released it is is not a MAJOR change to the Spec just some pruning of no longer used features etc. Although I am a little leery of removing the OpenGL 'begin' and 'end' bits. I'm not exactly sure what this will acomplish however I suspect that they assume that everything is running on a machine so damned fast that the dynamic recompiler of the intermediate code sent to the GPU will make up for this?

On lower end machines IE emeded systems this is a completely different matter. EGL 2.0 spec is out too. Oh well things go weird often with standards. I still have yet to get my OGL code functioning with BCB myself. At least I don't need that for work! :)

Cyb

[mudlord]

Ok I will try the new source tree and see what I need to install to get it to compile (getting the SDK's to install under win2K is possible MS is really being silly these days but what else is new with them? See Vista see OSX copy DOH).

Hehe, okay. All you should need is the headers and libs from the DX8.1 SDK if you want to compile the stable version. Development one needs the DX9 one.


Anyhow OpenGL 3.0 spec is soon to be released it is is not a MAJOR change to the Spec just some pruning of no longer used features etc. Although I am a little leery of removing the OpenGL 'begin' and 'end' bits. I'm not exactly sure what this will acomplish however I suspect that they assume that everything is running on a machine so damned fast that the dynamic recompiler of the intermediate code sent to the GPU will make up for this?

I havent read up on the new OGL developments to be honest, so OGL 3.0 is quite new to me. I would imagine they'll still keep compatibility, hopefully, with older OGL versions, instead of taking the DX10 route of completely breaking backwards compatibility for the sake of extra things....


On lower end machines IE emeded systems this is a completely different matter. EGL 2.0 spec is out too

I heard that the PS3 uses OGL ES for graphics. Still, im not too familiar with ES.

[Cyberman]

Hehe, okay. All you should need is the headers and libs from the DX8.1 SDK if you want to compile the stable version. Development one needs the DX9 one.Doh.. I can use an older version then. I feel silly. It's better for me to beat on the stable version and then reintegration can be handled later. I'll do some adjustments and see what I can get going on my system (as slow as it is).

I havent read up on the new OGL developments to be honest, so OGL 3.0 is quite new to me. I would imagine they'll still keep compatibility, hopefully, with older OGL versions, instead of taking the DX10 route of completely breaking backwards compatibility for the sake of extra things....I hope not as well. DX breaking is primarily a comercial reason. MS does not want to leave control of all that to other people so that is the route they've taken. It's quite the political move.

I heard that the PS3 uses OGL ES for graphics. Still, im not too familiar with ES.OGL ES is a much more simplified standard. IE it moves to a more straight foward path for handling things instead of the 'it depends on the OS' method for normal OGL. In simple terms it doesn't have as many complicated mechanisms for determining features (IE all the wonder extension probing) that MIGHT be implemented.
"Royalty free 2D/3D API consisting of well-defined subset profiles of desktop OpenGL" is the best description I've found. In summary it has well defined functionality which is what is needed in embeded apps (IE no surprises).

As for wither the PS3 supports it or not, well I don't know to be honest.


Cyb

[mudlord]

It's better for me to beat on the stable version and then reintegration can be handled later. I'll do some adjustments and see what I can get going on my system (as slow as it is).

Alright, sounds cool.


DX breaking is primarily a comercial reason. MS does not want to leave control of all that to other people so that is the route they've taken. It's quite the political move.

Yeah, and also it helps force adoption of Vista. I intend to steer clear of it as much as possible tho for gaming, since DX9 for me is more than enough graphics-wise, and I don't need to blow money and time on DX10, when a lot of the techniques it uses, like procedural content generation, can be done already..


As for wither the PS3 supports it or not, well I don't know to be honest.

From my research, PSGL is the API it uses. A subset of that is indeed OpenGL ES.

In other news, I am acquiring Visual Studio .NET 2003 Professional. I intend to try out some things with it, as it is the original compiler Rice used when he was coding.

[Cyberman]

Alright, sounds cool.
I hope so (LOL). Knowing my good fortune thus far I'll have to spend half a day getting the thing to compile the base code. (sigh)


Yeah, and also it helps force adoption of Vista. I intend to steer clear of it as much as possible tho for gaming, since DX9 for me is more than enough graphics-wise, and I don't need to blow money and time on DX10, when a lot of the techniques it uses, like procedural content generation, can be done already..Welcome to Steve Balmar, the man who killed Silicon Graphics in 2 years. I'm not sure Vista will be adopted wholesale, things are definately not looking up as much as MS wanted. As for procedural content generation, that sounds VAGUELY like OpenGL version 1.0 (sorry couldn't help but snicker how MS 'adopted' the features of OGL into DX over time). I think MS still has a seat on the OpenGL board oddly.


From my research, PSGL is the API it uses. A subset of that is indeed OpenGL ES. They made there own variant? (How very Sonyesq) Just like they adopted Linux but the variant available for the PS2 was too crippled to do real developement on (IE you couldn't do squat toward game developement with it other than for someone who had Sony Linux for the PS2).


In other news, I am acquiring Visual Studio .NET 2003 Professional. I intend to try out some things with it, as it is the original compiler Rice used when he was coding.I'm wondering if it will have the same broken things as VS2005? (sorry I'm pessimistic today). Are you going to port your latest code branch to using that environment or start with a 'known' set of code that compiles under it?

Erstwhile time to fire up SVN and get the stable code branch.

Cyb

[mudlord]

I hope so (LOL). Knowing my good fortune thus far I'll have to spend half a day getting the thing to compile the base code. (sigh)

That sucks :(. I remember having the same issues when first starting work on this.



Welcome to Steve Balmar, the man who killed Silicon Graphics in 2 years. I'm not sure Vista will be adopted wholesale, things are definately not looking up as much as MS wanted. As for procedural content generation, that sounds VAGUELY like OpenGL version 1.0 (sorry couldn't help but snicker how MS 'adopted' the features of OGL into DX over time). I think MS still has a seat on the OpenGL board oddly.

True, I know one thing, I wont be touching Vista for a very long time....Mainly I would need a whole new PC to do some decent dev work with it at a zippy pace. Plus, I don't like the whole driver fiasco atm, especially with OGL performance. Procedural content generation has been around ever since the demoscene started. Its funny how MS only started to really pick up on it in DX10 and thier geometry shaders, when demoscene stuff use OGL, software rasterisation (case in point: "Heaven Se7en") or DX9 to do the same thing.





They made there own variant? (How very Sonyesq) Just like they adopted Linux but the variant available for the PS2 was too crippled to do real developement on (IE you couldn't do squat toward game developement with it other than for someone who had Sony Linux for the PS2).

Yep, they use a graphics API with a subset which is based on OGL ES.



I'm wondering if it will have the same broken things as VS2005? (sorry I'm pessimistic today). Are you going to port your latest code branch to using that environment or start with a 'known' set of code that compiles under it?

Erstwhile time to fire up SVN and get the stable code branch.

Cyb




a) Nope, it seems with the compiler switch, everything behaves like it should, just like the last official beta. All z problems that were caused by compiler usage have been fixed, and now finally, emulation quality is exactly the same as Rice's last plugin. So, my builds now have improved on it, with the built-in BMGLib etc...See the attached build as proof :bouncy:

b) There was already project files left over by Rice, so it was a matter of simply fixing the preprocessor commands to use DX8 in the MSVC 7.1 project files, and viola...

C) Just a note, I cleaned up the SVN tree a bit, it should make things a lot clearer to do.

:)

[squall_leonhart]

i was chatting to Mudlord today,.. and we found that RiceVideo is compatible with PJ64 1.7,.. only when using the Opengl output..... it seems it only hardlocks the screen when using Direct3D.... now if only the framebuffer effects worked in OGL....

also, is there a reason why Rice Video renders so wierd?.. take a look at the mirror shield in OoT and you'll see what i mean... take a look at the one in MM as well coz im sure it has some iregularities as well :\

Majora's mask is missing the blur effect used when your on the moon, and the distance cut off seems to low.... the kids running around the tree appear further way on Jabo's plugin then on Rice Video

[The Siskoo]

GT 64 Championship Edition (E) and (U) [!] --> check Increase TextRect Edge

[mudlord]

GT 64 Championship Edition (E) and (U) [!] --> check Increase TextRect Edge

Thanks :)


now if only the framebuffer effects worked in OGL...

Mmmhm, and if I can get them to work at a decent speed...and rewrite it...:plain:


it seems it only hardlocks the screen when using Direct3D

Hmm, and I read your logs on the PJ64 beta forum. Suffice to say, its really strange. =]


take a look at the mirror shield in OoT and you'll see what i mean... take a look at the one in MM as well coz im sure it has some iregularities as well

I know Jabo did quite a bit of work recently with texture LOD in Zelda and the Rare Ltd written games, not sure if the mirror shield is a use of it.


ajora's mask is missing the blur effect used when your on the moon, and the distance cut off seems to low.... the kids running around the tree appear further way on Jabo's plugin then on Rice Video

Hmm, well of course the blur is missing.So your saying theres a issue with drawing distance?

[Cyberman]

Note on apparent distance etc. Do not use Jabo's as the 'most' acurate or another. The real comparison is how it is on the real N64. If you have the game and the console take the time to look at the specific point of the game you are wondering about if you can before saying relativistic things such as "it looks too far away" or "it looks too close". It may have been like that in the original game, if so tweaking ones plugin for subjective things is like comparing ones measurements in feet with those in meters DIRECTLY (IE no conversion) it will definately distort things way out of proportion.


Cyb

[squall_leonhart]

i use Jabo's as the basis as it is the closest to actual N64 rendering in regards to Majora's Mask, on both the N64 and Jabo's the Children become visible from further away then on RV.

[Cyberman]

All right let me put it a different way. Do you know what the scene is supposed to look like? IE not in Jabo's plugin but in the original game. If not.. you are making a flawed comparison, it's the same as saying a yard is a meter or visa versa. You have to have a standard by which you measure things, and in this case it's the N64 system. Jabo's plugin is emulating the N64 hardware, however it is not the N64 hardware. All graphic plugin's have to compare with the visual output of the N64 system in the end, because that is the standard. Therefore compare it with images from the N64 not Jabo's plugin, then you will not be making a subjective comparison. In the current state, no one knows weather what you are talking about is a bug in the version of Jabo's plugin you have or in the version of mudlord's plugin you have.
Be sure to match the scenes correctly also, just a bit of skew can make things look odd easily (perspective distortion etc.)

The main thing to keep in mind is that mudlord could take days or weeks to try and figure out what might be the problem, when it might not be a problem to begin with. This is why you make realistic and acurate comparisons and not subjective ones. (Testing software is an art form in itself and if you think about it that is what is going on here.)

Cyberman

[squall_leonhart]

what part of

on both the N64 and Jabo's the Children become visible from further away then on RV.

did you miss?

lol, i know what it looks like on the N64, and the children appear in the distance from further away on the N64 then on rice videos... theres also the funky blur effect and crazy drug induced psychosis thing going on there....

[Cyberman]

I guess I did miss LOL sorry about that. Screen shots to compare (IE N64 scene and RV scene) would be more helpful than anything. That is what I was really getting at. It could be that the applied affect has something to do with the visually percieved fade in distance.

Cyb

[squall_leonhart]

hey, sorry if i seemed like i was being rude then, i didn't mean it like that.

[mudlord]

Back,

sorry I took so long, being having massive problems getting into the site, had to resort to a proxy service for access. (which is odd, as the site never had problems like this before)

Anywayz.....

[Cyberman]

Because of numerous systems and configurations and people speaking of problems about the plugin and the possibility of obfsucation of what the real issue.

How about a little button the plugin adds in the configuration menu that dumps:
All Rice Related Video settings (in a neat well defined manner :D)
All System Related Settings that might affect the plugin (GFX card version of D3D OS information etc.)
All Emulator Related Settings (anything that is possible to get at least) that might affect it as well.
to the clip board then they can paste it into a message so that people can dicipher what the problem.

Cyb

[mudlord]

How about a little button the plugin adds in the configuration menu that dumps:
All Rice Related Video settings (in a neat well defined manner )
All System Related Settings that might affect the plugin (GFX card version of D3D OS information etc.)
All Emulator Related Settings (anything that is possible to get at least) that might affect it as well.
to the clip board then they can paste it into a message so that people can dicipher what the problem.

Bout time I actually added this. You suggested this a while back, bout time its finally added.

[mudlord]

I'm back...been busy with some real life issues.

Anyways, currently I am refining the texture pack format.

I am working to tweak out the CI BMP code, since RGBA PNG seems to replace it quite well.....The results at this stage are quite good, though, with no issues as of yet.

[Cyberman]

Wait you are letting Reality interfere with your emulation programming!? oh my. LOL.
Ahem :)

It's cool so you are repacking the images? You are considerning just PNG and JPG right (no indexed BMP's). That should work fine for my plans.

Cyb

[mudlord]

Wait you are letting Reality interfere with your emulation programming!? oh my. LOL.

Mmmhm. Its a travesty, I know. Proves the point though that people have real life jobs, university, or other personal commitments besides working on thier hobbies :P.


Well, currently, I am making the code use only JPG and PNG, so that means BMP's are being recompressed into PNG, which of course is lossless. Which means, all debugger dumped images too will also be in RGBA PNG.

I have also started to add preliminary support for 8x texture resizing. Currently on my 256MB Radeon X1650 Pro, it works extremely well, though I didnt do any more testing besides on SM64 though.

[mudlord]

Back,

I uploaded 6.1.3.1 which includes 8x and 16x texture rescaling.

Sorry for not being on here lately to give progress reports.

[ggab]

hi mudlord,

did you post something HERE, related to the 4bit CI texture's bug in original Rice's plugin source as Gonetz posted on emuxhaven?


Gonetz's quote:
Marvelous thing I just discovered.
There is a bug in RiceVideo, in palette CRC calculation. In brief – a wrong palette is taken for CRC. As the result - a wrong CRC. Since all texture designers used that CRC, I have to emulate this bug to make texture loading. Marvelous.

-

An explanation of the situation with palette CRC bug in RiceVideo:
The bug affects only 4bit CI textures. When “Full TMEM emulation” option is off, RiceVideo takes wrong, I even can say random, palette to calculate CRC. The consequences can be very bad. CRC becomes content-dependent. That is, the same texture can get different CRC in different situations. Besides, if RiceVideo was used in “Full TMEM emulation off” mode to dump textures, created pack will not work when this option is on, and vice versa.
There is no easy way to fix it. That is, the bug itself is easy to fix, I can point on exact places in the code. However, to fix existing texture packs it is necessary to use the fixed version to dump all textures again, and rename created hires textures using correct CRC. This hardly will be done.
The only thing, which can be done – warn all texture designers not to set full tmem emulation off when dumping textures.
As for GlideHQ, I’m trying to reproduce that behavior in my code and I’m partially succeeded. However, some packs still not work. Probably, it’s not the only rake hidden in RiceVideo code.


My comment:
i hope all the N64 community adopt the best solution found to solve the 4bit CI texture's bug :)
Gonetz's suggestion of "set full tmem emulation ON when dumping textures" seems to be a great idea, anyway...

Thanks!


Edit:

there is a big problem with the re dumping textures scenario...

Question: Is there an option to dump all the textures from the ROM, and not just the ones that are loaded?
Answer: No, not unless you hack the ROM. You must play through the game to dump the textures. There is no other way to do so unless you hack into the ROM. That's about it.
~Cyberman~


i've forgot you need that!!!!!

what to do???? :S

[mudlord]

hi mudlord,

did you post something HERE, related to the 4bit CI texture's bug in original Rice's plugin source as Gonetz posted on emuxhaven?

No.

All I posted was that CI BMPs are the only real needed format for BMP support, since PNG handles everything else.


My comment:
i hope all the N64 community adopt the best solution found to solve the 4bit CI texture's bug
Gonetz's suggestion of "set full tmem emulation ON when dumping textures" seems to be a great idea, anyway...

Thanks!


Well, this bug should be stamped out imo. Though its a worry that complete texture packs have to be redone for this one bug.


That is, the bug itself is easy to fix, I can point on exact places in the code.

That would help me out a lot if Gonetz can show me whats wrong, since he knows exactly where the errors are and what to fix. That way, since he's solution, which seems logical, can be added, if its the right thing to do, given the current situation.


Gonetz's suggestion of "set full tmem emulation ON when dumping textures" seems to be a great idea, anyway...


Cool, in my docs I will note it down, if he wants to just this solution.

[CrashDance22]

I was just about to re-post my question here, but noticed Cyberman already did. Thanks!

[diamond_rust]

So has anyone started a 8x/16x texture pack yet.....?

I'd buy that for a dollar!

:-p

[mudlord]

Sorry for the long absence..been in hospital mainly, due to a Series of Unfortunate Events(tm).

Unfortunately, I need to have more blood & pathological tests tomorrow than I had today, so I dunno how long I'll be away. And on top of that, I have a lot of university work to do also when I am feeling better (luckily, I made special arrangements with CSU, so that university work won't be affected by my absence due to medical reasons).

Anywayz....


So has anyone started a 8x/16x texture pack yet.....?

I'd buy that for a dollar!

Yep, a talented texture artist has already started with a 8x/16x pack. You'll need quite a beefy PC to run it though. :bouncy:

[diamond_rust]

That totally blows chunks about the medical situation. :-(
With any luck there'll be a revolution in optical and/or quantum
computing sometime soon. That'd give medical research a huge leap
in computing power.


Whoops, getting off the subject a bit.

Totally awesome about the suped-up tex's.
Hopefully either my OC'ed GeForce Go 7900GS or 8600GTS can handle
it; I can't imagine how Zelda OOT with 16x textures would look on my
50in HDTV at 1920x1080............Yowza !!!!

[Cyberman]

Yuck mudlord get healthy fast.

As for HR texture packs using 8x and 16x .. that should be in a different thread and likely in the HR TP forum (sub forum under 1964).

Cyb

[mudlord]

As for HR texture packs using 8x and 16x .. that should be in a different thread and likely in the HR TP forum (sub forum under 1964).

Yep,though I do honestly now see the need for a seperate HR texture forum, since Jabo's and Gonetz's plugins support HR textures.....

[Cyberman]

Seems that way. I'm sure someone is discussing it somewhere. :D

Cyb