Pixel-Accurate N64 Software Video Plugin

[HatCat]

Originally Posted by ReyVGM

It looks even worse :P
As in, even blurrier.

It actually looks sharper.

Switch to native 480i resolution, turn Force NN off. That's blurry. Turn it on. That's sharp.

It looks blurrier to you when down-sizing the image to 320x240 because the native RCP filters already applied a blur-related effect to the image, so the blurry Force NN=disabled counteracts the blur with blur, which is why it looks less blurry to you if you leave it off at a hacked resolution than if you turn Force NN on.

Originally Posted by ReyVGM

Yep, that works just fine. Anyone can convert the images on their own if they want. Anyone that deals with images should already have a batch convertor in some form.

Plus the raw screenshots were just the 320x237 active video source without the VI filters. You would get more of the full 320x240 screenshot (the missing 3 lines) if you just clicked "Write DRAM" and opened the CPU memory in my PixD utility instead of printing the screen yourself from the "DP frame buffer" resolution formula results.

Originally Posted by ReyVGM

You can find my original conversation here:
http://forum.pj64-emu.com/showpost.p...postcount=1703

And your reply:
http://forum.pj64-emu.com/showpost.p...postcount=1704

Synopsys:
I learned that you were only going to allow taking screenshots of non-standard resolutions without the filters.
And I said that as long as you are adding other options (hacks) to the plugin, why not add a way to take screenshots with non-standard resolutions with the filters included too, for my sake.

After some back and forth, you replied with this:
"Okay. Well in a later release I can think about how hard it would be to add an option for applying the filters to the wrong resolution (dynamic changing ones before scaling to 640x480), but as this has nothing to do with current fixes or accurate hardware behavior I'm fairly sure that isn't going to make it in the next release I'm about to do (too many other little goals left to take care of first).

It's even possible I might have to re-implement the code for some of the VI filters to not rely on the correct 640x480 assumption, which means I might have to add extra code to the plugin to do what you want. So it's something I can try to look at in a future release, but most likely not the upcoming one."

Well, yes, I remember that, but what was confusing me from your post was that you said, "I would rather wait for the screenshot hack you said you were going to look into some months ago." I'm unaware of discussing any screenshot hack. What you just cited now was me saying I would try to consider your hack request to apply the filters to the wrong resolution, not hack screenshots.

I'm still not really sure that that's going to be able to possibly work out the way you're hoping for honestly. The only reason something like goldeneye or mario64 looks as good to you as it does running in a 320x240 window with VI filters on, is because among the filters is included the native 640x480 workspace to be able to do them effectively. If I took the 320x240 frame buffer and THEN did interpolation, anti-aliasing, dithering/gamma etc. filters to that, I can promise it would look different than the current result you are getting by doubling all pixels to 640x480 and then doing it and then having you re-resize the image back down. That being said, I did tell you that I was going to try to look into how manageable/desirable (even to you) it would be to do what you want, so yeah, I'll try to remember to investigate that further. Just keep in mind I have to balance these feature/hack requests against all this time I've spent not making the RDP faster so that people can use this plugin at full speed.

[ReyVGM]

These have all been taken with an external screenshot program. The emu window was at 320x240 with all examples.



A (upper-left): mylittle-nocomment v3, DAC Filters enabled
B (Middle-left): Angrylion RDP 1.2, DAC Filters enabled, GPU Accelarated Scaling On.
C (Middle-right): Angrylion RDP 1.2, DAC Filters enabled, GPU Accelarated Scaling OFF.
D (Lower-left): Angrylion RDP 1.5, DAC Filters enabled, Force NN OFF.
E (Lower-right): Angrylion RDP 1.5, DAC Filters enabled, Force NN ON.

As you can see, mylittle-nocomment v3 looks the best.

Here's an animated gif between v3 and 1.5. Nevermind the colors, just look at "Mario A".



Same example, look at the text:


That's the difference I was talking about before.


