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

[HatCat]

In fact, for the better of keeping the download method centralized and non-scattered, I would rather dispose of those attachments.

But for the hell of it, first I'll log their download counts:

File Type: 7z 	rsp.7z (94.5 KB, 476 views)
File Type: 7z 	rsp_pr2.7z (459.9 KB, 107 views)
File Type: 7z 	rsp_pr3.7z (103.3 KB, 158 views)
File Type: 7z 	rsp_pr4.7z (94.3 KB, 452 views)
File Type: 7z 	rsp_pr5.7z (77.6 KB, 64 views)

Funny. I couldn't get BOTH the SSE2 and SSSE3 builds to have 64.0 KB file size, yet I get 64 downloads.

pr2 and 3 were very closely released and for a very short time before pr4, so that's why some counts are so much more than others.

[Garteal]

Finally got a chance to try out the plugin with Majora's Mask on Project64 2.1 with the default plugins. There are some rendering issues with both HLE and LLE.

Unchecking "send display lists to the graphics plugin" results in a black screen in the motion blur scenes and during gameplay it renders lines where the seams (of the skybox for example) are.


Having it checked, I had an issue with the textures where they did not render properly (mostly the ground textures). It was as if you stood very far (while in reality you were right there) and it was showing the lowest LOD texture.

Another issue I had with it checked was clearly visible texture seams. Unfortunately I couldn't reproduce it in the little time I had so I don't have a screenshot of it, but if needed, I'll try to find out how it exactly happened and provide screenshots when I get home.

Just to be specific, this was tested on my laptop with Windows 7 Pro 64-bits and an NVIDIA GT540M.
Project64 2.1.0.1
Direct3D8 1.7.0.57-ver5
Static Interpreter public release 6

[V1del]

Neat stuff batcat, I grabbed the m64p port of off ecsv's repo to play me some TWINE with sound, worked like a charm, no speed improvement infos though as i used HLE gfx, may do some benchmarking later with z64, thanks for the update anyway

...though there is no absolute guarantee that the audio plugin didn't just copy an RSP interpreter inside of it to basically still do LLE.

Them jabs, i lol'd

[HatCat]

Originally Posted by Garteal

Finally got a chance to try out the plugin with Majora's Mask on Project64 2.1 with the default plugins. There are some rendering issues with both HLE and LLE.

Unchecking "send display lists to the graphics plugin" results in a black screen in the motion blur scenes and during gameplay it renders lines where the seams (of the skybox for example) are.

Hm, strange. I wasn't able to see the skybox seamlines.
I did get something like that screen anyway though:


Similar to you, same basic screen when using LLE or HLE with Jabo's D3D8 on my NVIDIA GeForce 6150 LE.

Now, at any rate (and this goes the same for the rest of the graphics glitches you hinted at), the results should appear less glitched with a different LLE plugin like, z64gl (with lowres=1):


