Talk:New Super Mario Bros. Wii

Unused Yoshi Interactions?

I am going to make a page documenting how yoshi interacts with sprites from areas which yoshi is not in. Should I put "unused Yoshi interactions" as a new sub-page or new section in the main page, or should I make a new section in one of the subpages? Or what? --Hiccup 10:27, 11 December 2012 (EST)

NSMBW Vid

Look at this vid that I found! http://www.youtube.com/watch?v=3oqGSTaFnYE--Holyromanemperortatan 16:17, 3 December 2010 (EST)

Indepth analysis

Here's a very very indepth analysis of the 1-Coin Battle early 7-Tower layout. Not sure if this kind of thing fits on the wiki, though. Should I put it in the article, or maybe create a "notes" page?

The zone height was originally 1568 blocks, the final one is 1648.
Multiplayer scroll player tracking setting is "1" in the early file (track bottom player), and "6" in the final (track highest player).
Zone Lightning was changed to a more lit version in the final level.
Bounds for the final level were changed; the early file puts "64" in the upper bounds and "16" as lower bounds, while the final level only uses "80" as upper bounds.
Sound modulation was changed to "Underwater Echo" from "None".
The final level uses background IDs 5102, instead of IDs 0202. All three background slots are used in the final, while the original only uses one. Usage of three slots fixed the dissappearing background.
Multiplayer Coin Battle Coins were added.
A Super Guide block was added.
The tilt controlled grinder sprite was repositioned; it's a bit lower than in the early file.
A set of platforms was added above the midway point.
A lot of the brown moving platforms was increased in size.
The secret exit fake wall is now three tiles high instead of early 2.
The secret exit controller's settings were changed. What's strange is that not only the height value was increased by 1, but also the width value. In addition, the "type" setting was changed.
A new platform and a few more cannons were added above the secret exit.
The star coin was blocked by a coin brick wall, and it's platform was redesigned.
An invisible fire flower and coin block were added at the top.
The final boss door platform's layer was fixed.
--Skawo 09:03, 1 August 2011

"Donut Block" in credits tile-set?

The "unrecognizable" yellow block documented in New_Super_Mario_Bros._Wii#Credits_Tileset appears similar to the Donut Block from other Super Mario games. Is it possible the two are related? --SuperRed38 (talk) 15:03, 13 January 2018 (EST)

What yellow block are you talking about? --Hiccup (talk) 15:19, 13 January 2018 (EST)

Six to the right. The yellow block with a hole. --SuperRed38 (talk) 17:49, 14 January 2018 (EST)

Oddity suggestion

Just a suggestion for the Oddities section: if the Super Guide (Luigi) loses a life on a level, the game will think the level has been beaten. If this could happen on the level 8-Bowser, when the Super Guide loses a life, the game will automatically switch to the ending sequence, even if the level is not fully passed. Of course, this is not possible to do without modding. --B squo (talk) 17:35, 27 May 2020 (UTC)

I think to determine if this is actually an "oddity" or not you'd need to look at what the code is actually doing. It may just be checking to see if the level is "ended" in any way, rather than this being some kind of purposely-programmed safeguard. --Hiccup (talk) 12:51, 28 May 2020 (UTC)

Anti-piracy change

User:Meatball132 changed the description of the anti-piracy functionality to "If it fails, the game waits a random amount of time between 3 and 10 minutes, then halts and presents an error message." I'm unable to confirm this, though.

The way I tested was by modifying Dolphin's code for DVDLowReadDiskBca to be either

 case DICommand::ReadBCA:
 {
   SetDriveError(DriveError::InvalidCommand);
   interrupt_type = DIInterruptType::DEINT;
   break;
 }

or

 case DICommand::ReadBCA:
 {
   SetDriveError(DriveError::ReadError);
   interrupt_type = DIInterruptType::DEINT;
   break;
 }

but neither of those produced the described result. (DriveError::InvalidCommand gives an error message immediately and DriveError::ReadError returns to the Wii Menu... which is the description I had before.) I also don't remember seeing anything that looked like that when I was reverse-engineering the game (and the invisible notes that I had left in the page prior to this edit also seem to cover these fairly exhaustively).

I haven't actually experimented with non-Wii discs on my console so perhaps there's a different error I don't know about or Nintendo hid some more obfuscated code in there somewhere. Or maybe things behave differently on different revisions of the game (I only have the US revision 2). I'm pretty sure User:Meatball132 worked on Newer Super Mario Bros. Wii, and thus has a lot more experience with NSMBW's codebase... so any ideas as to why I'm not able to reproduce this? --Pokechu22 (talk) 01:59, 1 November 2023 (UTC)