By the way, Perfect Dark doesn't seem to be loading with your plugin. It doesn't go past the Rare logo. It works fine with other plugins. The strange thing is that I remember the game loading fine before on your previous plugin versions, but it doesn't load now.

Well, yes, I remember that, but what was confusing me from your post was that you said, "I would rather wait for the screenshot hack you said you were going to look into some months ago." I'm unaware of discussing any screenshot hack. What you just cited now was me saying I would try to consider your hack request to apply the filters to the wrong resolution, not hack screenshots.

I'm still not really sure that that's going to be able to possibly work out the way you're hoping for honestly. The only reason something like goldeneye or mario64 looks as good to you as it does running in a 320x240 window with VI filters on, is because among the filters is included the native 640x480 workspace to be able to do them effectively. If I took the 320x240 frame buffer and THEN did interpolation, anti-aliasing, dithering/gamma etc. filters to that, I can promise it would look different than the current result you are getting by doubling all pixels to 640x480 and then doing it and then having you re-resize the image back down. That being said, I did tell you that I was going to try to look into how manageable/desirable (even to you) it would be to do what you want, so yeah, I'll try to remember to investigate that further. Just keep in mind I have to balance these feature/hack requests against all this time I've spent not making the RDP faster so that people can use this plugin at full speed.

Oh screenshot hack is just what I called it for short.

Although, since the window now resizes to the framebuffer resolution, and the filters are applied, and the graphics don't look messed up like the last release. Then I guess I can keep using the external screenshot program and get what I need without you having to cook up some screenshot hack only for me.

*edit*
I guess it doesn't yet. I tried Turok 2 and it still looks bad.
A few pages ago I also asked about why didn't games with non-standard resolutions looked "right" in your last plugin even if the window is at the correct resolution and even if the filters were off.
You said you were going to look into finding a way to have them games look "right" in a non-standard res window too while using DP Framebuffer, I believe.
I thought you had done it because Goldeneye looks a lot better than the previous release, but other games like Turok still look bad.

[HatCat]

Originally Posted by ReyVGM

These have all been taken with an external screenshot program. The emu window was at 320x240 with all examples.



A (upper-left): mylittle-nocomment v3, DAC Filters enabled
B (Middle-left): Angrylion RDP 1.2, DAC Filters enabled, GPU Accelarated Scaling On.
C (Middle-right): Angrylion RDP 1.2, DAC Filters enabled, GPU Accelarated Scaling OFF.
D (Lower-left): Angrylion RDP 1.5, DAC Filters enabled, Force NN OFF.
E (Lower-right): Angrylion RDP 1.5, DAC Filters enabled, Force NN ON.

As you can see, mylittle-nocomment v3 looks the best.

Wrong, you have DAC filters disabled in A and B, not enabled.

I would have thought that for all your preference in always keeping the VI DAC filters turned on all the time, even at the pre-filtering resolution, you would have known the difference between a VI-filtered image and one that does not have the filters applied to it

I can perfectly validate that Mario64's 320x240 16-bit frame buffer, stored in VRAM, before any DAC filters take place, looks like this:


If the lack of anti-aliasing, reverse-dither, "blurring", gamma or any other filters in this screenshot looks at all familiar, it's because two of your 5 images are the same thing.

Originally Posted by ReyVGM

Here's an animated gif between v3 and 1.5. Nevermind the colors, just look at "Mario A".

Just looking at that animation by itself, even with the low GIF palette color quality, is enough to tell me you did not have DAC filtering enabled in all tests.

Originally Posted by ReyVGM

Same example, look at the text:


That's the difference I was talking about before.

Judging by the presence of anti-aliasing and some extent of blur in both of your GoldenEye slides, I would say that this time, you did include DAC filters for testing that time. Therefore, it's not the same comparson I was trying to understand when using Mario64 as an example, since you remembered to always maintain enabling the DAC filters for one of the game tests but not the other.

Originally Posted by ReyVGM

By the way, Perfect Dark doesn't seem to be loading with your plugin. It doesn't go past the Rare logo. It works fine with other plugins.

