Pixel-Accurate N64 Software Video Plugin

[HatCat]

I am fine without involving money, though I have for several years now lacked a real N64 and an available TV to output through or capture stuff.

And yeah, some of these games have really, really crazy graphics RDP bugs on the real hardware, totally messy stuff you'd think was just a bug in the emulator...when really it's HLE that fixes these bugs and LLE that emulates them!

[theboy181]

Hat is correct.. N64 was not perfect with texture handling by any means.

A good example is Chameleon Twist. The Kitty logo is ass on the REAL HW too.

[ReyVGM]

I understand your experiment, but I've had bad experiences with resizing images that way. Maybe Mario 64 gives you perfect results, but other games might not.

I can still keep using older versions of the plugin for my 320x240 screenshot needs, no biggie.

What interests me the most is seeing a newer version of the plugin 'properly' show games with non-standard resolutions in a non-standard window. Goldeneye was a huge improvement on this latest version, but other games did not fare as well.
Although, that might be because of that "issue" I reported a while back, of some games with VI enabled natively encasing the visuals in a black frame, but with the VI disabled they are displayed full screen.
I hope someone takes some captures of a real Turok 2 (or any game from that list I made) to see if it's really encased in black frames.

[HatCat]

Originally Posted by ReyVGM

I understand your experiment, but I've had bad experiences with resizing images that way.

Not talking about a "way" to do it. There's more than one way to resize an image when you lose this much information; that was my point. GIMP just gives you a list of some of the options; if this plugin were to change the resize method it would merely be picking from another one of those, inevitably.

Originally Posted by ReyVGM

Maybe Mario 64 gives you perfect results, but other games might not.

Well if what you were saying is that you've "had bad experiences with resizing images" that were 440x330, processed to their native resolution up to 640x480, then resize them to 440x330, then yeah obviously, that would make sense. There's no regular resize that exists that would reverse what real hardware did to make it look like the hacked image you want.

The point is that's because any re-sizing at all gives bad results--which is why probably, you shouldn't do it. It looks better at 640 for some reasons.

Originally Posted by ReyVGM

I can still keep using older versions of the plugin for my 320x240 screenshot needs, no biggie.

Except for the games which incidentally had half the frame buffer size as the hardware native DAC size, in which case it divides evenly into a 2:1 ratio (640x480 is 200% of 320x240, which allows the possibility of hacking the image by means of a re-size.)

Originally Posted by ReyVGM

What interests me the most is seeing a newer version of the plugin 'properly' show games with non-standard resolutions in a non-standard window.

What might the definition of "nonstandard resolution" be? Just something that's not 320x240?

Originally Posted by ReyVGM

Goldeneye was a huge improvement on this latest version, but other games did not fare as well.

It's what I was hoping for. The last release was focused on filtering quality when scaling up or down the image. If it made the 440x330 hack of GoldenEye look better for you, then it was a coincidence, though I guess by itself it indicates nothing directly negative about my approach.

Originally Posted by ReyVGM

Although, that might be because of that "issue" I reported a while back, of some games with VI enabled natively encasing the visuals in a black frame, but with the VI disabled they are displayed full screen.
I hope someone takes some captures of a real Turok 2 (or any game from that list I made) to see if it's really encased in black frames.

Well I've seen already a couple native video captures taken from N64 hardware output itself which had the in-scaling towards the center leaving the frames around it, so until I see anything which contradicts that information I have no reason to believe that it isn't simply a natural configuration of the VI scaling registers, which more than permit the possibility.

[HatCat]

mylittle-nocomment3.7z had better picture for you because it was still written in DirectDraw back then.

The scaling method used Windows rectangles to do a DirectDraw scaled blit with a hacked (by that I mean wrong, as it was against MSDN documentation) screen width factor by one pixel, which corrected the blurring that half of the image was having on some GPUs (yours and mine) but would make it wrong on others. This again, was another case of GPU-defined behavior when using DirectX to blit the image.

mylittle-nocomment4, 5, and the EmuTalk releases you are able to download from my thread are all done in OpenGL in order so that I can have more low-level control over the raster stuff that dictates how the stuff is drawn to the screen on the client's side. So if I am to have any chance of using this information to look at how OpenGL can control the scaling towards what you wanted, I have to be able to compare between 4, 5, and the EmuTalk builds. Anything before mylittle-nocomment4 was still done in DirectDraw.

[GPDP]

So a few games like Rogue Squadron suffer from a weird issue on screens that would normally be interlaced:









The third image is actually in motion, so there's some combing artifacts, which are typically normal, but the others are still images, which should exhibit no such artifacts, and most other games with interlaced screens (Pokemon Stadium and Tony Hawk's Pro Skater 3 for example) indeed have no such issues, displaying perfectly on said screens.

For what it's worth, the RetroArch version of this plugin exhibits exactly the same issue.

[OldGnashburg]

I don't know much about programming, but why cant we just leave the resolution at what it's supposed to be 320x237, wasn't the hardware designed to omit those 3 lines of pixels so it could look better on a late-90's CRT?

[ExtremeDude2]

Not all games run at the same resolution.

[OldGnashburg]

Ah, that makes sense then.

[ReyVGM]

Originally Posted by HatCat

mylittle-nocomment3.7z had better picture for you because it was still written in DirectDraw back then.

The scaling method used Windows rectangles to do a DirectDraw scaled blit with a hacked (by that I mean wrong, as it was against MSDN documentation) screen width factor by one pixel, which corrected the blurring that half of the image was having on some GPUs (yours and mine) but would make it wrong on others. This again, was another case of GPU-defined behavior when using DirectX to blit the image.

mylittle-nocomment4, 5, and the EmuTalk releases you are able to download from my thread are all done in OpenGL in order so that I can have more low-level control over the raster stuff that dictates how the stuff is drawn to the screen on the client's side. So if I am to have any chance of using this information to look at how OpenGL can control the scaling towards what you wanted, I have to be able to compare between 4, 5, and the EmuTalk builds. Anything before mylittle-nocomment4 was still done in DirectDraw.

I see.

Thanks for everything you've done so far by the way

I hope it keeps improving and hopefully one day I'll be able to see a game in a window with its native non-standard resolution (as in, not 320 or 640), with filters enabled, and that it doesn't look garbled or like crap :P

Imagine if you take a native resolution screenshot with F3, then apply some filters to it. That's how I'm imagining games would look on the emulator if you apply the VI filters to a game in a non-standard res window.