Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1701  
Old 15th March 2015, 08:57 AM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

Quote:
Originally Posted by HatCat View Post
Actually renamed it from "GPU-accelerated scaling" to refer to the opposite of "Force NN" due to a debate over which was more accurate and whether I should default it to on/off.
Could you call it Nearest Neighbor instead of "NN"? That way people will know what it means. Nearest Neighbor seems to be what I would look for yep.


Quote:
If you use an eyedrop tool (or w/e it's called) in GIMP/Photoshop to check the exact RGB value of some pixels you may find that they have a very small deviation constantly changing each vertical interrupt.

If you are not finding this...it is because the interfering VI filters are not currently enabled within the ROM itself (n64 can choose which, if any, VI filters to enable). Only some of the VI filters yield pseudo-random results; the others are pixel-exact every time. Just depends the current part of the game you play.
Yep, I know the color value changes by a very small margin. But at least the filtering is consistent. In the case of Hybrid Heaven, it looked more filtered. But that was because I had the GPU thing enabled. So no worries.


Quote:
The only reason these filters even exist is because of television screens or CRT differences. I somewhat doubt that any of these VI filters would even exist, if all the Nintendo 64 ever did as a gaming system was output graphics to a modern flatscreen monitor. So it should be more than satisfactory to have this hack done only when VI filters are being bypassed, not when they are not.
The N64 had a very troubled development. I have absolutely no doubt that they already had the CPU finished before they decided to include all those filters the other consoles lacked at the time.
The only one that really knew what they wanted to do was Sony. Sega had a powerful 2D system with the Saturn and at the last moment they added a second CPU to be able to do 3D polygons. Which is funny because Sega was pioneering with 3D on the Arcades since 1993.
And Nintendo originally was going to do a powerful system that did those pre-rendered graphics like Donkey Kong Country and Killer Instinct. You can even see the "Ultra 64" logo (original name for the N64) on the KI machine, signaling that they were at least thinking about going that route. In the end I supposed they realized 3D was the future once they finished Star Fox and Miyamoto started working on Mario 64.

Quote:
I will look into it.

Thinking about it, you are probably right about it as long as VI filters are off. So I will see how much friction I get when trying to implement it.
I don't know why I'm even bothering you that much. In the end what interests me the most are the screenshots and you already said that the plugin will allow me to take native-res screenshots both filtered and unfiltered. So even if Goldeneye looks like crap while playing, at least I'll have the pretty native-res filtered screen.
I would like for games with non-standard resolutions to look good too, for everyone else sake. But for me, as long as the screenshots look "accurate", that's good enough for me.

I am going to assume that for the filtered screens using a non-standard resolution, the filtering will be "faked" right? Will it at least be a convincing fake, and not a GIMP/Photoshop blurring-like effect?

Last edited by ReyVGM; 15th March 2015 at 09:00 AM.
Reply With Quote
  #1702  
Old 15th March 2015, 05:14 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by ReyVGM View Post
Could you call it Nearest Neighbor instead of "NN"? That way people will know what it means.
a) "Nearest Neighbor" is itself open to interpretation and can mean too many different things.
b) Only people with filtering knowledge would understand that more than just saying "Force NN".
c) It's actually more like, "Force nearest-neighbor filtering (or upscale)" and not simply "Force nearest neighbor", but the purpose of the option names is to be concise so that they are not too long to refer to.
d) Config window size...the text name "Force NN" fits the window without me having reason to make config window bigger.
e) Documentation for the options is better than linking English text inside the plugin.

Quote:
Originally Posted by ReyVGM View Post
Yep, I know the color value changes by a very small margin. But at least the filtering is consistent. In the case of Hybrid Heaven, it looked more filtered. But that was because I had the GPU thing enabled. So no worries.
It looked more filtered because OpenGL has to filter the VI-filtered image so that it fits the 640x240 into your window size. Just that you prefer the pixilated filter over the alternative TV size filter that scales it up through GL_LINEAR.

Furthermore, "Force NN" will be off by default in the next release (as with any other checkboxes and 1's and 0's should all be off I think for simplicity :3), but the CFG file I ship with it will turn it on. Because a) most people will complain about the bilinear "blurring" if it is off even though it is a common final result for most TVs, b) there is a very particular edge case bug I've struggled to fix with the bilinear method in OpenGL state layout that I still have not yet resolved. So as long as the config file is installed correctly as well then actually "Force NN" will be on by default not off.