RDB issue. The more you HLE something, the less dependent the game's execution is on the accurate emulation of external components. (e.g., high-level graphics plugins can emulate the RSP internally rather than relying on an [a-]synchronous RSP emulation thread to do it.)

So that's a issue with recompiler CPU settings in pj64. We just happen to be testing a LLE plugin that better exposes these sorts of problems.

Originally Posted by ReyVGM

The strange thing is that I remember the game loading fine before on your previous plugin versions, but it doesn't load now.

must have upgraded/downgraded the RDB file since then

Originally Posted by ReyVGM

A few pages ago I also asked about why didn't games with non-standard resolutions looked "right" in your last plugin even if the window is at the correct resolution and even if the filters were off.
You said you were going to look into finding a way to have them games look "right" in a non-standard res window too while using DP Framebuffer, I believe.
I thought you had done it because Goldeneye looks a lot better than the previous release, but other games like Turok still look bad.

I remember saying that it should be possible if DAC filtering is bypassed.

[ReyVGM]

Originally Posted by HatCat

Wrong, you have DAC filters disabled in A and B, not enabled.

It is completely and 100% enabled. I've made sure of that since the very start.

I would have thought that for all your preference in always keeping the VI DAC filters turned on all the time, even at the pre-filtering resolution, you would have known the difference between a VI-filtered image and one that does not have the filters applied to it

I'm disappointed that you think I'm that stupid to have had filters disabled all this time, even with the tons of examples and tests I've posted here.

I can perfectly validate that Mario64's 320x240 16-bit frame buffer, stored in VRAM, before any DAC filters take place, looks like this:

I do know the difference. Even so that the image you posted is different from the one I posted. Notice the background, the darker parts. In your image it lacks dithering, but on my image it's filtered.

You can get it out of your mind that I've had filters disabled. My screenshots are accurate.

If the lack of anti-aliasing, reverse-dither, "blurring", gamma or any other filters in this screenshot looks at all familiar, it's because two of your 5 images are the same thing.

Yes, the top-left and middle-left images are the same. Both have filters enabled, the middle-left one has GPU scaling enabled (or Force NN off in your newer version).

That's why I'm asking why it looks more filtered with your newer version, because with Filters On and NN off, it should net me the same results as your previous versions, right?

Just looking at that animation by itself, even with the low GIF palette color quality, is enough to tell me you did not have DAC filtering enabled in all tests.

Judging by the presence of anti-aliasing and some extent of blur in both of your GoldenEye slides, I would say that this time, you did include DAC filters for testing that time. Therefore, it's not the same comparson I was trying to understand when using Mario64 as an example, since you remembered to always maintain enabling the DAC filters for one of the game tests but not the other.

I NEVER EVER turn off the filters. So again, you can remove that thought from your mind. Goldeneye looks more filtered because Goldeneye by default is "blurrier" than Mario 64. You can't really compare text from one game to another.

RDB issue. The more you HLE something, the less dependent the game's execution is on the accurate emulation of external components. (e.g., high-level graphics plugins can emulate the RSP internally rather than relying on an [a-]synchronous RSP emulation thread to do it.)

So that's a issue with recompiler CPU settings in pj64. We just happen to be testing a LLE plugin that better exposes these sorts of problems.

must have upgraded/downgraded the RDB file since then

Hmm, I do remember downloading a newer version some time ago yes. Crap.

*edit*
Went back to a previous version, and the game still doesn't load. Not even in interpreter mode.
I could swear it worked before.

I remember saying that it should be possible if DAC filtering is bypassed.

Well, that's the next "feature" I'm going to wait for

[HatCat]

Originally Posted by ReyVGM

I'm disappointed that you think I'm that stupid to have had filters disabled all this time, even with the tons of examples and tests I've posted here.

Never said or even implied "all this time"; I clearly pointed out specific screenshots A and B that did not seem at all to match your GoldenEye comparison nor the other 3 screens, at which points you obviously DID have the filters enabled and not disabled.

