Rice's Plugin Source <discussion>

[squall_leonhart]

suggestion.
change renderer method without having to end the rom.

...i dunno if this is possible under any emulators other then PJ64 1.7 though

 

[mudlord]

I am somewhat very displeased with you posting in here. Didn't you read the message? It said "DO NOT POST HERE". It says so for a reason. Next time, post in the discussion thread, and NOT this one. I really wonder sometimes why humans explictly IGNORE instructions, when they are told not to do something, and instead they do what they are not supposed to do. I really wish I didn't have to waste my breath saying this, I got loads of better things to do instead of trying to talk to one person who ignores what I and others have asked.....

As for the request on ingame renderer switching....If it only possibly will work on 1.7 beta, I don't see the point. I'm not going to do something just for one emulator, that would mean Mupen and 1964 would have to be capable of the same thing. On top of that, I'm very happy how it is. I don't see the need for it to be changed.

 

[squall_leonhart]

First this thread will be HEAVILY moderated. Do NOT post problems with the plugin here. That is the DISCUSION thread. New Features might be OK this is primarily to be a one stop thread to get the plugin from. (first part of thread) any addition will be specifically about features implemented or suggested so it's in one place. Discussion is for bugs. I will move anything about a bug to the discussion thread, unless it's by mudlord.


Anything about USING the plugin (this is not a feature) goes in discussion. This is entirely about developement and suggestions. These questions will be moved to discussion. The old thread is now the discussion thread.

Have fun (I've stickied this thread too).

Cyb

mine was a suggestion.

you should ask cyberman to change his post if you don't want suggestions in there. i would'nt have posted there if cybermans post didn't say i could.

 

[mudlord]

Oh alright, thanks for letting me know. I shouldnt have flown off the handle, but when people do stuff against my wishes, I get very pissed off...Especially when I asked nicely first . And plus, it wastes my time when I could be doing more important things.

Now thats out of the way, I thnk that doing your request would involve quite a fair bit of renderer changes. It might be possible to do this on other emus, not totally sure at this stage.

 

[Cyberman]

You did neglect to read the subject line . I thought I had adjusted the message as well, ahh well life goes on I'll fix it, sorry about that.

All prior suggestions have been in this thread (aspect ratio option for example and better control over file dumping etc.)

mudlord need to try an SVN checkout soon,you don't plan on images > 2gigs in size do you? (inside joke)


Cyb

 

[squall_leonhart]

You did neglect to read the subject line . I thought I had adjusted the message as well, ahh well life goes on I'll fix it, sorry about that.

All prior suggestions have been in this thread (aspect ratio option for example and better control over file dumping etc.)

mudlord need to try an SVN checkout soon,you don't plan on images > 2gigs in size do you? (inside joke)


Cyb

i read the subject line, but your post seemed to negate it :/. so i just followed your post.

Ahwell,... these things happen :/

Oh alright, thanks for letting me know. I shouldnt have flown off the handle, but when people do stuff against my wishes, I get very pissed off...Especially when I asked nicely first . And plus, it wastes my time when I could be doing more important things.

Now thats out of the way, I thnk that doing your request would involve quite a fair bit of renderer changes. It might be possible to do this on other emus, not totally sure at this stage.

the plugin might be able to handle the change internally, it will likely require a massive rewrite of the way the plugin handles the api and graphics process

 

[Cyberman]

mudlord does the plugin handle it's own configuration or does it pass this job to the emulator? I know you can change plugin settings for graphics on the fly with the playstation by running PSXemucheater which I believe shuts down the graphics plugin and then sets it's configuration then restarts the plugin. IE the settings ocure outside the actual plugin.
So a QUICKIE way to implement this would be to use a Passthrough plugin that becomes the big brother of the graphics plugin instead of the emulator.
As long as you can invoke said big brother plugin with a key sequence (ala CTRL-K in the cheat software for playstation emulation). It can shut down the real GPU plugin and invoke it's configuration menu, then unload and reload the DLL with the new settings. Reconfiguration on the fly without that horrible aftertaste

Cyb

 

[squall_leonhart]

aye, exactly, but i think it might be possible without a dummy loader, although i don't know zot about programming, theres no reason its not possible... lol, VBA for instance can change from ddraw > d3d > opengl without requiring a restart, it just reinit's the display thread.

 

[mudlord]

mudlord need to try an SVN checkout soon,you don't plan on images > 2gigs in size do you? (inside joke)

Heheheheh, its rabbiddiety's server. I uploaded my latest non alpha code to the main thread, as well as the brand new installer system.

mudlord does the plugin handle it's own configuration or does it pass this job to the emulator?

The plugin uses its own management system for configuration. This is one of the main things I am currently rewriting for the next builds (I might do a quick alpha for ya)...The emu just intercepts the calls to the video plugin, but I'm not sure how zilmar does his changing plugin code for PJ64 1.7 (allows for plugins to be changed on the fly)

aye, exactly, but i think it might be possible without a dummy loader, although i don't know zot about programming, theres no reason its not possible... lol, VBA for instance can change from ddraw > d3d > opengl without requiring a restart, it just reinit's the display thread.

Depends really on the threading, Rice left over some threading code for the plugin tho....but it seems quite incomplete.

 

[mudlord]

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

 

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