New LLE RSP Plugin (accurate, fast but untested?)

[Pau]

I've heard you are now working together with these mupen64plus sellouts. I will not put any of my work into the pockets of these guys

[shunyuan]

Originally Posted by FatCat

You are free to distribute your version anyway, post about it etc. as long as my legacy isn't uncredited.

I don't plan to distribute the modified RSP plugin since I know nothing about the RSP emulation and don't know how to fix the bugs of it (if any).

Originally Posted by FatCat

So, what you're saying is,
- You'll use the exact same gfx plugin,
- The exact same emulator (stick to Project64 2.0 or 1.6 for both),
- but my original "rsp_mle.dll" has different HLE gfx than zilmar's RSP 1.7.0.7 HLE gfx for Resident Evil 2?

I know you can set HLE gfx in the config with the version you wrote but please just this time try to test with my original rsp_mle.dll to see if maybe it could be a bug with how you implemented the config, just trying to rule as much out as we can.

if so, where can I see the different gfx in re2?

Go back to the topic, I tested with your build of rsp_mle.dll, and I got the same result for both project64 2.0 and 1.6.

So would you mind to take a look about it and let me know what the differences between your and zilmar's plugin for GFX HLE handling.

[HatCat]

Yes suanyuan it seems you're right; I'm having a look at why the GBI processing is so different on both builds.
I was unaware there could be a bug with the simple HLE redirection, looking into it now.

Originally Posted by Pau

I've heard you are now working together with these mupen64plus sellouts. I will not put any of my work into the pockets of these guys

pokefan999, I presume.

I have never worked with Mupen64Plus.
I did however get pressured into talking with Mupen64++ developer okaygo and involved in IRC chats etc. that way.
Mupen64Plus effectively was born because okaygo lost his other source code, so I didn't participate.

And if your idea of determining whether I have anything to do with them or not is accusing me outright and seeing how I react, I suppose you don't really have anything to contribute; that's okay.

The purpose of this thread is testing. The only thing I really need to see is very rare corner cases that will render a debugging message to the DLL, or bug reports. There is not a whole lot of other things to do with the RSP, you may find.

[HatCat]

suanyuan, seems Resident Evil 2 initializes the OS SP task structure with zeroed data sent to *(DMEM + OS_TASK_OFF_DATA). How exactly this pointer is used I don't know since I don't work with HLE much, but neither Glide64 nor Jabo's HLE Direct3D seem to like it.
That's why Hacktarux's RSP interface shelled out of older mupen64 and Project64 1.6/1.7 RSP (but not pj64 1.4 RSP which still has the bug you reported) check to see if this pointer is 0 to know how to HLE it.