Originally Posted by ReyVGM

My screenshots are accurate.

"Accurate", then? What's this? I thought for sure you realized before that you knew what you were asking me to do was an inaccurate hack--apply the filters prematurely at the wrong workspace resolution. Now instead, you're implying that shrinking the accurate 640x480 screenshot to arbitrary resolutions like 440x330 or 320x240, at which point no filtering existed at all, is accurate?

There are only two ways it can be an accurate screenshot: You either disable the filters under the intention of taking a screenshot of what the RDP or CPU drew to the frame buffer by itself, or you leave the filters turned on at the 640x240 or 640x480 resolutions (possibly higher, but never lower).

Resizing from 640 pixels wide to 320 pixels wide is a loss of information--you cannot possibly have the right idea to claim accurate screenshots when throwing out hardware-accurate information like this. You still have yet to experiment with my suggestion: Try resizing the 640x480 result in GIMP or whatever, to 320x240. GIMP itself, not just this plugin, has different scaling interpolation options at cramming the 640x480 source into 320x240--the fact that there are multiple possibilities for throwing out the full pixel information should tell you that there is no singular accurate screenshot from the process.

Originally Posted by ReyVGM

That's why I'm asking why it looks more filtered with your newer version, because with Filters On and NN off, it should net me the same results as your previous versions, right?

I've said this before. GPU-accelerated scaling ON and filters ON in the final release posted to this thread (which is to say, the previous version to the current) looks like this here:


I am not at all getting the result you posted; it looks terrible for me. This is what I had to improve since the previous versions with the scaling method. Maybe you have some sort of GPU or driver configuration where it looks even better on the older version of the scaling algorithm I used, but considering that it looks a lot worse for me, I don't think it's worth it if all it's being to be abused for is inaccurate screen sizes in exchange for re-corrupting the result on my end just so it looks better on somebody else's.

Originally Posted by ReyVGM

I NEVER EVER turn off the filters. So again, you can remove that thought from your mind. Goldeneye looks more filtered because Goldeneye by default is "blurrier" than Mario 64. You can't really compare text from one game to another.

Examining the comparison more closely from the color storage, it appears to have less to do with filters on/off than I thought, so much as it is how the driver is choosing to scale the image through its own optimization. For the best performance, it will often pick its own thing, and I see no problem with this.

[ReyVGM]

Originally Posted by HatCat

Never said or even implied "all this time"; I clearly pointed out specific screenshots A and B that did not seem at all to match your GoldenEye comparison nor the other 3 screens, at which points you obviously DID have the filters enabled and not disabled.

Well I can assure you the filters were enabled on all examples. And the screens were taken with a screenshot program while the window was at 320x240.

"Accurate", then? What's this? I thought for sure you realized before that you knew what you were asking me to do was an inaccurate hack--apply the filters prematurely at the wrong workspace resolution. Now instead, you're implying that shrinking the accurate 640x480 screenshot to arbitrary resolutions like 440x330 or 320x240, at which point no filtering existed at all, is accurate?

No wait, I meant accurate as to the options I said were enabled/disabled.
Meaning that if I said filters were enabled, then my examples were accurate to that.

I've said this before. GPU-accelerated scaling ON and filters ON in the final release posted to this thread (which is to say, the previous version to the current) looks like this here:


I am not at all getting the result you posted; it looks terrible for me. This is what I had to improve since the previous versions with the scaling method. Maybe you have some sort of GPU or driver configuration where it looks even better on the older version of the scaling algorithm I used, but considering that it looks a lot worse for me, I don't think it's worth it if all it's being to be abused for is inaccurate screen sizes in exchange for re-corrupting the result on my end just so it looks better on somebody else's.

Well, the final release posted here (version 1.2), with filters on and GPU scaling on, window at 320x240, looks like the examples I posted. But it wasn't 'perfect' because that release was removing/adding horizontal lines (as I reported back then).
Maybe my PC makes it look like my example, and your PC makes it look like your example, but regardless, I've always had filters on and every 320x240 example has been like that.

