Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #621  
Old 14th December 2013, 07:08 AM
Garteal Garteal is offline
Junior Member
 
Join Date: Dec 2013
Posts: 4
Default

Quote:
Originally Posted by BatCat View Post
Oh well that's, unique. I'm not seeing how that should be possible if observing this with HLE graphics for both RSP plugins.

Well to speed up positioning myself in the game properly (and any other circumstances about the exact RDRAM state) should I ask you for a PJ64 saved state to quickly take me to where I can see these weird lines and compare switching the RSP plugins myself?
That won't be necessary as it happens pretty much anywhere. I just happened to be outside when I was testing at the time, but the lines are still there in town for example.

Quote:
I'm curious...what error?
Should've been more specific, but this only happens with the RSP 1.7.0.9 it comes with. The Static Interpreter boots, but it has missing graphics etc. Eg the N from Nintendo doesn't render at the splash screen.
Reply With Quote
  #622  
Old 15th December 2013, 05:30 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Well for the sake of keeping up-to-date, I've been really busy/frustrated trying to find some OS to install on a blank SSSE3 laptop I've received.
Haven't had time to look into it yet since I'm so stubborn about why this thing refuses to just take a simple Linux install (hell even MS-DOS would be nice at this point really), but I'll try and get to checking this report in detail sooner rather than later.

So sorry about the delay.

Quote:
Originally Posted by Garteal View Post
Should've been more specific, but this only happens with the RSP 1.7.0.9 it comes with. The Static Interpreter boots, but it has missing graphics etc. Eg the N from Nintendo doesn't render at the splash screen.
Yeah, that always happens in LLE.

