Rice's Plugin Source <discussion>

[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

 

[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