Nintendont

Just spent a few hours trying various games for the first time, including Mario Sunshine, Mario Golf, Paper Mario, Star Fox Adventures, and Skies of Arcadia.

I've got to say this is some impressive stuff. The video output is very clean in progressive mode, and true 16:9 viewport rendering if you desire. It doesn't really feel like I'm playing on an emulator either, which is great.

My only gripe is that it seems in order to achieve the original artistic intent of the games, we must set Nintendont's video width to 720, otherwise there is a pixel aspect mismatch where graphical elements that are supposed to be round, end up being elliptical in shape, eg. the golf ball HUD sprite in Mario Golf, or the moon in the opening sequence of Skies of Arcadia.

However the video width setting is unreliable — nonfunctional for Mario Sunshine and Star Fox Adventures. If anyone knows more about this, whether there are some special settings which can force the video width more reliably, or even patched in the .ISO, please advise.

 

First of all Nintendont is not an emulator. Almost everything is running natively in Wii mode as the Wii CPU is basically a faster GameCube CPU. There are a few things emulated like the memory card.

Changing the Width is known to cause issues with some games. Have you tried enabling Nintendont's built-in Widescreen option as it works with most games?

 

That setting does seem to work for all of my games, however it doesn't solve the issue, which I suspect may be related to a discrepancy between square pixels and non-square pixels. I suspect the game dev's artistic intent is that they knew the game's final raster will be eventually scaled to 720x480 to suit the non-square pixel aspect of the NTSC video signal format. However Nintendont is still outputting the games at 640x480 by default, unless we set width to 720, which unfortunately doesn't work for all games.

 

the width setting is a hack and doesnt work for every game, for instance it works for smash bros ntsc but not for smash bros pal and so on, sometimes it works on pal and not on ntsc, sometimes it works on both, sometimes it works on neither, it depends how the game is codded and if nintendont finds the hook.

that said like people said nintendont is not an emulator that is why you dont have save states and whatnot, also each tv is diferent, for isntance width for me only needs 684 to be full screen on my tv on certain games while other dont need a thing and so on.

 

As far as I know, the Auto setting for width simply allows the game to specify the video width, just like it does normally. I don't think that Nintendont itself should distort the games, so read here (https://gbatemp.net/threads/fixing-vwii-mode.573265/) for a little more info. Apparently, the Wii U distorts Wii output slightly, and since Nintendont runs in Wii Mode, it is affected. If you want to test for yourself, try the 240p Test Suite's "Linearity" screen.

 

I noticed the Nintendont pixel aspect problem goes away if I set WiiU's HDMI output to 480p. However this takes a really long time to dig through the menus to set 480p, and image quality is worse than letting WiiU upscale to 1080p. So frustrating!

In another thread I speculated that Homebrew Launcher may be somehow confusing the system into thinking it is in virtual console mode prior to launching Nintendont,and applying a different aspect, based on this:

I observe that Homebrew Launcher itself is squished horizontally into a slightly-narrower-than-4:3 ratio for unknown reasons, so maybe that has something to do with it. Is there some easy way to change its title ID to something other than L?

 

It seems this is due to the fact that 4:3 pillarbox inside a 720x480p HDMI signal results in something like only 540 lines of horizontal res in the active image area.

The workaround is to set Nintendont's 'WiiU Widescreen' to On, and then have the TV do the pillarboxing, however doing that reinstates the original problem (circles are slightly oval again)

Possibly relevant code:

https://github.com/FIX94/Nintendont/blob/master/kernel/main.c#L318

Code:

   // Set the Wii U widescreen setting.
   u32 ori_widesetting = 0;
   if (IsWiiU())
   {
       ori_widesetting = read32(0xd8006a0);
       if( ConfigGetConfig(NIN_CFG_WIIU_WIDE) )
           write32(0xd8006a0, 0x30000004);
       else
           write32(0xd8006a0, 0x30000002);
       mask32(0xd8006a8, 0, 2);
   }

https://github.com/FIX94/Nintendont/blob/master/loader/source/menu.c#L2016

Code:

void ReconfigVideo(GXRModeObj *vidmode)
{
   if(ncfg->VideoScale >= 40 && ncfg->VideoScale <= 120)
       vidmode->viWidth = ncfg->VideoScale + 600;
   else
       vidmode->viWidth = 640;
   vidmode->viXOrigin = (720 - vidmode->viWidth) / 2;
   ...
   VIDEO_Configure(vidmode);
}

 

