TL;DR: Aspect ratio formulas on Wikipedia seem to indicate the horizontally squished image is actually the correct presentation. I then challenge this conclusion and provide an alternative hypothesis.
According to the
Wikipedia article on pixel aspect ratio:
PAR = pixel aspect ratio
DAR = display aspect ratio
SAR = storage aspect ratio
PAR = DAR/SAR
If we plug in GameCube's numbers:
10/11 = DAR/(640/480)
DAR = 40/33
i.e if GameCube renders internally at 640x480 with a pixel aspect of 10:11, the display aspect ratio is 40/33, which is somewhat narrower in the horizontal direction than 4:3.
If true, GameCube does not intend to render a 4:3 raster, and any calculation which makes that assumption would be incorrect.
The problem is then how to properly convert GameCube's funky raster to:
1. An NTSC raster with SAR=704/480, DAR=4/3, PAR=10/11
2. An NTSC raster with SAR=720/480, DAR=4/3, PAR=8/9
3. A HDTV raster with SAR=1920/1080, DAR=16/9, PAR=1/1
Note: the above PAR's were calculated using PAR=DAR/SAR.
Solutions:
1. In this first scenario, both the GameCube and NTSC rasters use the same PAR (10/11). Therefore pixels can simply be copy pasted from the GameCube raster to the NTSC raster to avoid geometrically distorting GameCube's DAR of 40/33. 32 pixels of pillarboxing either side of GameCube's raster would be needed to center the image:
2. Since GameCube's DAR must be preserved in order to avoid geometric distortion, let DAR=40/33 (GameCube's DAR).
We are trying to display it on an NTSC raster with PAR=8/9.
Given we know the DAR and PAR, we can solve SAR:
SAR = DAR/PAR
SAR = (40/33)/(8/9)
SAR = 15/11
SAR =
654/480
i.e GameCube's internal raster should be scaled to 654x480 to account for the discrepancy between the PAR of GameCube's raster and the NTSC raster.
Sidenote: the width value of 654 is consistent with kingjinxy's observation
here.
As 654 is still less than NTSC raster's width of 720, pillarboxing with 33px either side would be needed:
3. Using the same formula as previously but with HDTV's PAR:
SAR = DAR/PAR
SAR = (40/33)/(1/1)
SAR = 40/33
SAR =
1308/1080
i.e GameCube's internal raster should be scaled to 1308x1080 and pillarboxed inside the 1920x1080 raster:
Assuming the previous formulas are all correct, what then is the DAR rendered on vWii with Nintendont set to width = auto or 640?
As I do not have a capture card to take a screenshot and count the pixels, I must take measurements of my TV screen with a ruler to determine the DAR of the raster.
I chose a game which is known to render internally at 640x480 (Skies of Arcadia Legends).
Source:
https://gc-forever.com/wiki/index.php?title=Swiss/Forced_Progressive_Compatibility_List
With WiiU outputting 1920x1080 and my TV's overscan disabled, I measured an active image area of 756mm x 624mm.
756/624 = 40/33 = GameCube's DAR, therefore GameCube's DAR appears to be preserved, despite objects like circles appearing horizontally squished as can be seen in the above image.
Alternative Hypothesis:
Given that it seems absurd to me that circles are intended to be such obviously distorted oval shapes, I propose an alternative hypothesis:
The PAR of GameCube's internal 640x480 rendering raster is not actually 10/11, but rather GameCube's NTSC video signal output raster has a PAR of 10/11.
This is consistent with the NTSC format of 704x480 having a 10/11 pixel aspect ratio according to the formula:
PAR = DAR/SAR
PAR = (4/3)/(704/480)
PAR = 10/11
Now let's propose that GameCube's internal rendering raster has SAR=640/480, PAR=1/1, DAR=4/3.
i.e 640x480 square pixels with an intended display aspect of 4:3.
Now let's calculate how it should be scaled to convert it to an NTSC raster with SAR=704/480, PAR=10/11, DAR=4/3.
SAR = DAR/PAR
SAR = (4/3)/(10/11)
SAR = 22/15
SAR =
704/480
i.e if GameCube renders internally in 640x480 square pixels with an intended display aspect of 4:3, all that is needed to convert it to the NTSC raster is to horizontally scale it up to 704, and this will not result in any change to the DAR (no geometric distortion).
If this seems counterintuitive, consider that in this scenario the intended DAR is 4:3 for both the GameCube's internal raster and the NTSC raster. Even though GameCube's PAR+SAR don't match the NTSC PAR+SAR, it doesn't matter, because the DAR is the same for both. Both rasters will end up being drawn onto a surface of the same dimensions by the TV.
To prove this point, suppose we render a square of 10x10px inside GameCube's internal raster. When the raster is scaled up horizontally to 704 to suit NTSC raster, it becomes 11x10px. But since NTSC has a horizontally narrower PAR, it will be horizontally squished back to a perfectly symmetrical square again.
My conclusion:
Whoever claimed that GameCube renders with a 10/11 PAR may have been referring to the PAR of the NTSC output raster, not GameCube's internal rendering raster.
I've never heard of anything rendering graphics in 640x480 non-square pixels, and it's simply not needed since the DAR of both rasters already match.
It also seems unlikely to me that GameCube's internal rendering raster was not intended for a DAR of 4:3, since the intended displays were 4:3 back in GameCube days. If the DAR is in fact 4:3, then GameCube's internal 640x480 must be square pixels (PAR=1) according to the formula PAR=DAR/SAR.
If my conclusion is true, the correct video width setting for games that render internally at 640x480, is the one which results in a 4:3 DAR measured with a ruler on your TV, with its overscan disabled. This should be either 704 or 720, depending on whether the console's NTSC output is 704x480 or 720x480.
Update: in the
Fixing vWii Mode thread, user Extrems has found that the GameCube's internal 640x480 raster for Skies of Arcadia is a viewing frustum with an aspect ratio of (4/3)/(11/10) which would mean its pixel aspect ratio is in fact 10:11, which is counter to my alternative hypothesis. Although it is still unknown why the 2D HUD elements appear horizontally squished. It is speculated the game developers may have negelected to convert the game's 2D assets from square pixels to 10:11 pixels.
Update 2: Extrems has
since reported that Wave Race: Blue Storm renders internally at 640x480 with an aspect of 4:3, which according to the formula SAR=DAR/PAR is square pixels, unlike Skies of Arcadia. This is consistent with the observation that in order to achieve symmetrical circles in the game's menu, Nintendont width must be set to the full 4:3 NTSC raster width (either 704 or 720, depending on which one your console happens to output — it seems 480i may be 704x480, and 480p may be 720x480).
New conclusion: different games render in different resolutions, aspects, and pixel aspects, and each game requires a specific Nintendont width setting in order to correctly map the game's internal raster to the NTSC output raster. The formula SAR=DAR/PAR can be used to determine the correct value for any given internal raster and output raster.
Proposed solution: create a public database containing the internal SAR, DAR and PAR for all games. This could be used to generate a loader config file to automatically set Nintendont width to the correct value, without requiring per-game intervention by the user.
Addendum
For Nintendont, a useful global default width value may be
680 when Wii is outputting 480p.
Then if the game looks too skinny, try 720, or if it looks too fat, try 654.
This should get you to the correct setting by eye in only one reboot, for most games.
In USB Loader GX per-game settings, those width values are 80, 120 and 54 respectively.
Following is my justification for this value:
Link to Google sheet
Final Thought
I suppose it may be advantageous for GameCube to render internally at the same pixel aspect ratio as its NTSC output raster, as it allows pixels to be mapped directly from GameCube to NTSC without needing to scale the entire raster, thereby avoiding aliasing/blurriness below the Nyquist rate, and saving GPU cycles to perform scaling.
The reduced horizontal/vertical size of GameCube's internal raster (eg. 640x480, 640x448, 660x448) could be useful for ensuring none of the game's pixels are cut off in the TV's overscan zone, and avoiding wastage of GPU cycles to render those unseen pixels.