With RSP 1.7.0.9 you have to turn on "Use High Level GFX ?" from within the Project64 core options. If you do that, then software rendering will work.
If you have this turned off, THEN it will fail to render the 3-D N logo in software rendering just like my RSP plugin does when it does in LLE (actually it is Jabo's LLE that fails to do it).

It's a stupid little revision in the RSP plugin specs where with zilmar's RSP 1.7.0.9 plugin, it's the core emulator options that dictates whether you're doing the RSP in HLE or LLE, not settings inside the plugin itself like what mine does. Perhaps that might be a small source of the other bug you reported?

Besides, if it still works perfectly with my RSP + angrylion's "my little plugin" software renderer, then that proves that the bug is in Jabo's software renderer and not the RSP plugin, because angrylion's is pixel-accurate and should work with either RSP plugin, mine or zilmar's, at least so far as the 3-D N logo on the splash screen.

Last edited by HatCat; 15th December 2013 at 05:39 AM.
Reply With Quote
  #623  
Old 16th December 2013, 09:08 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Alright, Garteal I haven't been able to encounter any lines with the HLE plugin.
I can only encounter them in LLE, and it seems to be 100% impossible that my HLE graphics redirection algorithm is any different from zilmar's (aside from his plugin being open-source, asking a HLE plugin takes only a few lines of code and is hardly something subject to infringement or intentional copying).

If you're noticing that it's fixed only on RSP 1.7.0.9 then please make sure to uncheck "Use High Level GFX ?" in the main emulator options.

As for the Software rendering crash, I can't seem to get RSP 1.7.0.9 to even boot this game in LLE without "Debugger > RSP > CPU Method > Interpreter" set, otherwise it crashes in the software rendering so that might have been the thing you needed to do the comparison accurately.
Reply With Quote
  #624  
Old 17th December 2013, 05:06 PM
Bastard's Avatar
Bastard Bastard is offline
Junior Member
 
Join Date: Dec 2013
Posts: 4
Lightbulb Bond we're under attack! Find Sir Robert!

And suddenly something unexpected happens...



Heh, trying to activate any hand scanner using LLE video always messes up your RSP (Project64's RSP 1.7.0.9 works as expected), stuff like semaphore corrections, video plugin, etc. didn't change the output. It shouldn't be hard to replicate, but just to help you out I attached a savestate below. See ya.
Attached Files
File Type: 7z 007 - The World is Not Enough (U).7z (1.72 MB, 1 views)
Reply With Quote
  #625  
Old 17th December 2013, 06:23 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Hi and thanks for the report, but you seem to be using an older release of this plugin, rather than the latest version. (I can tell by the Win32 MB GUI for tracing errors I was using back then.)

You are probably using rsp.dll public release 4. That exact error message no longer exists in the current version (pr6) of my plugin, so you are using an older version.

What's more? When I loaded your saved state up in Project64, not only was I successfully able to reproduce your RSP error message with my RSP emulator, but zilmar's RSP 1.7.0.9 for Project64 also had RSP error messages of its own when I hit the hand scanner (mostly SP DMA segfaults). Since neither RSP emulator seems to be stable for the saved state you provided, it suggests that the host CPU (Project64's recompiler core) is to blame. You should modify the RDB ROM settings for this game in Project64 so that Project64 stops sending faulty, illegitimate requests to my RSP plugin as well as his.

Or use a different emulator, like Mupen64 or 1964 0.8.5's interpreter. They are very good at communicating the correct requests to the RSP to prevent "RSP errors" like this.
Reply With Quote
  #626  
Old 17th December 2013, 06:27 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

I can confirm that this seems to be a PJ64 core issue, no problems with m64p here, and as said i played that game a while ago and went through this exact mission
Reply With Quote
  #627  
Old 17th December 2013, 06:36 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

I should apologize for all of the confusion, everyone.
  • The new RSP plugin spec for Project64 2.0's native RSP plugin makes you use the "Use High Level GFX ?" checkbox in the main Project64 settings, independent of the HLE/LLE settings through Garteal's UI.
  • zilmar's Project64 emulator has been configured for ~10+ years to use stable RDB ROM settings assuming HLE gfx.
  • Almost all F3DEX ucode games have problems with zilmar's re-compiler core and send faulty requests to the RSP, causing false RSP error reports with my emulator here.
  • zilmar has no intention to go out of his way to support other plugins. He admits to only caring about the development of Project64-native plugins, and has shown no interest in making his emulator fully compatible with plugins outside of Project64.

I'm sorry to say that this is all an unfortunate coincidence.
But from what I have seen in this thread so far, all of my designs are correct.

I tried to cover most of these details briefly in the MANUAL documentation I wrote, but I guess my writing skills with professional documentation are a little overly saturated, such that nobody in their right mind would have the time or patience to extract these details.

All I can really say to everyone is: The RSP is a communicator with the core emulator. Please be thorough about the process of elimination about other barriers receiving this communication (the graphics RDP renderer, the main CPU emulator like pj64, mupen etc.) before assuming that there is a bug on my side. Either way, thanks for putting the time into these reports.

---

Good news: Seems the SSSE3 build of my RSP plugin has surpassed the world's fastest RSP emulator, Jabo's MMX re-compiler RSP plugin for Project64, in certain latent spots where the pixel-accurate graphics plugin his used. It seems my own RSP plugin has surprisingly ended up the fastest of them all. My goal of proving that an interpreter can be faster than a re-compiler has been successfully met.
Thanks very much to MarathonMan for sending me the SSSE3 laptop CPU I needed to finally check this.

[EDIT] Thank you for confirming, V1del.
Reply With Quote
  #628  
Old 17th December 2013, 11:58 PM
Bastard's Avatar
Bastard Bastard is offline
Junior Member
 
Join Date: Dec 2013
Posts: 4
Lightbulb

Quote:
Originally Posted by BatCat View Post
That exact error message no longer exists in the current version (pr6) of my plugin, so you are using an older version.
Heh, funny comment little kitty

It's the 455th line in GitHub's su.h (github.com/cxd4/rsp/blob/master/su.h#L455), and I'm well aware of your releases 'cause I check your repo regularly

(also, unlike you, I'm not allergic to #ifdef WIN32 ... #endif statements )
Reply With Quote
  #629  
Old 18th December 2013, 12:38 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by Bastard View Post
It's the 455th line in GitHub's...
Wrong. The exact error message is "RSP Error::(x)". That exact error message you reported no longer exists in my plugin.

You are not using the latest version, so the responsibility behind the fault of the error rests with your declination to use the correct version, little guy.
Reply With Quote
  #630  
Old 18th December 2013, 12:50 AM
Bastard's Avatar
Bastard Bastard is offline
Junior Member
 
Join Date: Dec 2013
Posts: 4
Lightbulb

Heh, sorry if my comment wasn't clear enough, maybe I should try to be more precise about what I did.
Being irritated by the ugly, Windows-specific sorta hack in the message() function, I recreated it with a #ifdef WIN32 block with MessageBox calls and a generic #else block with printfs.
So I was referring to the error itself, and you to the whole message() system. That's it.
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 04:51 AM.


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