[deleted - contains incomplete/superseded information]

 

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.

 

Nintendont updated to 492
rename to boot.dol and replace on sd card/usb
https://github.com/FIX94/Nintendont/blob/master/loader/loader.dol?raw=true

Added need for speed carbon and most wanted to force connected exception so they wont randomly disconnect
Did alot of merges including
Fix for smash ultimate gc controller Dr-Crow
Remove iso cache and tweaked sonic ridders patch (SuperrSonic) helps fire emblem issues and games where music went silent after awhile.
Lots of controller.inis
and some more that seemed ok.

 

Glad to see that this wonderful piece of software is still receiving bugfixes in 2021.

A question about all these new controller ini files: are they supposed to be inside controllers.zip, right? As of now, they are scattered.

 

How can I "kill" right stick, and how does the "A" button default without pressing the "select" button every time I start the game

 

i don't understand what you want at all, i see you have a Brazilian flag s send me a private message with your issue in Portuguese if you want.

 

Is there any way to disable the WiiU pad but not require a Wii Remote when using VC injects? I saw this fork which is kind of what I want to do: (cant link but its at github /NazarSurm/Nintendont---No-gamepad-on-Player-1

I am wondering if there is any way I can set it up, ideally it would work like this:
1. Pick a GCN game from title screen
2. Select VPAD (preferrably I would be able to get rid of this dialog entirely to ALWAYS select the VPAD option)
3. Nintendont boots but does not assign vpad to player 1, instead prompts if I want to use the Pad or a Controller. Or maybe it waits for any button press and assigns Player1 to that

this way if I want to play just using the VPAD, can still do that, or if I want to use my own controller, I can.
Any way to do something like this right now or would it need code changes to Nintendont?

 

what you want is not coded in nintendont... it would require recoding the vwii injection by nintendo, sure you can make gamepad be player 2 or whatever but you would always need to use either the gamepad or wiimote to start an inject since that is how nintendo coded the virtual console injection.

from everything you want the only thing that nintendont itself could change is not make gamepad locked to player 1 but the rest its out of nintendont reach since those are steps from wiiu menu in wiiu mode and nintendo codding, nintendont only starts after the wii enters in wii mode, before that nintendont has no control and no codding for wiiu side.

also what he did in the fork was removing gamepad codding altogether from nintendont therefore gamepad doesnt register anything because it isnt codded to work at all...

 

Yeah I dont think the first thing is possible (where WiiU asks to use Gamepad or not). I think with hid2vpad it would be possible to get past that menu with no vpad.
The second I think it would be helpful to have an option to totally disable the WiiU pad as P1, maybe in the config. I plan on trying to compile Nintendont later and see if I can find a way to get it to do what I want. Goal is to be able to use a controller with WiiU GCN/VC injects without having to use a Wiimote at all

 

launching homebrew launcher and then hid2vpad to launch nintendont just seems way more trouble and time consuming imo.

 

on the github page under Notes it reads:

"Nintendont runs best with storage devices formatted with 32 KB clusters. (Use either FAT32 or exFAT.)"

Should I choose 32768 in the FAT32 Formatter ? like below:

 

Co

Correct. FAT32 32768 bytes=32KB.

 

Hey! I decided that I wanted to play some old GC games, so I dusted off my Wii U yesterday. I'm having some problems with Nintendont though. Specifically, the actual menu/settings.

I've downloaded the latest version and put it on the SD card according to the instructions. I installed some kind of forwarder years ago when I tas tinkering with this, so I have a channel that I use to launch Nintendont. TBH, I don't remember the method I used for that, but it seems to still work.

The problem is that when launching Nintendont, 9 times out of 10, I get corrupted/distorted text/graphics in the menu. See attached photo. I can run games from the SD card just fine if I just press A a few times, so everything is working except the menu. I do the same simple steps every time:

1. Run Haxchi from Wii U home menu, let it reboot into system menu
2. Run Nintendont "channel"

I've searched quite a bit for this issue, and haven't found many people who have had the same problem, most people just have "black screen" issues, which is not the case here.

Ideas?