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

[the_randomizer]

Originally Posted by FatCat

Yeah, reported by nintendo1889 some time back.

I didn't think people would want every DLL installed. Personally I almost always use rsp_lle.dll or rsp.dll, but I guess I didn't care at the time to put thought into dispersing the plugin dll names under the macro config tree.

No worries, I use the one that works best, in this case rsp_mle.dll. If it's too much trouble changing the internal names to match the file names, there's no need to stress about it.

[HatCat]

I also had no idea that my plugin would become this famous.

I just created this thread hoping I would get some testing info, went to bed straight after, presuming nobody was going to reply to my thread. Instead, I wake up and see that 45 people downloaded my attached plugins XD, I was like WTF.

Since my work seems a bit more popular than I expected, I'm deciding to give each DLL its unique name for clarity purposes when testing the different versions.

rsp_mle.dll is basically the exact same as zilmar's RSP Project64 (HLE audio, LLE everything else for speed, less accurate gfx) default settings, only it is an interpreter to prevent crashes caused by compiler predictions.

[mesk14]

Originally Posted by squall_leonhart

@mesk

place the z64.conf file into /$emudir$/screenshots/plugin

That works,thank you

Originally Posted by FatCat

Since my work seems a bit more popular than I expected, I'm deciding to give each DLL its unique name for clarity purposes when testing the different versions.

That would be extremely helpful

[the_randomizer]

Originally Posted by FatCat

I also had no idea that my plugin would become this famous.

I just created this thread hoping I would get some testing info, went to bed straight after, presuming nobody was going to reply to my thread. Instead, I wake up and see that 45 people downloaded my attached plugins XD, I was like WTF.

Since my work seems a bit more popular than I expected, I'm deciding to give each DLL its unique name for clarity purposes when testing the different versions.

rsp_mle.dll is basically the exact same as zilmar's RSP Project64 (HLE audio, LLE everything else for speed, less accurate gfx) default settings, only it is an interpreter to prevent crashes caused by compiler predictions.

If the MLE version isn't super-accurate as you said, what would be an RSP plugin that I can use with Glide 64 and Jabo's DSound plugin? I know one is HLE and the other is LLE (I think), I probably chose the worst of the bunch to use for testing....sorry for reporting useless info on the tests, seeing as I used the wrong plugin and all

Aw dammit.

[HatCat]

Originally Posted by nintendo1889

If the MLE version isn't super-accurate as you said, what would be an RSP plugin that I can use with Glide 64 and Jabo's DSound plugin? I know one is HLE and the other is LLE (I think), I probably chose the worst of the bunch to use for testing....sorry for reporting useless info on the tests, seeing as I used the wrong plugin and all

Aw dammit.

HLE can be more accurate than LLE, but generally speaking this is never possible in cases where the LLE is completed.

To play with Glide64 and Jabo's DSound, you do indeed use the `rsp_mle.dll`, so you are using the correct DLL.

However, Glide64 is not a LLE graphics plugin. I cannot control what is sent to the RDP because `rsp_mle.dll` lets a HLE graphics plugin simulate the ucode.
So I am less responsible for what happens.

However, I would not say that means you are testing the wrong file.
suanyuan proved that I had a bug with my HLE support...you could be doing the right thing by testing LLE audio only (plus other rare types) and HLE gfx unlike most people who are using the fully LLE version of my plugin.

[edit] Also, since zilmar cannot remember why he clears the DPC_STATUS_FREEZE bit in the RDP status register for HLE gfx tasks, in the next version I upload I might need your help testing HLE gfx with my MLE plugin.

[the_randomizer]

Originally Posted by FatCat

HLE can be more accurate than LLE, but generally speaking this is never possible in cases where the LLE is completed.

To play with Glide64 and Jabo's DSound, you do indeed use the `rsp_mle.dll`, so you are using the correct DLL.

However, Glide64 is not a LLE graphics plugin. I cannot control what is sent to the RDP because `rsp_mle.dll` lets a HLE graphics plugin simulate the ucode.
So I am less responsible for what happens.

