These are old downloads of the plugin. I won't remove them from anyone's possibility of testing, but do not be confused into thinking these are the latest updates to the plugin. Head over to the plugins forum at EmuTalk for newer releases. No registration required.

For some reason the RDP also supports never-before-emulated things in the public scene, like the "screen alignment/adjustment" game options in games like SSB, Banjo-Tooie, makes Pokémon Snap finally playable, and makes it advisable to turn on 8 MB RDRAM expansion pak emulation on games using the extra 4 MB for high-resolution graphics. (With HLE video plugins this feature was stupid and useless.)

Shunyuan's graphics plugin may force using a RSP that sends dlists to it, but that doesn't make it a HLE plugin. It's literally a LLE plugin; the real reason why it's faster is simply because it doesn't emulate as much.

I'd forgotten to specify that a native build for this was contributed by haxatax a few months back. It was the true, native build of angrylion's plugin in VS2010 with the default 1024x768 window size and "my little plugin" title, which were some additional complaints made in the "SoftGraphic" thread. People wanted a basic 320x237 screen for non-pixilated, "native" screen graphics so that VI interpolation wouldn't have quite so much to interject with.

Ya, like I said the plugin was LLE. Why would a pixel-accurate plugin be HLE anyway. There's a difference between making the RSP redirect execution to another plugin and genuinely having a HLE algorithm.

Another thing, the 320x240 plugin. It looks too sharp. I'm convinced the filters are not applying correctly on that one. I know the filtering should less noticeable, but I shouldn't be seeing jaggies, not even on this res.

*edit*
I guess it depends on the game. I was playing Superman and it's jaggied as hell. But then I put Majora's Mask and everything looks perfect. I guess Superman is so crappy that it doesn't even use antialias?

Anyway, VI filters are controlled by the VI registers and can all be turned on or off by the game at any moment. This is all the unmodified, original plugin code, and there is negative 100% reason to think there's a bug that filters aren't properly being applied.

Game decides whether to deactivate or whether filters are used at a stage, so yes, you might see "unfiltered" screens for some games. This is accurate.

**EDIT**

Quote:

Originally Posted by ReyVGM

*edit*
I guess it depends on the game. I was playing Superman and it's jaggied as hell. But then I put Majora's Mask and everything looks perfect. I guess Superman is so crappy that it doesn't even use antialias?

HAHAHAHA, Superman 64! I love that game.

Biggest fucking piece of shit ever released for the Nintendo 64. Don't be surprised if it's not just the graphics that suck.

Quote:

Originally Posted by ReyVGM

So I should disable the "Use High Level GFX?" option in PJ64?

Depends which RSP plugin spec is being used.

If you're just using the RSP plugin I wrote then don't worry about it; that setting is impertinent and gets ignored.

I still think that the VI filters can be done as pixel shaders in HLE plugins. The things that would be interesting to replicate would be the dither matrices.

Afterall, pixel shaders work per-pixel, just like that massive loop in the software rasteriser. And pixel shaders have access to each pixel in an image.

So theoretically, one could make the plugin only draw the raw image in the framebuffer, and then apply the VI filters as a pixel shader? Would be quite a bit faster then, I'd imagine, as opposed to doing the entire thing on software.