Pixel-Accurate N64 Software Video Plugin

[mudlord_]

Possibly. I haven't looked much into software RDP emulation, but yeh, I don't see why not.

Things like coverage would still be done in software though, and same with some blender modes that some games use like Monster Truck Madness 64.

[ReyVGM]

Originally Posted by HatCat

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.

Hehe, yeah. But I never finished it back in the day, so I decided, why the hell not now?

I guess that crappy game just disables the filters because Majora's Mask looked perfect.

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'm using one called "Static Interpreter". I don't know if that's yours because for some reason none of the plugin file names actually match the names the plugin selector on the emulators show.
For example, this angrylion plugin: file name is "mylittle-nocomment" but the name on the emulator is "angrylion's RDP r77", and it's repeated twice because one is 320x240 and the other is 640x480, but there's no way of knowing which is which unless you try them

[HatCat]

Originally Posted by ReyVGM

I'm using one called "Static Interpreter". I don't know if that's yours because for some reason none of the plugin file names actually match the names the plugin selector on the emulators show.

They don't have to. Filename of the DLL plugin doesn't dictate what ASCII name string the plugin's name is.

struct PluginInfo.Name[100] is not the same thing as the Windows operating system filename you downloaded the file as.

I named it rsp.dll because that's the filename you have to use when installing it to Project64 1.6 anyway. And Project64 1.6's RSP LLE interpreter is most definitely still bugged in a few places (Mario 64 LLE gfx, Resident Evil 2, Mario no Photopie, ...), not to mention slower anyway, so there's no point in using it. I had only one sensible choice of filename to give, you see.

Originally Posted by ReyVGM

For example, this angrylion plugin: file name is "mylittle-nocomment" but the name on the emulator is "angrylion's RDP r77",

It used to be "my little plugin", but, that name's retarded anyway. I re-named the plugin title into something more specific, to include the revision number. That was why BigHead posted that hex edit with the renamed dll after all.

Originally Posted by ReyVGM

and it's repeated twice because one is 320x240 and the other is 640x480, but there's no way of knowing which is which unless you try them

Heh, yeah that is annoying.

In the first attachment I did to this thread the other one used to be named "angrylion's RDP r77 (320x237)". The reason why both DLLs have the same name is related to software policy...legally speaking when you release modified binaries you have to post the source code in this license, and I didn't want to throw in extra main.cpp source file's, one for every single plugin name I gave. That was annoying.

Still, it's not really worth resetting the attachment over either. It's easily hex-edited enough though, since I disabled Unicode character sets. Uhhh for newbs you can open the .dll file in Microsoft Notepad, search for "angrylion's RDP" in the text and edit it!

[but srsly don't try that, use a hex editor, maybe BigHead can help :P]

[ReyVGM]

I don't really care how they are named. My problem is that I don't know which is which since the .dll name doesn't match the one on the emulator.

I try changing the name with the hex editor then.

*edit*
Ok I couldn't do it. I thought I could just edit it like in notepad. But I guess it doesn't work like that.

I used notepad+, but then the emulators crashed.

*edit 2*
I guess adding data to the .dll made everything crash. But now I replaced "r77" of the internal name to 320 and 640 respectively and it worked

[HatCat]

Can't tell what the deal was. You can name a .dll file whatever you want; it has nothing to do with the actual plugin's name string the plugin tells the emulator to project. File names have nothing to do with internal name strings.

Anyway yeah, when editing an executable you also have to not break alignment issues. If you replace 3 bytes with 3 bytes it's fine, but if you change "r77" to "rlolwut"? you break program offsets.

[ReyVGM]

Originally Posted by HatCat

Can't tell what the deal was. You can name a .dll file whatever you want; it has nothing to do with the actual plugin's name string the plugin tells the emulator to project. File names have nothing to do with internal name strings.

I understand that, but then I don't know which plugin goes with what internal name. Specially when you have a lot of plugins and are afraid to delete what you don't use in case you break something.

[HatCat]

I probably should have moved the plugin name string to a preprocessor macro, defined in the VS project files rather than the source code. That would have evaded the legal technicality of having to include source code to all released, modified binaries (even if the only modified part of the binary was a simple text string :/). I was trying to stay on the legal safe side of the MAME license, but, looking back at it I could have just made the screen resolution, not the only thing moved out of the source, to the preprocessor.

Oh well. Look on the bright side! It happens to me too. I probably could hex-edit it like you did to rename one of the two matching plugin names, but for now I'll be a stubborn, lazy masochist and put up with it.

[ReyVGM]

Is there anyway to fix the frequency in which the plugin makes the emu freeze/crash when saving and loading states?

I've only used this plugin to play games so I thought the save states where just broken globally, but then I played a game with the SoftPlugin and wow, not a single freeze or crash after saving/loading.

Or maybe is the RSP's fault? I don't know, but there is a disproportionate amount of save state crashes when using the Angrylion + Static Interpreter combo.

*edit*
It's definitely the RSP. I'm using the z64 RSP now and no crashes whatsoever.

[GPDP]

Did you try them in another version of the emulator?

Also, one interesting thing about SoftGraphic is that it would run quite slowly for me in windowed mode, but would speed up quite a bit in fullscreen. I'm attributing that to Windows, or at least my graphics card drivers under Windows, but still, weird. Wonder if this plugin would act similarly if a fullscreen option was implemented?

Also, damn shame the Mupen64Plus devs have yet to incorporate this plugin into their repo. Seems like it would be right up their alley, even if most people cannot run it at full speed.

[HatCat]

Originally Posted by ReyVGM

*edit*
It's definitely the RSP. I'm using the z64 RSP now and no crashes whatsoever.

That implies your settings for the RSP were at fault.

You should know how unstable saved states are. The emulator has problems re-synching everything completely, especially when things are emulated at an op-code-accurate level in LLE.

z64 RSP = old RSP code with HLE audio enforced.
So to mimic that in my plugin you would simply check the second config option to send audio lists to audio plugin.

Originally Posted by GPDP

Also, one interesting thing about SoftGraphic is that it would run quite slowly for me in windowed mode, but would speed up quite a bit in fullscreen. I'm attributing that to Windows, or at least my graphics card drivers under Windows, but still, weird. Wonder if this plugin would act similarly if a fullscreen option was implemented?

That isn't really internal to anything. All full screen essentially does is just take away the window border, hide the mouse cursor and run the screen at your monitor's size. If you notice faster speed, it's a coincidence because of something implemented alongside that.