Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1771  
Old 30th April 2015, 11:41 AM
fallaha56 fallaha56 is offline
Project Supporter
Member
 
Join Date: Apr 2006
Posts: 34
Default VI bugs as discussed

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
Attached Images
File Type: jpg NSME0000.jpg (19.6 KB, 10 views)
File Type: jpg NSME0006.jpg (19.4 KB, 8 views)
File Type: jpg NSME0006 crop.jpg (27.0 KB, 9 views)

Last edited by fallaha56; 30th April 2015 at 11:45 AM.
Reply With Quote
  #1772  
Old 30th April 2015, 02:37 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

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.
Reply With Quote
  #1773  
Old 30th April 2015, 02:53 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

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.

Last edited by HatCat; 30th April 2015 at 02:57 PM.
Reply With Quote
  #1774  
Old 30th April 2015, 03:31 PM
fallaha56 fallaha56 is offline
Project Supporter
Member
 
Join Date: Apr 2006
Posts: 34
Default VI bugs as discussed

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! :-)
Reply With Quote
  #1775  
Old 1st May 2015, 02:17 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

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!
Reply With Quote
  #1776  
Old 1st May 2015, 03:08 AM
theboy181's Avatar
theboy181 theboy181 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Aug 2014
Location: Prince Rupert,British Columbia Canada
Posts: 424
Default

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.
__________________
Book recommendation!
https://www.amazon.com/All-Cats-Have.../dp/1843104814
Reply With Quote
  #1777  
Old 1st May 2015, 07:37 PM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

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.
Reply With Quote
  #1778  
Old 3rd May 2015, 01:28 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by ReyVGM View Post
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.

Quote:
Originally Posted by ReyVGM View Post
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.

Quote:
Originally Posted by ReyVGM View Post
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.)

Quote:
Originally Posted by ReyVGM View Post
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?

Quote:
Originally Posted by ReyVGM View Post
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.

Quote:
Originally Posted by ReyVGM View Post
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.
Reply With Quote
  #1779  
Old 3rd May 2015, 01:32 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

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.
Reply With Quote
  #1780  
Old 6th May 2015, 06:14 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 147
Default

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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 11:52 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.