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

[the_randomizer]

Originally Posted by BatCat

Then you could at least explain where you were confused, because I am not seeing it. :/

I didn't see the dates on the files on the first post is all, just the names, no biggie. And for EmuCR, lol, I don't trust those files as far as I can throw a football. They leaked an Snes emulator on there all the time against author's wishes, so I called them out on it

Anyways, I didn't see the "click here to get the latest version", I only saw the attached files on the OP, so it was PEBKAC on my part. Sorry about that.

[HatCat]

ya , release dates are all in the manual

But since there is no "pr6" or higher, only "pr5", I was incredibly confused why anyone wouldn't be certain that "pr5" had to have been the latest version. No offense--it sounds like you had your reasons.

Funny thing, at emuCR they got impatient waiting for me to update this plugin again, so they started compiling off my GitHub repository. So I broke Microsoft Visual Studio's ability to compile my code, and they haven't been able to update their builds of my plugin since. That's why I thought you were judging by the code on my GitHub repository, instead of the version numbers here.

Originally Posted by nintendo1889

Anyways, I didn't see the "click here to get the latest version",

Only one reason why I put that there.
I see lots of people are still downloading "rsp.7z" and not the latest version (pr4 and, now, pr5), possibly cause they thought "pr" meant "parts of the multi-part download" or something, or just looked for the very first attachment they could find and only downloaded that.

It was to help make sure they didn't download the oldest version thinking it was the latest.
But, I'm out of attachment upload slots, anyway. This forum only permits a maximum of 5 attachments per post.

[the_randomizer]

Originally Posted by BatCat

ya , release dates are all in the manual

But since there is no "pr6" or higher, only "pr5", I was incredibly confused why anyone wouldn't be certain that "pr5" had to have been the latest version. No offense--it sounds like you had your reasons.

Funny thing, at emuCR they got impatient waiting for me to update this plugin again, so they started compiling off my GitHub repository. So I broke Microsoft Visual Studio's ability to compile my code, and they haven't been able to update their builds of my plugin since. That's why I thought you were judging by the code on my GitHub repository, instead of the version numbers here.



Only one reason why I put that there.
I see lots of people are still downloading "rsp.7z" and not the latest version (pr4 and, now, pr5), possibly cause they thought "pr" meant "parts of the multi-part download" or something, or just looked for the very first attachment they could find and only downloaded that.

It was to help make sure they didn't download the oldest version thinking it was the latest.
But, I'm out of attachment upload slots, anyway. This forum only permits a maximum of 5 attachments per post.

Aaaaaand I feel like a jackass But at least I know why now.

[e2118289]

Hi there, thanks for the new release catdude, your RSP is really neat.
But there is a problem. The new semaphore/sync stuff it's not working in PJ64 2.1!
With both options set any game just freezes with 60 VI/s and keeps doing nothing, tried toggling the options separately without luck, also tried HLE audio/video etc etc, the only thing that works is having both options disabled, and that way Mario no Photopie doesn't boot so can you please check this out?

[HatCat]

Originally Posted by oddMLan

I found a bug in Conker's Bad Fur Day using the latest release. Some SFX and voices sound "muffy" (as if there were no interpolation applied). Easily noticeable in the intro with Conker cutting the "N" logo with a chainsaw.
Jabo's RSP and your RSP Public Release 4 don't suffer from this bug.
I could upload some audio comparing the affected audio and the desired result if it is necessary. FWIW, this game compresses voices and SFX using some custom MP3 codec.

Using Project64 2.1 and Jabo's DirectSound 1.7.

Ah, this was no bug in the vector operations. I seem to remain voided of those.
It actually turned out to be a surviving "typo", if you could call it that, in the 128-bit quadword stores if the address was unaligned. I put the lines in the wrong order a few months ago.

Easily enough fixed, as well as the issue mentioned in the post directly above this one, but in a sudden turn of events it seems I won't be releasing this next version straight away because it looks like I might have an opportunity to first pull in and merge some 64-bit portability fixes based on the Mupen64Plus take on the situation. It won't matter for non-zilmar-spec afaik, but more portability is more success at any rate.

The issue about SP_SEMAPHORE cycle-accuracy fakes not working in Project64 2.1 was actually because I moved the CPU memory map of the PC register to a local segment instead of writing it back. I had no idea, but the emu needed to remember the PC on a global scale in this case.

[oddMLan]

Yay Glad you fixed it. I wonder if that "typo" affected other games.
Oh, and BTW, I experienced a black screen if I enabled the SP_Semaphore option, too. But at first it seemed to work, then the next day it didn't D: I thought I screwed up something lol

Now that we're talking about bug squashing, I want to inform you that changing the RSP settings from the Config Menu in Project64 2.1 crashes the emu. Open the RSP config dialog, and as soon you try to save the settings the emulator closes immediately, creating some interesting files in the config directory (rcpcache.dhex... etc). I don't think those files should be created neither the emulator should close abruptly so it seems to be a unintended crash after all. But maybe I could be wrong...