But if you take a look at this post from you from July 2014 , Mario 64 file select screen, one without filters and one with filters. Your filtered one looks exactly like my example.

You were probably using mylittlenocomment v3 back then, and not the final release posted here though.

Which is why I asked the original question: "Why does it look more filtered now?" (when compared to all the previous versions, sans 1.2).
But you already answered that, because you are using a different method now.

Examining the comparison more closely from the color storage, it appears to have less to do with filters on/off than I thought, so much as it is how the driver is choosing to scale the image through its own optimization. For the best performance, it will often pick its own thing, and I see no problem with this.

Using the Mario 64 image, there's no way to get that old behavior from mylittlenocomment v3 back in your latest version?
And the more filtered look of your latest version is more accurate then? (even if there's nothing accurate about a 320 filtered image).

I know you can't remember or keep track of all my posts and questions, but every new release that introduces some new option that adds any kind of additional filtering, I always ask you about it. I think at 320x240 with filters on, mylittlenocomment v3 looks the best.


As for Perfect Dark. I don't know specifically what the RDP does, but doesn't that just control what specific game options are enabled/disabled? Or does it actually do something (other than that) to make games playable or to break them?
Because I tried older RDP's, and I tried turning on/off all the game options for Perfect Dark and it just doesn't load. I remember the game loading just fine some months ago.

[fallaha56]

So...been doing a more testing

New version 1.5 defo better than old one (image 1), less pixel craw

But new one still shows obvious diagonal pixel crawl esp on the letter M -interestingly this is still there in the v1.2 plugin! (image 2/3)

All crawl goes away with VI filters off...

Hope this is helpful

[HatCat]

Yeah, it looks this way for me, but you should enable Force NN when reporting bugs so that the individual, actual pixels become clearer for this sort of analysis.



I think this seems as it does on the original system. VI filters are mostly a raster operation; they don't carefully analyze triangles and things like that to make sure they didn't displace or glitch a few pixels here and there. That's another reason why people might from time to time think a little more highly about turning them off.

[HatCat]

ReyVGM: You don't seem interested in trying my experiment I suggested, so I think I will try this experiment for myself.

Like I said, take the original, unmodified final result of what comes out from the system:


Now, open it up in GIMP or whatever you use. I just happen to have GIMP installed since I accidentally my old installation of Jasc Paint Shop Pro. To re-size the image, choose "Scale Image..." from under the Image menu.

Set it to resize to 320x240.


If I leave the down-sample technique at the "None" default setting, the result is:


And then you have other options, like "Linear", which is the method that Force NN=OFF constitutes (scale via GL_LINEAR sampling internal to GL implementation). "Cubic" doesn't look any worse than the result you suggested either. Don't fail to realize that there's more than one option--more than one option for destroying 50% of the original image's information by subtracting unique pixels. It's only logical that, since the VI interpolates the frame buffer from 320x240 to 640x240, you may as well pick whatever interpolation method of your own to counteract that interpolation if you're so focused on just whatever looks best.

So why hack the plugin with multiple hacking options when you can just resize the image this way?

Not that you should be resizing it at all when the filters are on, but whatever. I guess you'll have to pick: 320x240 full picture stored in RDRAM that you can view in PixD, or only 237 out of 240 of the pixel rows but with VI filters applied to them. If you'd rather throw away the 3 pixel rows that the VI itself throws away when doing the filters, than to just settle with the REAL original, native and unfiltered 320x240 image so that you don't have to resize anything, then God speed to ya.

[fallaha56]

Interesting x2

For what it's worth that was with NN on BUT it looks like the forum's image uploader does some nasty smoothing...

In case it's relevant also notice the odd wandering pixel even with filters off -as you say presume that is just limitations of native N64 rendering -think I got a little too used to hi-res HLE in the past lol!

Ps really appreciate the hard work/devotion to cause -happy to donate cash/hardware if it will help, sure as hell can't help you code an RDP! :-)