[EDIT] Hm but this time, the color combiner is wrong for the grass. =[

Or, angrylion's per-pixel accurate LLE plugin:



In short, this seems to be an issue with the Direct3D renderer and/or HLE simulation of the RDP within Jabo's plugin.
If at any time you might find doubts about this, I would try testing the slower RSP interpreter plugin that came with your installation of Project64 2.1 (labeled "RSP 1.7.0.9"), and if that has the same issues then I would guess the RSP has no control over those particular graphics glitches.

Texture LOD, null frame buffer effects in LLE, blurred texture filtering, ..etc. those are all a sign of probably the RDP/graphics plugin not being equipped for the commands data communicated successfully by the RSP emulator. After all Jabo's gfx is definitely one of the best out there, but it lacked sufficient information on the RDP commands in LLE as well as a few other problems.

Originally Posted by V1del

Neat stuff batcat, I grabbed the m64p port of off ecsv's repo to play me some TWINE with sound, worked like a charm, no speed improvement infos though as i used HLE gfx, may do some benchmarking later with z64, thanks for the update anyway

In the Mupen64Plus fork, I think ecsv may need to add -DARCH_MIN_SSE2 (or _SSSE3) to the Linux MAKEFILE to really utilize my SSE2 accelerations, otherwise I fear their build of my emulator may turn out slower than their current/stable release of it.

Originally Posted by V1del

Them jabs, i lol'd

LOL. I was kind of hoping somebody would get that.

As much as I wish it was just a joke, I didn't really want to bring it up at all, but sadly in this day and age it seems people will be exposed to lots of misinformation if I don't.

[Garteal]

Originally Posted by BatCat

Texture LOD, null frame buffer effects in LLE, blurred texture filtering, ..etc. those are all a sign of probably the RDP/graphics plugin not being equipped for the commands data communicated successfully by the RSP emulator. After all Jabo's gfx is definitely one of the best out there, but it lacked sufficient information on the RDP commands in LLE as well as a few other problems.

As I thought. The texture issue happens only when I'm using the integrated Intel HD 3000 chip instead of the 540M. Here is what it looked like using the Static Interpreter. Using the RSP it came with produced similar results.

HLE


LLE (The skybox seam is somewhat visible in the distance)

In short, this seems to be an issue with the Direct3D renderer and/or HLE simulation of the RDP within Jabo's plugin.
If at any time you might find doubts about this, I would try testing the slower RSP interpreter plugin that came with your installation of Project64 2.1 (labeled "RSP 1.7.0.9"), and if that has the same issues then I would guess the RSP has no control over those particular graphics glitches.

I actually tested this too when I was testing the Static Interpreter. Everything works fine with RSP 1.7.0.9.

I've also just tried this on my desktop with an AMD R9 280x and I get the same weird line rendering and seams issue using LLE.

[HatCat]

Interesting. I've never seen that before.

According to those two screenshots you posted, the rendering quality is actually improved when executing the RDP in LLE on Jabo's d3d8 (higher-resolution textures even!), instead of HLE. Yes, it's normally true on a grand scale that HLE is harder to stabilize, more hazard-prone to small bugs, impossible to support every bit of code etc., but it's supposed to have a "better quality" appearance than even LLE, with less broken things in the known games. I had no idea that LLE would make up for, what seems to be problems with one of your older, more out-dated video cards.

(And I can tell for myself you labeled them correctly i.e. "LLE" was not switched with "HLE" when labeling the screens, because as you pointed out the LLE one has some slight triangle rendering offsets/minor mistakes like that very small recession of black pixels in the skybox, and the edge of the grassy floor straight next to the water shown in the pic. Usually LLE while less bug-prone has problems with 3-D triangle rendering in the d3d8.)

Well, since you seem to be looking into these sorts of things, I figure it's worth mentioning that there is a fully pixel-accurate software-rendering plugin. It should help sometimes to remove any confusion based on your choice of video card, because it just uses pixel DMA in DirectDraw independent of what video card you have (if even any, really).
mudlord uploaded a build of said plugin (made by angrylion) from this post.
As far as we've seen it has no mistakes or graphical imperfections with any games, but nobody has the CPU to use that plugin at full speed emulation. It's just not optimized enough yet, and it could make do with some possibilities of hardware-accelerated OpenGL, like what z64gl does.

Additionally, if you had "Hide Advanced Settings" disabled in the main Project64 options, no doubt you noticed the "Software rendering" option in Jabo's Direct3D 1.7.x, too, but, you can't really use that while testing in LLE because Jabo left that in a broken state. That option only truly works with HLE on Jabo's, so when it comes to debugging the RSP there really is almost no point to it.

Originally Posted by Garteal

I actually tested this too when I was testing the Static Interpreter. Everything works fine with RSP 1.7.0.9.

I've also just tried this on my desktop with an AMD R9 280x and I get the same weird line rendering and seams issue using LLE.

Right, so to be certain if I'm understanding you correctly there was actually no issue on the RSP plugin's side.

It's briefly generalized over somewhere in the user MANUAL.HTML I wrote, but all any RSP plugin has to do for HLE is ask the graphics/audio plugin to do the work FOR it. It's pretty much the same code for any RSP plugin, in fact: All I'm doing is redirecting the graphics/audio task to a plugin of the respective type, if the user checked your UI options for doing that type of task in HLE. In this sense, it's impossible for HLE bugs to be caused by my RSP plugin because any RSP plugin does only the work of making something else, do the work for it, heh.*

*except a bug fix to Resident Evil 2, where HLE was impossible due to a null pointer when doing the MPEG video decompressors, where I fixed a bug where the RSP was attempting to do HLE when it shouldn't have even bothered

[HatCat]

Ah, crap, I notice I gave the wrong link.

Not even worth editing the post.
http://forum.pj64-emu.com/showpost.php?p=50466

If you follow the link I actually gave you, it's still "pixel-accurate", with possibly some VI complications for real N64 filtering/dithering maybe removed.

But the link I really meant to post (right above) is to angrylion's plugin, which while slower is a little bit more tested and does all the "real N64 graphics" stuff like low-res dithering, interpolation for upscaled screen-sizes etc.

[Garteal]

The Intel HD 3000 was actually introduced in Sandy Bridge CPU's which came in 2011 or so.

Originally Posted by BatCat

Well, since you seem to be looking into these sorts of things, I figure it's worth mentioning that there is a fully pixel-accurate software-rendering plugin. It should help sometimes to remove any confusion based on your choice of video card, because it just uses pixel DMA in DirectDraw independent of what video card you have (if even any, really).
mudlord uploaded a build of said plugin (made by angrylion) from this post.
As far as we've seen it has no mistakes or graphical imperfections with any games, but nobody has the CPU to use that plugin at full speed emulation. It's just not optimized enough yet, and it could make do with some possibilities of hardware-accelerated OpenGL, like what z64gl does.

I was going to try that next. Thanks for linking me to it.
There are no graphical glitches from what I've tested but it's certainly way too expensive too run. I only get around half speed right now with my 2500K. Is anyone still working on it?

Additionally, if you had "Hide Advanced Settings" disabled in the main Project64 options, no doubt you noticed the "Software rendering" option in Jabo's Direct3D 1.7.x, too, but, you can't really use that while testing in LLE because Jabo left that in a broken state. That option only truly works with HLE on Jabo's, so when it comes to debugging the RSP there really is almost no point to it.

Yeah, I did. I've tried it as well and got an error upon booting the game.

Right, so to be certain if I'm understanding you correctly there was actually no issue on the RSP plugin's side.

I've taken a look at the manual and glanced over it. Nice writing by the way.
I only get those weird lines when I'm using the Static Interpreter yeah; the RSP 1.7.0.9 works fine.

[HatCat]

Originally Posted by Garteal

I've taken a look at the manual and glanced over it. Nice writing by the way.
I only get those weird lines when I'm using the Static Interpreter yeah; the RSP 1.7.0.9 works fine.

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?

Originally Posted by Garteal

Yeah, I did. I've tried it as well and got an error upon booting the game.

I'm curious...what error?

There is the access violation that typically happens when turning on the option with 4 MB RDRAM, but that's not possible in this case since you're testing Zelda MM and that requires 8 MB to be turned on anyway.
It seems to work without errors for me though.

Originally Posted by Garteal

There are no graphical glitches from what I've tested but it's certainly way too expensive too run. I only get around half speed right now with my 2500K. Is anyone still working on it?

Not that I know of.

mudlord started the thread because somebody else was trying to do everything closed-source without doing any legit improvements to it.
These months mudlord's too busy that he probably will get no chance to improve actively upon the poor performance of that plugin anytime soon.

I was working on it myself for a while and made some noticeable speed benefits, but I stopped working on it before it was ever fully worth releasing since I got mad at a list of people in the process. I really wanted to finish the RSP first anyway, but with that virtually out of the way now, the RDP is nothing short of the next most interesting thing to apply my SSE knowledge to...only one thing is, I'm not a DirectDraw wiz'.

[HatCat]

Just to update I did make another attempt to check out that scene in MM with both LLE and HLE and didn't notice a difference from when I switched to view it with RSP 1.7.0.9. Then again it could just be that I have a lot of tasks occupying my mind; if there really are any surviving bugs on my part I'd like to get informed of them somehow before I'd like to get this project off of my head.