Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #31  
Old 15th April 2013, 03:45 PM
Pau Pau is offline
Junior Member
 
Join Date: Apr 2013
Posts: 13
Default

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
Reply With Quote
  #32  
Old 15th April 2013, 03:47 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
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).


Quote:
Originally Posted by FatCat View Post
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.
Attached Images
File Type: jpg screen-1.jpg (20.4 KB, 3 views)
File Type: jpg screen-2.jpg (20.5 KB, 4 views)
File Type: jpg screen-3.jpg (20.9 KB, 6 views)
File Type: jpg screen-4.jpg (21.0 KB, 4 views)
Reply With Quote
  #33  
Old 15th April 2013, 03:55 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

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.

Quote:
Originally Posted by Pau View Post
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.

Last edited by HatCat; 15th April 2013 at 03:57 PM.
Reply With Quote
  #34  
Old 15th April 2013, 05:33 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

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.

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

Last edited by HatCat; 15th April 2013 at 05:38 PM.
Reply With Quote
  #35  
Old 15th April 2013, 05:52 PM
Pau Pau is offline
Junior Member
 
Join Date: Apr 2013
Posts: 13
Default

Liar. I saw you are in mail contact with them to get it running in their proprietary sellout crap
Reply With Quote
  #36  
Old 15th April 2013, 06:09 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
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.

Code:
    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?
Reply With Quote
  #37  
Old 15th April 2013, 06:19 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

Quote:
Originally Posted by suanyuan View Post
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.

Quote:
Originally Posted by Pau View Post
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.
Reply With Quote
  #38  
Old 15th April 2013, 06:28 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
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.

Code:
    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?

Last edited by shunyuan; 15th April 2013 at 06:44 PM.
Reply With Quote
  #39  
Old 15th April 2013, 06:48 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

Quote:
Originally Posted by suanyuan View Post
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.



Reply With Quote
  #40  
Old 15th April 2013, 07:13 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
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.

Last edited by shunyuan; 15th April 2013 at 07:21 PM.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 03:51 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.