However, I would not say that means you are testing the wrong file.
suanyuan proved that I had a bug with my HLE support...you could be doing the right thing by testing LLE audio only (plus other rare types) and HLE gfx unlike most people who are using the fully LLE version of my plugin.

[edit] Also, since zilmar cannot remember why he clears the DPC_STATUS_FREEZE bit in the RDP status register for HLE gfx tasks, in the next version I upload I might need your help testing HLE gfx with my MLE plugin.

Well, okay that makes more sense; glad I didn't do anything wrong with the testing. Jabo's Direct3D8 1.6.1/1.7.0.59 are LLE-based GPU plugins right? So for that, I'd need to use rsp_lle.dll, I think. As for the new version of rsp_mle, just give me a holler when it's out, that is, if you need more testing

To sum up

Rsp_mle - HLE
Glide 64 - HLE
Jabo's DirectSound 1.7.07 - LLE

Gotcha. So far I haven't encountered anything out of the ordinary but I'll keep you posted.

BTW, how long has that sound plugin been LLE?

[HatCat]

Hmm it seems that your understanding is approximate.

MLE means that there is a hybrid of HLE and LLE.
rsp_mle.dll and rsp_lle.dll are both MLE plugins, which is somewhat confusing.
rsp_mle is MLE because the GPU plugin must be HLE; the SPU plugin must be LLE.
rsp_lle.dll is MLE because the GPU must be in LLE; the SPU must be HLE.
They both mix HLE and LLE graphics/audio plugins, just that which one gets inverted.

Originally Posted by nintendo1889

Jabo's Direct3D8 1.6.1/1.7.0.59 are LLE-based GPU plugins right? So for that, I'd need to use rsp_lle.dll, I think.

The thing about Jabo's 1.7, is that it can use either HLE **or** LLE.
It will use, whatever the RSP commands it.
That's why checking "Use high level GFX ?" in Project64 settings makes Jabo's Direct3D run in HLE, whereas leaving it unchecked tells Jabo to do LLE.

Either rsp_lle.dll (HLE audio but LLE gfx) or rsp.dll (LLE every single thing) will do LLE gfx and use the feature.

Um, Jabo's Direct3D8 1.6.1, has no LLE.
Jabo couldn't backport his LLE graphics emulator from 1.7 to his final plugin release for graphics. It might be in part because zilmar upgraded the plugin specs in pj64 1.7 and pj64 1.6 couldn't support those features.

Originally Posted by nintendo1889

BTW, how long has that sound plugin been LLE?

Jabo's sound plugin has always been a LLE sound plugin to my knowledge?

So if you use my `rsp_lle.dll` (again, misleading ... the GPU plugin must be LLE but the audio is done in HLE) with Jabo's LLE audio emulator, you get no sound.
There is no sound when using a HLE RSP with a LLE audio emulator, or vice versa....

So my RSP plugin forces nothing, just relies on the correct graphics and audio plugins to be set in the emulator config, with respect to the correct rsp dll.

[the_randomizer]

Originally Posted by FatCat

Hmm it seems that your understanding is approximate.

MLE means that there is a hybrid of HLE and LLE.
rsp_mle.dll and rsp_lle.dll are both MLE plugins, which is somewhat confusing.
rsp_mle is MLE because the GPU plugin must be HLE; the SPU plugin must be LLE.
rsp_lle.dll is MLE because the GPU must be in LLE; the SPU must be HLE.
They both mix HLE and LLE graphics/audio plugins, just that which one gets inverted.



The thing about Jabo's 1.7, is that it can use either HLE **or** LLE.
It will use, whatever the RSP commands it.
That's why checking "Use high level GFX ?" in Project64 settings makes Jabo's Direct3D run in HLE, whereas leaving it unchecked tells Jabo to do LLE.

Either rsp_lle.dll (HLE audio but LLE gfx) or rsp.dll (LLE every single thing) will do LLE gfx and use the feature.

