Dolphin, the GameCube and Wii emulator - Forums

Full Version: Correct aspect ratio option?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
You actually have it kind of backwards I think. The TV will do what it does regardless of the signal (so long as it's an NTSC signal). The signal is produced to the standard so that the TV can handle it.

The NTSC GC/Wii uses 525 lines. That is the NTSC standard, that is what all NTSC devices use. NTSC spec display devices have an active display area of 486 lines. They will display 486 of the 525 lines in an NTSC signal. The GC/Wii renders @480 lines (sometimes less). This means that there are some active lines that contain no image data, but are part of the active frame. A proper NTSC TV will display 486 lines, of which 480 (or less) will actually contain video data. Whether or not there is actual video data there is irrelevant in terms of determining the SAR of the display. So 486 is the number of horizontal lines in the 4:3 display.

Devices can handle 720 samples, but the standard is that the active line duration is 52.6555 µs, which, when multiplied by the sample rate of 13.5 MHz, gives you an active display width of 710.85 samples. The 13.5MHz number can be obtained by multiplying 30*1000/1001 (the NTSC frame rate) by 525 (the number of lines per frame) by 858 (the width of a complete line in samples). This means that a perfect 4:3 NTSC spec TV will display 710.85 samples per line. If a 4:3 TV is perfectly matched to the NTSC spec, it will display 710.85 samples on 486 lines and cover a 4:3 total area. It doesn't matter if the GC/Wii actually renders only 640x480 or 448 or whatever number of lines, 486 lines will be displayed with 710.85 samples per line according to the specification. This means that each sample has a SAR of 4320/4739. Sorry if my explanation is convoluted and hard to follow, there's just so much going on that has to be accounted for. If something doesn't make sense, please point it out so that it can be clarified/corrected, but I am fairly sure that my thought process is sound.
It doesn't make sense because you're working at the wrong end of the signal. The quoted standards, the doom9 capture guide etc. are all based around analogue video. As in old broadcast and VHS type stuff. What we have is a digital picture of 720x480/576 that is expected to be rendered with a SAR of 4:3. Applying a SAR determined by using formulas based around analogue formats is wrong because those formulas would not have been used to create the source material (unless you were capturing it from an actual console using a capture card).
The GC/Wii outputs analog video. It uses the NTSC standard, which is analog. I understand that dolphin renders digitally. But it is emulating a system that is designed to be converted to analog and displayed by analog devices. So in order for in game geometry to look right we have to emulate the way that a real NTSC analog TV would display that image. That is what is at the heart of the issue being addressed by this thread.
mirrorbender Wrote:The GC/Wii outputs analog video. It uses the NTSC standard, which is analog. I understand that dolphin renders digitally. But it is emulating a system that is designed to be converted to analog and displayed by analog devices. So in order for in game geometry to look right we have to emulate the way that a real NTSC analog TV would display that image. That is what is at the heart of the issue being addressed by this thread.

That's not really correct. The GameCube and Wii are both progressive consoles - they render in progressive and then convert that into interlaced format in the xfb if an interlaced output is used. That's why Dolphin doesn't have the interlacing problems in game that some other console emulators have. And the GameCube and Wii are capable of either NTSC or PAL (despite the dumb region lock). For the GC and Wii interlacing is an option, so there is nothing tying the consoles to analog displays, and thus there is nothing here that Dolphin can't emulate on modern digital displays.

Analog transmission, just like digital transmission, relies on common standards - video should be encoded in X and displays are designed to display X. All Dolphin has to do is understand what X is and what it's doing, and that's emulation. If the GameCube and Wii were going outside of those standards it most likely would not even work! The fact that these are subtly and randomly wrong implies that the games are telling the consoles to do before it is encoded for transmission that Dolphin isn't picking up on.

Boiling it down to "how an NTSC analog TV would display the game" is an extreme oversimplification that ignores how the hardware works and all of the OTHER display methods.
(07-08-2015, 04:33 PM)mirrorbender Wrote: [ -> ]The GC/Wii outputs analog video.  It uses the NTSC standard, which is analog.  I understand that dolphin renders digitally.  But it is emulating a system that is designed to be converted to analog and displayed by analog devices.  So in order for in game geometry to look right we have to emulate the way that a real NTSC analog TV would display that image.  That is what is at the heart of the issue being addressed by this thread.

Dolphin does not emulate the analog conversion, and there is no need to because it would just need to be undone again for display and result in inferior picture quality. That is why the analog formulas should not be used to calculate the SAR to be applied to the digital output.

Quote:That's not really correct. The GameCube and Wii are both progressive consoles - they render in progressive and then convert that into interlaced format in the xfb if an analog output is used. That's why Dolphin doesn't have the interlacing problems in game that some other console emulators have.
Eh, that's not always correct either. Data can be copied from the EFB (which is always progressive, but may have a vertical offset applied to account for the field (top or bottom) that will be used for display) to the XFB as either both fields (progressive) or a single field (interlaced). Nearly all games use lazy coding and copy both fields to the XFB even when only one will be displayed, so in 99% of cases the XFB also contains progressive frames (even though it's a waste of memory that games could have used for other things).

Quote:If the GameCube and Wii were going outside of those standards it most likely would not even work!
That's actually why Nintendo had to include a hidden option to disable the double-strike mode used by Wii VC titles, they're non-standard and don't work on newer TVs...
Right, I'm talking purely in terms of aspect ratio here. You don't need to account for interlacing or anything like that.

Still, the game is rendered digitally, possibly scaled, and then placed within the NTSC/PAL picture frame, and then displayed on an NTSC/PAL TV. That is the intended use. I'm ignoring internal scaling for now. So game renders @ 640x480. This is then placed in the NTSC frame, which is 858 samples wide and 525 lines tall. 710.85x486 of that is what is actually displayed. That 710.85x486 area is 4:3. The fact that the game only takes up 640x480 of that area doesn't change the pixel/sample aspect ratio, if that makes sense to you. I'm going to try to make a visual demonstration to try to make it clearer what I'm trying to accomplish here, because we're clearly not all quite on the same page here.
By the time it ends up in that format it will no longer be 640x480.
Can you explain why not?

*Edit* Just to clarify, I understand why it wouldn't be 640x480 in interlaced mode. I am talking about progressive mode. In interlaced mode, each field would have 243 active lines (240 with picture information), and then the even fields would be interlaced with the odd fields to create the same effective image height of 486(480 image lines). So the same math would work.

Also, here is that visual guide to go with my math:

http://imgur.com/a/bWV33
It seems like we need some kind of specialist. An issue clearly exists but it seems not everyone agrees how to fix it.
Does an issue clearly exist? Since not even TVs seems to be able of producing consistent results, should we really be trying to make Dolphin display things the way they "should" be displayed? Or maybe I'm missing something.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17