Pixel-Accurate N64 Software Video Plugin

[HatCat]

*** deleted ***

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.

[HatCat]

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.

[mudlord_]

I'm pondering starting work again on graphics emulation, so a litmus test for games would be most helpful.

[HatCat]

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.

For 1024x768 window size and the original plugin title, here is the build haxatax posted.
http://forum.pj64-emu.com/showpost.php?p=50466

In the OP of the thread is a build of the obsolete, out-of-date mylittle-fptr trunk as well which maintenance stopped for years ago. It was the tree that Shunyuan chose for the "SoftGraphic" fork.

I took some detailed care to optimize a few compiler and linker settings and used VS2013 for the builds here.

[the_randomizer]

Yeah, strange issue with this plugin. For one, I see four duplicate entries in the settings that say "Angrylion's RDP r77", then when I load a game, the error "Process DList" appears. WTF?

Edit: Disabling HLE graphics helps the game further along, but the emulator crashes soon after.

Edit 2: PEBKAC, works now, it's cool seeing them with pixel accuracy.

[HatCat]

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.

[ReyVGM]

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

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?

[HatCat]

Not sure what you're referring to.

A screenshot would maybe help.

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**

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.

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.

[mudlord_]

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.

[GPDP]

Originally Posted by haxatax

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.