Hi, I can confirm that the change is correct. The code for this is in DVDCheckDiskBca(), just after the __DVDStoreErrorCode(0x123456a, cbCallback); call. It's this part, specifically:

OSCreateAlarm(&alarm_80395ea0);

uint delay = 180 + (OSGetTick() & 7) * 60;

OSSetAlarm(
    &alarm_80395ea0,
    (OSBusClockSpeed >> 2) * delay,
    callback_801d1060);

OSGetTick() returns a time value measured in very small units (roughly tens of nanoseconds), so the bottom 3 bits of it are essentially a random number. So this code picks an effectively random number between 0 and 7, and rescales it to be between 180 and 1800. Then it sets an alarm for that duration, at which point the callback is called, displaying the error message.

Your tests didn't work because all of this only happens if the BCA read is successful and the data doesn't match, not if the BCA read itself is unsuccessful. You could test it in Dolphin by modifying DVDInterface::ExecuteCommand() to return different data, but a much easier way is to use Dolphin's built-in debug tools to set a breakpoint at 801d0ef8 (that's PAL — 801d0db8 for your US version) and change either r0 or r5 there to make the comparison fail. This check happens very early during startup, so you'll need to use Dolphin's "Boot to Pause" option (in the Options menu) to get a chance to set the breakpoint before the code executes. Then just play the game or wait for 3-10 minutes, and you'll see the error screen.

RoadrunnerWMC (talk) 06:36, 7 February 2024 (UTC)

Thanks! That makes sense, and I'm guessing I didn't notice because I was using symbols from Dolphin's signature database which doesn't know about OSSetAlarm (but does apparently know about OSSetPeriodicAlarm right after it; the signature database is fairly flakey). That plus the weird pirate patches I saw made me assume that the BCA read was unsuccessful. I was able to confirm that waiting does indeed result in halting with the error message.

Re "Lara Croft Tomb Raider: Anniversary", I'm pretty sure someone just messed up when inputting the data onto redump given that the pattern of 0000, 0010, 0020, 0030 matches the disc offsets and the text "KGSC" starts at offset 0x36 instead of 0x34; it looks like they removed the last two columns of data and put the offsets into the first two columns. They have a second BCA listed that seems to not have this issue. I'll bring this up on the redump forum.

I like your new writeup, though I noticed you removed File:New Super Mario Bros. Wii BCA.png and File:New Super Mario Bros. Wii and Wii Sports BCA comparison.apng. I feel like these images are helpful for showing how subtle a difference it is (though I'm also a bit biased since I originally created them). Do you have any thoughts on this? --Pokechu22 (talk) 18:41, 7 February 2024 (UTC)

Hey, Roadrunner and I worked on this edited version together and we talked at length about the microscope images. We did feel kinda bad removing those, because we were sure a lot of work must've been put into them, but we decided that it was unnecessary for a number of reasons.

One, it was presented as "you can see the difference through a microscope!" which is cool and all, but that seems more like a fun fact being forced in there than helpful supplemental information. It's only tangentially related to the point that was being made: that the BCA data had a 1 instead of a 0 at the end of the block of data checked by the game. We made sure that was explained very clearly in the text when rewriting it, so I don't think by removing the images we lost any clarity.

Plus, "how subtle a difference it is" isn't really relevant to the explanation. We're trying to explain how the anti-piracy works, not illustrate the stealthiness of the change they made. They could've completely changed the data there to random noise and we wouldn't be going "look at how unsubtle the shmucks at Nintendo made the BCA difference lol", because how different it is doesn't matter. Maybe Nintendo thought keeping it subtle would make it harder to find, but that's pure speculation and I think that's too much to try to shove into the article.

Lastly (and most importantly), I think it actually made things more convoluted. Saying "hey this byte is 1 instead of 0" then going "and now you have to try to analyse that under a microscope" was a bit overwhelming, even for me. So when trying to imagine how a more casual reader would feel, we decided it was easier to understand without the images.

I do apologise, because again, it seemed like you put a lot of work into this and we do hope we didn't offend you or make you feel like we undid your work or anything. But I'm afraid after our extensive consideration we felt like the images had to go :( sorry. Meatball132 (talk) 20:09, 7 February 2024 (UTC)

Alright, all of those are good points. The images along with a few others are still available at https://commons.wikimedia.org/wiki/Category:Burst_cutting_area for future reference (I think TCRF deletes images that aren't used in articles after a while). --Pokechu22 (talk) 07:05, 8 February 2024 (UTC)