SoftGraphic graphic plugin

[Sigma_Virus]

Originally Posted by haxatax

why the fuck would you want to do that.

You're probably wondered, what drugs is this guy on?

Well if you interpreted that by all games, I meant all games in existence then that's not the case.

I don't own many N64 games to begin with, not even a dozen.
Many of the games I own is short and completed relatively fast except for a few exceptions like Zelda, Mario, GoldenEye, Perfect Dark etc.

So pulling something off like completing them all with every GPU plugins wouldn't be an impossible task, but I slightly exaggerated on that part.

However I'm bored, have been using Project64 1.6 for almost 9 years along with Jabo and Glide plugins and recently switched to 2.1 so of course I'm eager to try new things out, whether it be the SoftGraphics plugin, Angrylions plugin, Ziggys plugin etc.

[Chaoslux]

Originally Posted by HatCat

Technically every plugin has a use.
No plugin is completely without use.

The plugin here, however, is obsolete.
If you liked the screenshots you saw here, consider using angrylion's original plugin.

The one here is just illegal software that tried to make the plugin go faster by removing all the VI accuracy.
If that's a sacrifice you like, then simply use z64gl, which is 10 times faster than this plugin.

Every plugin has a use. The plugin here, however, is the only one that runs Pokemon Snap without the red dot bug. ;P

[HatCat]

Actually angrylion's plugin does that, not suanyuan changes.

Red dot issue has been fixed for a long time in the MAME.

[GPDP]

Angrylion's plugin and MAME definitely have the edge in accuracy. However, even though accuracy to the real hardware is their goal, the VI filter looks damn ugly on modern displays, and unfortunately MAME/MESS is unstable as hell, and Angrylion's plugin has zero options to speak of. All you get is a 1024x768 window and that's it.

I've thought for some time a good alternative to the fullblown accuracy found in MAME would be to do more or less what Shunyuan did with this plugin (strip out the VI filter and add resolution and filter options), but using the bleeding edge code found in Angrylion's nocomment branch, and without trying to make it "HLE" or pretend the code is such when it obviously is not. Shunyuan's execution was in poor form here, I would say, but the concept of where this plugin was going was not too bad IMO.

And before you say it would not be accurate without the VI filter, indeed it would not be, but even so, the end result would still be a much more compatible plugin with overall less issues (barring speed) than the HLE plugins.

[shunyuan]

Originally Posted by GPDP

I've thought for some time a good alternative to the fullblown accuracy found in MAME would be to do more or less what Shunyuan did with this plugin (strip out the VI filter and add resolution and filter options), but using the bleeding edge code found in Angrylion's nocomment branch, and without trying to make it "HLE" or pretend the code is such when it obviously is not. Shunyuan's execution was in poor form here, I would say, but the concept of where this plugin was going was not too bad IMO.

I embedded a modified RSP core inside this plug-in because I want to let RDP rendering and N64 CPU execution in parallel though multi-thread. PJ64 and other emulators execute the N64 CPU and RSP instructions sequentially in the same run loop and can't take advantage of multi-core CPU.

To verify what I said, you can run mario64 with the old version of this plugin with UI to switch VI filter (using LLE interface) and the latest one, then compare the speed, that's why the latest one runs faster.

[HatCat]

If that's true, then I suppose I owe you some form of apology Shunyuan.
I forgot about all that multi-threading talk from months ago.

It's not quite a priority I agree with (partly because it repels the purpose behind having zilmar's plugin spec in the first place), but at least it proves you did have some legitimate reason for merging two plugins in one. I thought for sure your reasons were more marketing-oriented than that. I guess that much I mis-estimated.

Originally Posted by GPDP

And before you say it would not be accurate without the VI filter, indeed it would not be, but even so, the end result would still be a much more compatible plugin with overall less issues (barring speed) than the HLE plugins.

No matter, whether it's momentarily more or less accurate.

I myself have just very recently created a temporary function that strips out all the VI filters, too, just like the plugin here does. The purpose is not to gain overall speed; it's to help me benchmark and isolate the RDP latencies more reliably and vectorize those. In the final result, I have no intention of [unconditionally] bypassing the VI filters...suppose there could be config options for it.

[ReyVGM]

I don't know if this has been mentioned (and excuse me in advance for not knowing the proper terms), but this plugin has repeated pixel lines in the graphics and in other cases, it cuts pixel lines away.

I only tested it on Mario Kart 64. But one of N64's resolutions is 320x240, right? Which in this case, MK64 uses.

To be able to tell what I'm trying to describe, you need to take the screenshots and compare them one after the other, so you can see the repeating pixel lines as you alternate the screenshots.

Here's a screenshot taken with an external program, while the game was windowed in the 320x240 resolution. You can see how the top part of "THE END" has a repeated horizontal graphic line (noticeable on the "T" and "D"). There's another repeated vertical line right in the middle of the castle too (hard to see until you compare them to the other images).




Here's a 2nd screenshot taken with an external program, while the game was windowed in the 640x480 resolution. I resized the image by 50%, to bring it back down to 320x240.
The "THE END" now looks fine, as you can see. The vertical line on the castle is properly showing now too. But there's a new repeated vertical line on the green area to the right (compare to be able to see).




And finally, here's a 3rd screenshot using the plugin's native screenshot capability, the resolution set is 320x240, but the screenshot comes out as 320x238. This one looks fine, no repeating lines and there's even more graphical information shown. If you notice to the right, on the edge of the image, you can see one more line of graphics that doesn't show up on the other screens. My guess is that the "repeating pixel lines" are pushing out of view actual graphical data.




Here's an animation of all 3 together:



So, questions: Is the real resolution 320x238? Should the plugin be showing even more graphical info since the native screenshot shows that it's missing 2 lines of pixels? What with the repeated pixel lines? Will this be fixed for the next release?

By the way, can someone add a proper screenshot option for this plugin? An option that lets you take numbered screens and not just a single "snap.bmp" that gets overwritten each time.

[HatCat]

Actually I understood your issue right away before posting anymore screenshots. The frame buffer resolution is actually 320x237, but the native NTSC VI resolution is 640x480. Either way, this plugin doesn't emulate pixel-accurate VI filtering, so that's why you see the repeated pixel lines. Ideally there should be VI interpolation going on in the background, but such things were removed so that the emulation wouldn't be as slow.

[ReyVGM]

I was just making sure I had explain myself with enough examples just in case no one understood the terms I was using.

So in layman terms, the actual resolution is 320x237, but it gets "upscaled" to 320x240, which in our old TV's wasn't noticeable due to the low definition and the N64's own blurriness?

[HatCat]

The frame buffer resolution is "upscaled" to whatever television screen you're using, and filtered by gamma, dithering, brightness, pixel interpolation, anti-aliasing, ... things which this plugin does not support. Those are other reasons why you would not notice it on a TV, because you ran it on a real N64.

So if Shunyuan's plugin is 320x240, then that would sort of be like the TV screen size, for our purposes.

Also it's not always 320x237. Sometimes it's ~640x480 or 512x384 (Star Wars games I think), or even other sizes. For most games it's 320x237, but yeah, Project64 FAQ says the native resolution is usually 320x240 ... not sure if that was just a roundabout guess?