Pixel-Accurate N64 Software Video Plugin

[HatCat]

Originally Posted by HatCat

3. If using "user-defined" or "DP frame buffer" screen resolution formulas, force user-defined or auto-detected frame buffer height to show extra pixel rows omitted by the DAC.

I've changed my mind about this one.

In most games from what I've seen, usually VI_DRAM_ADDR_REG has an origin that is one scanline below the top-most one you could see in RDRAM itself if you had used a utility like my PixD invention, or something else like LemAsm to analyze it. Zelda64 for example, either OOT or Majora's Mask, always seem to store the frame buffer as 320x240 pixels at 000500 hex.



This is 500 hex bytes deep into the RDRAM I dumped and opened in PixD.

Actually, VI_ORIGIN_REG always seems set to 0x00000780, again in either MM or OOT, at least based upon my tests in Nemu64, Mupen64 and Project64. This happens to be exactly 320 pixels later than what the above screenshot was taken at, so we scroll down by one scanline:


Garbage. Once we crop only the top 237 scanlines and ditch the bottom 3, we have the source frame buffer dimensions for sending to the analog output on the final screen. For this reason the low 3 scanlines are black.

So yeah, forget about the 3rd item. Just use my utility that I'll release along with my plugin next if you want to get the full 320x240 pixels instead of the RCP-offset unfiltered screen image.

[ReyVGM]

Looks good. I'll test it out when you release the tool.

[HatCat]

There should be a new release now posted at EmuTalk forums as a new thread.
Forum --> Community Projects --> Emulator Plugins --> angrylion's Per-Pixel RDP with OpenGL

It's fine if some people find it easier to still use this thread to discuss the plugin.

Sorry, the PixD utility release didn't make it into the same archive as the graphics plugin release. I meant to have it as part of the plugin download as an extra in the archive, but that plan didn't really make it in the end. I think I will see about making a separate thread for that.

[HatCat]

ReyVGM : http://www.emutalk.net/attachment.ph...1&d=1430085807

You can use that to open binary files as pixel maps. As said in the readme in the zip, press the '4' key on your keyboard to switch to 16-bit color decoding after a file is open in PixD, which is what most (not 100% though) of N64 games use for the frame buffer screen.

[ReyVGM]

Sorry, I was away for a bit.

I'm a bit tired, but I tried the new plugin, which is now called vigl instead of mylittlecomment.

Tried Goldeneye, it seems that when using DP framebuffer now everything seems more filtered? With DAC filters on, that's the old default with the filters on at 320 and 640, right? With that on, I'm getting a lot more filtering.

I don't quite understand the PiXD tool. Is that the method you said you were going to do to be able to take the filtered and non-filtered screenshots in a certain bitmap format?
I pressed F3 and I saw the same unfiltered image as before. I used the Write DRAM option and dropped the bin into the PiXD tool and all I saw was garbage.
I see PiXD as having some use, I guess I can use that to view hidden graphics and stuff. Should be great for people that hunt unused content. But it's a bit complicated if I just want to take screenshots? I don't know if I'm confusing two different things though.

I think I'm going to wait until you implement that 'hack' I requested before, the one where I could take screenshots in non-standard resolutions (like Goldeneye), but with the filters on. I've pretty much played all the 320x240 and 640x480 games available, all that's left are the ones with non-standard resolutions. That's really the option I've been waiting all my life when it comes to N64 plugins :P

Tomorrow I'll do a few more tests after you tell me why I'm getting more filtering at 320x240.

[HatCat]

Originally Posted by ReyVGM

Tried Goldeneye, it seems that when using DP framebuffer now everything seems more filtered? With DAC filters on, that's the old default with the filters on at 320 and 640, right? With that on, I'm getting a lot more filtering.

Can't tell what you're saying, GoldenEye often runs at 440x330 so the filters always as they should bring the image up to 640x480, you elect to scale it back down to 320x240?

Side-by-side screenshots showing this extra filtering since the old release would be nice.

Originally Posted by ReyVGM

I pressed F3 and I saw the same unfiltered image as before.