Um, Jabo's Direct3D8 1.6.1, has no LLE.
Jabo couldn't backport his LLE graphics emulator from 1.7 to his final plugin release for graphics. It might be in part because zilmar upgraded the plugin specs in pj64 1.7 and pj64 1.6 couldn't support those features.



Jabo's sound plugin has always been a LLE sound plugin to my knowledge?

So if you use my `rsp_lle.dll` (again, misleading ... the GPU plugin must be LLE but the audio is done in HLE) with Jabo's LLE audio emulator, you get no sound.
There is no sound when using a HLE RSP with a LLE audio emulator, or vice versa....

So my RSP plugin forces nothing, just relies on the correct graphics and audio plugins to be set in the emulator config, with respect to the correct rsp dll.

Wasn't too sure on the 1.6.1 GPU plugin, but it makes sense now. For LLE, I definitely have the CPU power to do it, so I can try that as well. Unfortunately, Bomberman 64 has some seriously broken audio, so not sure how properly test the game with HLE or LLE audio and the RSP. AI is 40 and VI is at 1400. Would it help to post an audio sample?

[HatCat]

Originally Posted by nintendo1889

Wasn't too sure on the 1.6.1 GPU plugin, but it makes sense now. For LLE, I definitely have the CPU power to do it, so I can try that as well. Unfortunately, Bomberman 64 has some seriously broken audio, so not sure how properly test the game with HLE or LLE audio and the RSP. AI is 40 and VI is at 1400. Would it help to post an audio sample?

It would help most, if you compared between Project64 1.6 and Project64 2.0.

Project64 2.0 is the one to introduce RDB-controlled audio timing integration and require user settings of the AI count per byte etc. controls.

But on 1.6, if the audio is wrong, it is a fault either of my RSP plugin (hah! yeah right) or the audio plugin itself.

Try your usual rsp_mle.dll to test LLE audio with Jabo's DirectSound for the most direct testing.

I would like to send you my updated mle.dll to help get a head start with figuring out the DPC_STATUS_FREEZE bit's possible application if any games use it, but I am just so busy with programming right now. Suffice it to say that I have made a very important discovery that will speed up RSP vector memory endianness transactions and speed up my RSP emulator the next time I do a release...I'm just so busy right now I don't have a lot of time to talk because I'm in the process of moving out of Texas and won't be able to log onto this site probably the next couple of nights or more.

[the_randomizer]

Originally Posted by FatCat

It would help most, if you compared between Project64 1.6 and Project64 2.0.

Project64 2.0 is the one to introduce RDB-controlled audio timing integration and require user settings of the AI count per byte etc. controls.

But on 1.6, if the audio is wrong, it is a fault either of my RSP plugin (hah! yeah right) or the audio plugin itself.

Try your usual rsp_mle.dll to test LLE audio with Jabo's DirectSound for the most direct testing.

I would like to send you my updated mle.dll to help get a head start with figuring out the DPC_STATUS_FREEZE bit's possible application if any games use it, but I am just so busy with programming right now. Suffice it to say that I have made a very important discovery that will speed up RSP vector memory endianness transactions and speed up my RSP emulator the next time I do a release...I'm just so busy right now I don't have a lot of time to talk because I'm in the process of moving out of Texas and won't be able to log onto this site probably the next couple of nights or more.

I have indeed tested Bomberman 64 using the setup I mentioned previously (rsp_mle, Glide 64 and Jabo's Directsound 1.7.0.7) and the issue is pretty bad audio-wise with skips every two to three seconds; in fact, if you were to open the file in Audacity, you can see the gaps in the spectrogram. I recall it being an issue in 1.6 as well, but I'll test it again between the two emulator versions and maybe run some ABX tests just to make sure.

Of all the games I've tested so far, this is by far the most bizarre when it comes to how the audio is handled; whether it's the plugin itself conflicting with the timing...it's hard to say for, but yeah, ABX tests might help get definitive info.