Quote:
Originally Posted by ReyVGM View Post
The N64 had a very troubled development. I have absolutely no doubt that they already had the CPU finished before they decided to include all those filters the other consoles lacked at the time.
The CPU was included by Nintendo but not designed by them.
They just used the one MIPS did. It's an MIPS R4300i, modified by NEC to become the VR4300.

So that was never the problem.

The problem is that your image will look wrong on one or more TVs if you do not adjust the image for certain old or new TV types. That's the only reason the VI exists to the extent that it does, with all the filters and the like. It means nothing if you are playing it on a laptop monitor screen...you have significantly less reason to use the VI filters since you do not have a CRT TV but a flat-screen LCD (I thought you yourself said you don't care about CRTs at some point or another...). So unless you simply like the CRT look, it makes no sense to nitpick about always having the filters since the frame buffer sent from the games, the RDP or the RAM is all that the game developers are thinking about from their own perspective. (The game developers will even write a 320x240 frame buffer, but complete VI emulation requires only reading 237 of said 240 rows of pixels, which gives you the black lines at the bottom, so you would disable VI filters if you really wanted to see the game from the developers' perspective, not a CRT TV's perspective...)

Quote:
Originally Posted by ReyVGM View Post
The only one that really knew what they wanted to do was Sony. Sega had a powerful 2D system with the Saturn and at the last moment they added a second CPU to be able to do 3D polygons. Which is funny because Sega was pioneering with 3D on the Arcades since 1993.
How were they doing 3D? Mostly just curious wasn't familiar with 3d before n64

Quote:
Originally Posted by ReyVGM View Post
I don't know why I'm even bothering you that much. In the end what interests me the most are the screenshots and you already said that the plugin will allow me to take native-res screenshots both filtered and unfiltered. So even if Goldeneye looks like crap while playing, at least I'll have the pretty native-res filtered screen.
It will have a 640x480 filtered screenshot and a 440x330 non-filtered screenshot.
That's the way it should be. I'm not following the last bit of what was said.

Applying filters to the source 440x330 image would be pointless because these filters were only invented as a solution to the fundamental pixel problem when resizing it to fit a CRT TV screen at 640x480. So the 440x330 image should be unfiltered, but I will see about fixing the artifact you have with the VI scaling when turning VI filters off that you mentioned because IMO that at least seems like a good idea.

Quote:
Originally Posted by ReyVGM View Post
I am going to assume that for the filtered screens using a non-standard resolution, the filtering will be "faked" right? Will it at least be a convincing fake, and not a GIMP/Photoshop blurring-like effect?
It will just be N64 filtering and only if you have filters enabled for the 640x480 final result.

If this is that confusing and misleading to you then maybe I should just prevent this confusion and make the "DP frame buffer" automatic window size illegal/unselectable when emulating VI filters. Because they're only really for the 640x480 result.

Last edited by HatCat; 15th March 2015 at 05:17 PM.
Reply With Quote
  #1703  
Old 15th March 2015, 05:30 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

ReyVGM , dsx did a real N64 video capture from GoldenEye 007 credits rolling at 640x480, thought you might be interested:
http://dsxcorner.com/emulation/credits.wmv

I forget where I last put your saved state so I could test that quickly in the emulator, but IIRC that looks the way it does in the plugin.
Reply With Quote
  #1704  
Old 16th March 2015, 05:15 AM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

Quote:
The CPU was included by Nintendo but not designed by them.
They just used the one MIPS did. It's an MIPS R4300i, modified by NEC to become the VR4300.
Yeah Nintendo doesn't really design their consoles. They partnered with Silicon Graphics for the N64 back then.


Quote:
The problem is that your image will look wrong on one or more TVs if you do not adjust the image for certain old or new TV types. That's the only reason the VI exists to the extent that it does, with all the filters and the like. It means nothing if you are playing it on a laptop monitor screen...you have significantly less reason to use the VI filters since you do not have a CRT TV but a flat-screen LCD (I thought you yourself said you don't care about CRTs at some point or another...). So unless you simply like the CRT look, it makes no sense to nitpick about always having the filters since the frame buffer sent from the games, the RDP or the RAM is all that the game developers are thinking about from their own perspective. (The game developers will even write a 320x240 frame buffer, but complete VI emulation requires only reading 237 of said 240 rows of pixels, which gives you the black lines at the bottom, so you would disable VI filters if you really wanted to see the game from the developers' perspective, not a CRT TV's perspective...)
Here's the way I look at it, and this doesn't apply on to the N64. I have the same perspective for every emulator.