Also I could compare speeds in some games using different RSPs. But unfortunately I can't test the SSSE3 version because my AMD CPU doesn't support that (it supports SSE3 and SSE4A but not SSSE3 u_u).
Maybe this weekend.

[HatCat]

Originally Posted by oddMLan

Yay Glad you fixed it. I wonder if that "typo" affected other games.

Come to think of it, most likely.

If I wasn't too lazy to put a debugger back in to prove when and for what games that bug just got fixed for, I would check it.

But the bug was basically a mis-ordered SQV operation if, and only if, the address isn't 128-bit aligned.

The vast majority of the time however it is aligned, which would explain why the bug was so hard to stumble upon without testing games with whacky/custom RSP ucode like Rareware/Conker's BFD etc.

I'm positive it could only have affected audio tho, not video...SQV with 3-D graphics tasks is unheard of.

Originally Posted by oddMLan

Oh, and BTW, I experienced a black screen if I enabled the SP_Semaphore option, too. But at first it seemed to work, then the next day it didn't D: I thought I screwed up something lol

Yeah it WAS working up until very soon just before I uploaded the pr5 release, where I snuck in a local I-cache counter optimization that broke it on accident. The fix is on the repo now; I just hope I'll be able to get enough answers on the Mupen64Plus merge and then I can release the fixed binary.

It was random/hard to reproduce most likely because the PC stopped at variable offsets and kept being forgotten by the RSP-CPU primary thread.

Originally Posted by oddMLan

Now that we're talking about bug squashing, I want to inform you that changing the RSP settings from the Config Menu in Project64 2.1 crashes the emu. Open the RSP config dialog, and as soon you try to save the settings the emulator closes immediately,

Same here, yeah.
I can't really control it though since I don't have the C# source to Garteal's Win32 GUI. I'll see about asking him for another quick update to fix that tomorrow.

It DOES however work if you click Configure RSP, while a game is running in Project64 2.1, just not with Project64 2.1 opened straight up and with no game currently loaded to the emulation thread. (At least that's what I'm observing.) Also it seems to work in 1964, Mupen64 and pj64 1.6 without crashing. But yeah, still, it's worth asking for that sp_cfgui.exe module to get a small update...

Originally Posted by oddMLan

creating some interesting files in the config directory (rcpcache.dhex... etc). I don't think those files should be created neither the emulator should close abruptly so it seems to be a unintended crash after all. But maybe I could be wrong...

Those aren't really needed I guess but I felt like always generating them to show off fancy RSP stuff.
It's partly just to be l33t, partly to make it easier for end users to debug the RSP machine code being executed and send these additional data files to me if I have to ask for them to troubleshoot something.

But it's mostly just for showing off RSP stuff for no apparent reason.
Hm, though I suppose it can get a bit annoying...maybe I should move it into the config system?

Originally Posted by oddMLan

Also I could compare speeds in some games using different RSPs. But unfortunately I can't test the SSSE3 version because my AMD CPU doesn't support that (it supports SSE3 and SSE4A but not SSSE3 u_u).
Maybe this weekend.

Man, it's like nobody on this entire board has a SSSE3 CPU.

Not ExtremeDude2, not me...well MarathonMan did and actually he's helping to provide me one sometime.

I wish Intel didn't waste time delaying more important standardization by adding those trivial SSE3 things, and SSE4A doesn't really contribute anything towards RSP emulation either.

Not to ramble on, but I know if my SSE2 build is almost as fast as the RSP recompiler for pj64, the SSSE3 build is going to be nothing short of a close call...gah, need access to test it though.

[HatCat]

nvm about the pj64 2.1 crash!

That wasn't anything about the EXE it was calling; that was due to logging the RCP system control registers shared with the RDP before the emulation thread was even initialized.

Even though it only seems to crash pj64 2.x and nothing else, I guess the info is mostly useless to look at if you have no bug to report to me for troubleshooting. So I compromised by removing this feature from DllConfig only.

M64+ ABI fixes were also merged, so a new release should be up shortly.

[GPDP]

May as well mention that I could not get the plugin to boot up Gauntlet Legends or World Championship Driving, despite setting the relevant option and using LLE graphics.

[HatCat]

New release is posted to the thread.

I'm out of attachment upload slots though. Sure I could just use another post or something, but I don't really care. Plus there's no benefit for me in making people register/log in to this forum to download it anyway, so see the OP for the download link.

Originally Posted by GPDP

May as well mention that I could not get the plugin to boot up Gauntlet Legends or World Championship Driving, despite setting the relevant option and using LLE graphics.

Yeah, this was just reported earlier on the previous page.
It is one of the things that got fixed in the sixth public release.