So I just needed to factor in an extra check before attempting to rely on the external GBI command list handling.

    switch (*(unsigned int *)(RSP.DMEM + 0xFC0))
    { /* Simulation barrier to redirect processing externally. */
#ifdef EXTERN_COMMAND_LIST_GBI
        case 0x00000001:
            if (*(unsigned int *)(RSP.DMEM + 0xFF0) == 0x00000000) break;
            if (RSP.ProcessDList != NULL)
                RSP.ProcessDList();

You should compile that line of code in for the quick fix.
I'll add it in the next release if I can get people to report at least one LLE bug or debug exploit message with my LLE plugin.

I was unaware HLE redirection from the RSP could have a bug since it's incredibly simple code...there was little documentation or examples of how to request a HLE operation that I just went with the method zilmar demonstrated in 1.4 which obviously was incomplete.

[Pau]

Liar. I saw you are in mail contact with them to get it running in their proprietary sellout crap

[shunyuan]

Originally Posted by FatCat

suanyuan, seems Resident Evil 2 initializes the OS SP task structure with zeroed data sent to *(DMEM + OS_TASK_OFF_DATA). How exactly this pointer is used I don't know since I don't work with HLE much, but neither Glide64 nor Jabo's HLE Direct3D seem to like it.
That's why Hacktarux's RSP interface shelled out of older mupen64 and Project64 1.6/1.7 RSP (but not pj64 1.4 RSP which still has the bug you reported) check to see if this pointer is 0 to know how to HLE it.

So I just needed to factor in an extra check before attempting to rely on the external GBI command list handling.

    switch (*(unsigned int *)(RSP.DMEM + 0xFC0))
    { /* Simulation barrier to redirect processing externally. */
#ifdef EXTERN_COMMAND_LIST_GBI
        case 0x00000001:
            if (*(unsigned int *)(RSP.DMEM + 0xFF0) == 0x00000000) break;
            if (RSP.ProcessDList != NULL)
                RSP.ProcessDList();

You should compile that line of code in for the quick fix.
I'll add it in the next release if I can get people to report at least one LLE bug or debug exploit message with my LLE plugin.

I was unaware HLE redirection from the RSP could have a bug since it's incredibly simple code...there was little documentation or examples of how to request a HLE operation that I just went with the method zilmar demonstrated in 1.4 which obviously was incomplete.

Thanks, and how will your RSP interpreter handle this kind of data? Is it a valid data for RSP or not?

[HatCat]

Originally Posted by suanyuan

Thanks, and how will your RSP interpreter handle this kind of data? Is it a valid data for RSP or not?

The data pointer serves a purpose unknown to me.
It should get sent to the gfx plugin as some sort of variable data for the ucode to process with, but I don't really know.

But it will certainly execute natively on my RSP in LLE, just like it seems to do on zilmar's RSP, so the bug with HLE gfx on RE2 will be gone in the same way.
The other HLE gfx stuff of course will still be handled by the video plugin, so no big speed loss.

Originally Posted by Pau

Liar. I saw you are in mail contact with them to get it running in their proprietary sellout crap

Nope, I am not in mail contact with them about anything.

Not that it's natural to back up your claims with proof or anything, since liars cannot prove lies.

And there you have just proved that you didn't "hear" I was in contact with anyone.
You simply hallucinated over the Internet.

I was only invited to join some mupen64plus discussion by okaygo, but I left quickly cause I got bored.

[shunyuan]

Originally Posted by FatCat

suanyuan, seems Resident Evil 2 initializes the OS SP task structure with zeroed data sent to *(DMEM + OS_TASK_OFF_DATA). How exactly this pointer is used I don't know since I don't work with HLE much, but neither Glide64 nor Jabo's HLE Direct3D seem to like it.
That's why Hacktarux's RSP interface shelled out of older mupen64 and Project64 1.6/1.7 RSP (but not pj64 1.4 RSP which still has the bug you reported) check to see if this pointer is 0 to know how to HLE it.

So I just needed to factor in an extra check before attempting to rely on the external GBI command list handling.

    switch (*(unsigned int *)(RSP.DMEM + 0xFC0))
    { /* Simulation barrier to redirect processing externally. */
#ifdef EXTERN_COMMAND_LIST_GBI
        case 0x00000001:
            if (*(unsigned int *)(RSP.DMEM + 0xFF0) == 0x00000000) break;
            if (RSP.ProcessDList != NULL)
                RSP.ProcessDList();

You should compile that line of code in for the quick fix.
I'll add it in the next release if I can get people to report at least one LLE bug or debug exploit message with my LLE plugin.

I was unaware HLE redirection from the RSP could have a bug since it's incredibly simple code...there was little documentation or examples of how to request a HLE operation that I just went with the method zilmar demonstrated in 1.4 which obviously was incomplete.

I guess this fix is not 100% correct. After I add this check to RSP interpreter, graphics rendering is correct, but the dialog voices of Resident Evil 2 movie are also be filtered out just like Zilmar's RSP 1.7.

But I have those dialog voices with Zilmar's RSP 1.6, and before I applied this fix, the dialog voices are there.

Could it possible that part of these data are related to mpeg decoding for GFX HLE function? Such as Jabo's Direct3D8 plugin decoded the mpeg data and write back audio data to emulator's memory?

[HatCat]

Originally Posted by suanyuan

I guess this fix is not 100% correct. After I add this check to RSP interpreter, graphics rendering is correct, but the dialog voices of Resident Evil 2 movie are also be filtered out just like Zilmar's RSP 1.7.

But I have those dialog voices with Zilmar's RSP 1.6, and before I applied this fix, the dialog voices are there.

Could it possible that part of these data are related to mpeg decoding for GFX HLE function? Such as Jabo's Direct3D8 plugin decoded the mpeg data and write back audio data to emulator's memory?

Yes it's possible, but, first I need to reproduce your report.

Maybe I'm using the wrong core settings for this game?
For some reason I'm not getting the voices at all no matter what I do--zilmar's RSP 1.6, take out that code I just put in, whatever you said.

Here are my settings.

[shunyuan]

Originally Posted by FatCat

Yes it's possible, but, first I need to reproduce your report.

Maybe I'm using the wrong core settings for this game?
For some reason I'm not getting the voices at all no matter what I do--zilmar's RSP 1.6, take out that code I just put in, whatever you said.

Here are my settings.

I think you are missing 1964Audio, without it you can't have the correct audio.

And my guess is wrong, I forgot I have the all the dialog voices at 1964 with Zilmar's RSP 1.7, so your fix shouldn't filter out those voices.

Sorry for the wrong bug report.