I do not take into consideration whatever "look" a display panel gives to a game when talking about how a game "really" looks. If the CRT makes games blurrier, or creates a dithering effect, I am not interested in that.
I understand that devs were counting on the "blurriness" of CRTs to get away with fake shadow and transparency effects, but I'm only interested in what really comes out the output hole of the console. Obviously in older games the display panel (and cables used) influenced how the game ended up looking. S-Video cable will make older games look a lot sharper on a CRT than just using composite cables.

Another example, the Gameboy. It originally came with a green-tinted screen. And a lot of people that take GB screens apply that green-tint to the images. But I don't like doing that because the hardware and/or games themselves were not green. If you put the same GB game on a Gameboy Pocket, the games will look grey. If you put them on a Super Game Boy, they will look Black & White.
So their true "color", is black and white. That nostalgic tint was added by the different display panels the different GameBoy system had. Even Nintendo themselves published GB images with a yellow tint, not even green. And I assume they used yellow because Black & White could blend with the white background of instruction booklets and boxes.

So in my view, I want to eliminate the "extra effects" the display panels add to games and just get the "raw" images that supposedly come out the output hole. Of course, those "raw" images were not possible until emulators were invented and they showed you their native raw pixels and resolution.

So to me, a TV (or CRT in this case), is just a display that messes with how the games "really" look. If someone wants that "TV" look, then they can enable scanlines or filtering or whatever other effect to mimic the CRT (which isn't even consistent because the quality of the panel and type of cables affected what you saw).

BTW, no need to counter-reply this long explanation. I was just letting you know how I see it and I've felt very strongly about this every since I discovered emulators... almost 20 years ago (has it been that long? )



Quote:
How were they doing 3D? Mostly just curious wasn't familiar with 3d before n64
Oh Sega was pioneer in the Arcades with 3D. Virtua Fighter, Sega Rally, and several other games were the first 3D arcade games. At least 3D (polygons) in the modern way games are built (I know thetr had been some faux sort-of 3D games before).
They even did 3D before Nintendo, but Nintendo was the first one on consoles with Star Fox.
So it's pretty embarrassing that they were leading the way on the Arcades, and their next console (Saturn) wasn't even going to be able to play 3D games until the very last moment.

Quote:
It will have a 640x480 filtered screenshot and a 440x330 non-filtered screenshot.
That's the way it should be. I'm not following the last bit of what was said.
Wait... I though you were going to apply a filter to the native screenshot.
As in, the screenshot will have the non-standard resolution, but with filters.
Well, in my case, that doesn't really do what I'm looking for because I could just play the emulator in 640x480 and use the external image program. There was no need for you to go through all that trouble if that was the way you were going to do it.


Quote:
Applying filters to the source 440x330 image would be pointless because these filters were only invented as a solution to the fundamental pixel problem when resizing it to fit a CRT TV screen at 640x480.
I understand, but isn't it possible to apply the filters to the original native resolution since the emulator doesn't really need to scale the image to fit a CRT? Since the VI doesn't really scale, it is just "applied", then couldn't that be possible?
In other words, can't the framebuffer image pass through the VI without scaling the original image to 640x480?
Since you are already including options that the real N64 would let you do, wouldn't it be possible to do this one too? Can't a "force nearest neighbor" be possible just for screens too? I mean, is it truly impossible or could it be done but you would not be interested in doing it?

Quote:
If this is that confusing and misleading to you then maybe I should just prevent this confusion and make the "DP frame buffer" automatic window size illegal/unselectable when emulating VI filters. Because they're only really for the 640x480 result.
Nah, don't remove it on my account. It's a nice option to have. And most people don't really care about the VI filters. They will probably just play with filters off and take screens without the filters.

All I'm really looking for is a way to have the native resolution, but with the N64 filters look. 640x480 be damned.

I could just fake it with Photoshop, but that wouldn't give me the correct result since a game can have the polygons with filters applied, but not the text. Since, like you said, devs could have filters on or off if they wanted.

Quote:
Originally Posted by HatCat View Post
ReyVGM , dsx did a real N64 video capture from GoldenEye 007 credits rolling at 640x480, thought you might be interested:
http://dsxcorner.com/emulation/credits.wmv

I forget where I last put your saved state so I could test that quickly in the emulator, but IIRC that looks the way it does in the plugin.
Yes, that's how it looks on the current plugin when the screen is 320 or 640.

Last edited by ReyVGM; 16th March 2015 at 05:46 AM.
Reply With Quote
  #1705  
Old 16th March 2015, 03:34 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by ReyVGM View Post
So in my view, I want to eliminate the "extra effects" the display panels add to games and just get the "raw" images that supposedly come out the output hole. Of course, those "raw" images were not possible until emulators were invented and they showed you their native raw pixels and resolution.
Whether by "raw images that supposedly come out of the output hole", you're referring to the filtered or non-filtered screenshots, either way they are possible without emulators. The filtered screenshots were achievable in the same way that dsx recorded that GoldenEye credits video, and the non-filtered screenshots also do not require the invention of emulators. Anything that can copy and write pieces of N64 RDRAM during execution on the real hardware can take them, such as a GameShark Pro. Because of that, I also had help from ExtremeDude2 in getting real N64 screenshots without the VI filters applied to them, independent of relying on emulators.

Quote:
Originally Posted by ReyVGM View Post
Here's the way I look at it, and this doesn't apply on to the N64. I have the same perspective for every emulator.

I do not take into consideration whatever "look" a display panel gives to a game when talking about how a game "really" looks. If the CRT makes games blurrier, or creates a dithering effect, I am not interested in that.
Exactly, and the filtering from the VI adjusts the image under the assumption that the CRT will do one of those possible effects you mentioned. So if you are not at all interested in CRTs, why care about the CRT filters that much? Regardless of whether they're emitted from the N64 VI or the TV itself. Because, in fact, it's something of a combination of both.

Quote:
Originally Posted by ReyVGM View Post
BTW, no need to counter-reply this long explanation. I was just letting you know how I see it and I've felt very strongly about this every since I discovered emulators... almost 20 years ago (has it been that long? )
Prior experience with older systems which gave basic raster output for 2-D pixel art most likely does not weigh on an understanding that future systems such as N64 will do filter effects to adjust to a CRT via the VI to adjust to these televisions, as these games are 3-D and not 2-D.

Quote:
Originally Posted by ReyVGM View Post
Wait... I though you were going to apply a filter to the native screenshot.
As in, the screenshot will have the non-standard resolution, but with filters.
Well no, because earlier you said this:
Quote:
, but I'm only interested in what really comes out the output hole of the console.
What "comes out of the output hole of the console" is a 640-pixel-wide, semi-CRT-filtered image which anticipates the possibility of a CRT for future adjustments.

If I did what you said then it would not be 640-pixel-wide, it would be 320 or 440 or whatever pixels wide, which is no longer what "comes out of the output hole of the console". Unless you were just generalizing when you said that, and you were interested only in emulating some aspects of what comes out natively? For example, don't emulate the VI to produce the N64 640x240 or 640x480 resolution, but emulate only the filters and apply them to the wrong resolution. Because that's being inconsistent.

Quote:
Originally Posted by ReyVGM View Post
In other words, can't the framebuffer image pass through the VI without scaling the original image to 640x480?
No, it can never do that.
All the RCP registers guarantee it is scaled to 640x480 in the final result (well, 240p).

Quote:
Originally Posted by ReyVGM View Post
I understand, but isn't it possible to apply the filters to the original native resolution since the emulator doesn't really need to scale the image to fit a CRT? Since the VI doesn't really scale, it is just "applied",
Really? So all this time, my emulation of the VI's native 640x480 emission was really just an extra thing that emulators never needed to do, since all that does is scale it to fit a CRT? Yet when I emulate the VI's CRT-anticipating filters, then that's when you want the VI emulated?

So in other words, VI emulation is only hardware-correct if I emulate some of it but not all of it? The emulator doesn't really need to emulate the VI's real N64 output behavior insofar as the 640x480 resolution itself, only the filters that are meant for that resolution?

Quote:
Originally Posted by ReyVGM View Post
All I'm really looking for is a way to have the native resolution, but with the N64 filters look. 640x480 be damned.
Then you want not what comes out of the output hole but a personal modification of the sequence used to produce it.

Why would the real hardware bother scaling an image up to 640x480, if it did the VI filters **first**, before stretching it to fit a CRT? If it did the CRT filters on a 320x240 screenshot, THEN scaled it to 640x480 before sending what comes out of the output hole, then every pixel would be redundant/multiplied. Every 2x2 block of pixels would all be the same. This way, when real hardware scales to 640x480i first, then filters the pixels, each pixel is unique. In either case, both scaling it to 640x480 as well as the filters themselves are, together, a combination of real N64 behavior that is meant to anticipate CRT television transformations to the image, and are, while a part of RCP's output, not the native drawing that the RDP does to the frame buffer (which is all the game developers really understand most of the time).

Quote:
Originally Posted by ReyVGM View Post
I could just fake it with Photoshop, but that wouldn't give me the correct result since a game can have the polygons with filters applied, but not the text. Since, like you said, devs could have filters on or off if they wanted.
It's not that they can choose to apply the filters to only the polygons but not the text, but only at certain time points in the game. A developer cannot say, "apply or disable this VI filter for this REGION of the frame buffer (only the polygons) but not the text". If a filter is on or off, that logic is applied to the entire 640x480 raster image. So if both polygons and text are on the screen, whether or not a particular filter is enabled must invariably affect both.
Reply With Quote
  #1706  
Old 16th March 2015, 03:39 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Finally! After 3 days of hassle I have finally sorted out all the SDL issues I was having in Linux port of this plugin. Had to fix a number of windowing system issues, the auto-resize feature if people set the option to auto-resize the window to fit the native frame buffer resolution, full screen mode (<-- the biggest pain) and switching back to windowed mode.

So happy that I can finally play games in full screen mode on Linux. (I don't know of a keyboard shortcut in Mupen64 0.5 to exit full screen mode, though, so I made the SDL full screen implementation merely resize the window, then you right-click the X11 window and choose "full screen" to make the OS do it for me.)


That leaves only a few things left to do before releasing.
  • give RDRAM dump files more convenient file names
  • fix a regression with the top-most scan-line when blitting in interlaced 480i mode
  • restore old RDP TEXRECTFLIP command behavior for GoldenEye
  • try to do that thing ReyVGM said, where if VI filters are bypassed or disabled, do not scale the image up to 640x480 so that it doesn't look so crooked while playing GoldenEye in a 440x330 window
  • ??? might remember later ???
Reply With Quote
  #1707  
Old 16th March 2015, 05:38 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Keyboard shortcut should be (tm) Alt+Enter but not entirely sure
Reply With Quote
  #1708  
Old 16th March 2015, 05:56 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Yeah that's the way it works in win32 mupen64 (as well as any other emu I've ever known), but nothing I hit on the keyboard seems to take me out of full screen mode on mupen64 0.5. Have to press Alt+Enter or something to switch to the main mupen64 window and end emulation to get out of full screen. Which I guess isn't such a big deal as long as I can play stuff in full screen. :3
Reply With Quote
  #1709  
Old 16th March 2015, 06:23 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

I dug out an old m64p 1.5 32bit version I had lying around from the days were glide napalm was only available as a 32bit plugin and it works there, the mupen64 I have around is incompatible with my current libs and I didn't feel like rebuilding, so idk maybe it was really broken at that time, other buttons that may be used for fullscreen are F11 or F10 maybe it used one of these?
Reply With Quote
  #1710  
Old 16th March 2015, 07:17 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Looking at it more, Alt+F11 does seem to trigger the window mode between full screen and back within X itself, but it doesn't call the plugin spec function "ChangeWindow" within Mupen64, in the same way that clicking the "full screen" button through the Mupen64 0.5 GUI seems to. When I click the full screen button in mupen it does call ChangeWindow and alternate back and forth between my windowing code and my full screen management code, but I have not found a keyboard shortcut to invoke this in the Linux port of mupen.

So I'm glad I found out about the Alt+F11 shortcut, but that only works within the distro itself, not a part of Mupen64's design.
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 06:19 AM.


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