If you choose the DP frame buffer screen resolution setting, then of course the plugin will log an unfiltered BMP image. That's the way the original bitmap is...no filters and 320x237 or whatever.

Change to a different setting like "VI register layout" or "User-defined", and then pressing F3 will write the DIB extension instead of the BMP extension, and read directly from the window surface if it includes the filtering.

The obvious choice would be "VI register layout" because that's the native resolution. You can just open the 640x480 VI-filtered DIB screenshot file and resize it through whatever downscale operation in GIMP or whatever that you prefer. Otherwise, you can set a user-defined resolution of 320x240 in the plugin settings if you would rather let the plugin's OpenGL handling decide its own arbitrary choice of downscale for you.

Originally Posted by ReyVGM

I used the Write DRAM option and dropped the bin into the PiXD tool and all I saw was garbage.

Do you know what a README is?

There's two of them: README and readme_n64.txt. You could have at least opened the _n64 one of them.

Originally Posted by ReyVGM

I see PiXD as having some use, I guess I can use that to view hidden graphics and stuff. Should be great for people that hunt unused content. But it's a bit complicated if I just want to take screenshots? I don't know if I'm confusing two different things though.

It's for both. Textures, hidden graphics, tile memory, frame buffers in 320x240 or 640x480 sent to the VI for filtering...N64 RAM contains all of that stuff in memory. You just have to look for it, except that due to the filename assigned to your RCP_XXXXXXXX_YYYYYYYY.bin files, you already know the exact address where PixD can find it. It's (XXXXXX).

[ReyVGM]

Originally Posted by HatCat

Can't tell what you're saying, GoldenEye often runs at 440x330 so the filters always as they should bring the image up to 640x480, you elect to scale it back down to 320x240?

Side-by-side screenshots showing this extra filtering since the old release would be nice.

By the way, not complaining, I'm just asking why is there more filtering.

Here are two. Notice the text. The one on the left is with the previous version, and the right one is the current version. The right one looks to have more filters applied, even at 320, Force NN is off (if it's on, it's even more filtered).



Same here, top text from the previous version, bottom text from the current version:



In the previous version, if I turned Force NN off, it would like the Left and Top examples (that's how it looks on older versions too), but in this version with Force NN off it looks more filtered now.

If you choose the DP frame buffer screen resolution setting, then of course the plugin will log an unfiltered BMP image. That's the way the original bitmap is...no filters and 320x237 or whatever.

Change to a different setting like "VI register layout" or "User-defined", and then pressing F3 will write the DIB extension instead of the BMP extension, and read directly from the window surface if it includes the filtering.

Noticed that now that I'm more rested. From what you said the previous times I thought the plugin was going to take both screens at the same time or something. It's fine the way it is now yep.

The obvious choice would be "VI register layout" because that's the native resolution. You can just open the 640x480 VI-filtered DIB screenshot file and resize it through whatever downscale operation in GIMP or whatever that you prefer. Otherwise, you can set a user-defined resolution of 320x240 in the plugin settings if you would rather let the plugin's OpenGL handling decide its own arbitrary choice of downscale for you.

For screenshot purposes, I would rather wait for the screenshot hack you said you were going to look into some months ago.
As far as emulation goes, it's aces.

Do you know what a README is?

There's two of them: README and readme_n64.txt. You could have at least opened the _n64 one of them.

Yes I know what a read me is. No need to be sarcastic. It was late and I was tired.
I read your explanations on the other forum and I tried the tool. Thanks for that option. I believe no other emulator has a VRAM viewer for N64 games, so it will be good for people that like to hunt down unused content.

[HatCat]

Originally Posted by ReyVGM

By the way, not complaining, I'm just asking why is there more filtering.

Here are two. Notice the text. The one on the left is with the previous version, and the right one is the current version. The right one looks to have more filters applied, even at 320, Force NN is off (if it's on, it's even more filtered).

This comparison is one between apples and oranges. You might recall that the native resolution is 640x480 and that the N64 never down-scales from that. If you on your own decide to downscale the window to something smaller than the native resolution, like 320x240, then that is up to the renderer what technique it uses for resizing the image, since whatever that technique is, it does not happen on the real system because there was no down-scaling from 480i.

Now, if you had 2 640x480 screenshots of the same image taken by two different versions of my angrylion plugin, yet one looked more filtered than the other, *then* that would mean I was adding at some point extra VI filtering. What you're observing is a change to the OpenGL texture rectangle blitting, which indirectly affects what happens when you resize the window.

Originally Posted by ReyVGM

Same here, top text from the previous version, bottom text from the current version:



In the previous version, if I turned Force NN off, it would like the Left and Top examples (that's how it looks on older versions too), but in this version with Force NN off it looks more filtered now.

Well, turn Force NN on.

Previous versions of the plugin defaulted to having it on ("GPU-accelerated scaling" off means it didn't use the bi-linear scaling method.) This is just a question of individual configuration preference.

Remember that NN refers to point-sampled, standard pixel resize. The blocky pixilated look from doubling the size of an image from 320x240 to 640x480 is nearest-neighbor. If you turn off NN, it uses GL_LINEAR instead, which uses a more logarithmic scaling process which causes the supposed "blur" look.

I used the "File Select" screen in Super Mario 64 for my tests a year ago. When choosing to resize it down to 320x240 with the VI filters still enabled in the previous version of the plugin, I noticed that either NN forced on or off looked slightly less sharp, than the way I could get it to look in the new version of the plugin I have just released, if I use textured triangles instead of glDrawPixels.

But yeah, if you open the 640x480 image in GIMP or something then resize the image, GIMP will probably ask you what method you want to use for resizing it. I think if you choose bicubic or bilinear, something like that, you will get the same exact result as with Force NN disabled in this plugin. So it's not an added filtering issue; it's a question of how you are configuring the plugin to display the image at lower than the native 640x480 screen.

Originally Posted by ReyVGM

Noticed that now that I'm more rested. From what you said the previous times I thought the plugin was going to take both screens at the same time or something. It's fine the way it is now yep.

I don't at all blame you for not noticing the change in the screenshots. It's not one of my more self-explanatory changes I made since the last release. In fact the only allusion I ever made to it at all was in the readme.txt change log list for the new release, which I wrote mostly for smallness rather than detail.

However, I did end up changing it because of your problem with having screen capture files being overwritten from not preserving the counter after closing/starting the emulator program. In the process, it was too difficult a problem to solve with writing both screenshots at once, so I changed it. In the process, I concluded that the most accurate choice is that BMP, non-filtered screenshots should be generated if "DP frame buffer" is selected, and VI-filtered DIB screenshots otherwise.

Originally Posted by ReyVGM

For screenshot purposes, I would rather wait for the screenshot hack you said you were going to look into some months ago.

Not remembering what hack I was talking about?

Was it before I talked about relying on my PixD utility instead? (I don't mind if people call it PiXD either with the uppercase 'X' since that is part of the name pun.)

[ReyVGM]

Originally Posted by HatCat

Now, if you had 2 640x480 screenshots of the same image taken by two different versions of my angrylion plugin, yet one looked more filtered than the other, *then* that would mean I was adding at some point extra VI filtering. What you're observing is a change to the OpenGL texture rectangle blitting, which indirectly affects what happens when you resize the window

Any chance of getting back that old behavior back in future releases?

Well, turn Force NN on.

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

However, I did end up changing it because of your problem with having screen capture files being overwritten from not preserving the counter after closing/starting the emulator program. In the process, it was too difficult a problem to solve with writing both screenshots at once, so I changed it. In the process, I concluded that the most accurate choice is that BMP, non-filtered screenshots should be generated if "DP frame buffer" is selected, and VI-filtered DIB screenshots otherwise.

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.

Not remembering what hack I was talking about?

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."

[HatCat]

I'm still unable to identify what it is you're misconceiving, so I'll have to post this comparison myself.

{ A, B,
C, D } =




A (upper-left): current release, Force NN ON
B (upper-right): current release, Force NN OFF
C (lower-left): old release (final attachment in this thread), GPU-accelerated scaling ON
D (lower-right): old release, GPU-accelerated scaling off

So what's the problem again? Do we not find that the upper-right result looks the best?
Or is it that you have somehow stumbled upon a fifth, even better option?