If you have played NSMBDS for years, or just a couple of minutes in Mario vs. Luigi's Pipe stage, you have at least once got mad at this annoying "feature" that keeps stealing your momentum:


I don't know what to call it other than "edge grab", as this "feature" plays a cool animation of Mario or Luigi climbing over a tile edge, if you are lucky, which you kinda always are when precision jumping. Now, the animation is not that bad, but Mario/Luigi comes to a complete stop in the process!

If you have played SMB3 or New Super Mario Bros. Wii, you'll never get stopped by a tile during precision jumping. So let's get rid of this thing and enjoy NSMBDS, cause it almost feels like a precision platform game!

I can only remove this by using DeSmuME emulator's cheats (menu: Tools->Cheats->List):
Add a new cheat by pressing "internal" button, and input...

Address: 103754
Value: -509607936
Select size: 4 bytes.

Oh the AR code becomes: 02103754 E1A00000. Maybe you can put this code in Action Replay?

So this disabled the turing on of the bit flag 0x1000 which tells Mario/Luigi to animate and stop his velocity.

The code is located in the large virtual member subroutine 21031B4 for Player Collision:


In C++ this code would look like this:


I have not seen any other errors from removing this flag, and I hope there won't be any!

You should play through the whole game and feel how much better it plays. Sadly, it is still kinda messad up compared to SMB3 and NSMBWii, and there is no quick fixes. But this one is a huge step in the right direction

/Poweline

So desmume supports Lua script (basically for making TAS videos). I have used it before to output bounding boxes in a few games to understand how they are working internally.

As you all know, NSMB has some very well written collision detection systems (allowing enemies to walk on platforms is one example). While talking to Treeki about how NSMBW worked with collision, he showed me some very interesting output from Newer, that could answer alot of how NSMB dealt with collision.
So I did a Lua script and he kept adding all kinds of cool stuff.
Now we got output that you all can monitor, test, and learn from:






From this script you can learn that Paragoombas, when being wingless, have ceiling collision detection, where normal Goombas don't. That tells us that wingless Paragoombas are not just Goombas but special Goombas. There is more to be seen, so grab the script and have fun!

Install desmume 0.9.9 and then download lua51.dll and lua5.1.dll from the "LuaBinaries 5.1.4 - Release 2" package at http://luabinaries.sourceforge.net/download.html
Then run the script from the menu Tools->Lua Scripting->New Lua Script Window...

And here is the script:
http://www.logotypes.se/tmp/Mario/nsmbds_out.lua

Credits to Treeki for his extreme knowledge of NSMB


One note: NSMBDS runs the game 3 frames ahead of the actual output on the screen. This makes it very complicated to output the information at the same time as it is being displayed. I wrote a frame queued cache system that remembers each data for any number of frames in the past that you choose, or 3 that is default. Now, the more frames you add, the more space the script will take up, making it slower and heavier. There are other settings available that can be changed, like turning off certain output to make things clearer, or change the colors of collision info.

Let me see if I can answer some of your questions.

First off, when talking about classes and the class hierarchy, they are NOT really related to Mario, but really related to the programming language that Mario was coded in.
In this case, the engine NSMBDS was made in was coded in the C++ programming laguage, so we are talking about C++ classes here:
https://en.wikipedia.org/wiki/C%2B%2B_classes

"A class is a user defined type or data structure declared with keyword class..."

I keep telling myself that a C++ class can be Mario, or a barn, or the universe itself. What that means is, there is no enforcement what a C++ class must be or can do. The thing that makes an enemy an enemy is the way the programmer structured/designed the class, to do enemy behaviours. In order to make Mario really work in a smart way (and yes, some of the Mario code is really smart), a specific C++ class was designed to deal with all different game interactions needed by the game, and this class is the base class of the actors. All other actors derive from this base class, so that they can all share and talk to each other.

1. Actors in SM64DS, NSMBW, NSMB2 and NSMBU/NSLU are all coded as C++ classes, so that their AI and individual data storage can be managed in an Object-Oriented way. But in order for actors to interact with each other (Mario and a platform lift for example), they all share many similar attributes, inherited from a common base class.

2. Simply because classes are not restricted to actors. A class can be anything the programmer wants it to be. Sometimes there are classes inside other classes, like an actor having an animation class to deal with animations for the actor. But that animation class is no way related to an actor, as if you would create one where you usually create an actor, the game would crash.

3. I don't really know the terms here. To me, NSMBDS uses two types of actors, one global actor called "scene" can only be alive one at a time. The other actors can all be alive at the same time, doing different things from being an enemy, or a scroll stop, or some event.

4. It is all possible. If you create a dummy C++ class with the correct header of an actor, then create a spawn structure that holds its building function and priority numbers of execution and drawing, and add the structure location to the spawn list, that class can be spawned into the game, to do anything you ever wanted. But C++ classes are only helpful for programming when you have access to the same dev tools and the source code of the game, because it uses name mangling:
https://en.wikipedia.org/wiki/Name_mangling

Without the right tools and knowlegde, and alot of manual work, it would just be too much work. I don't even know how some of those "crazy" Newer Team people were able to get their custom programmed actors into the Wii game

HDMA is very useful for scanline 1 and up. Is was created for SNES where the top scanline (scanline 0) is not drawn or visible on the TV screen. Yoshi's Island for SNES uses HDMA for gradient backgrounds (changing backdrop palette RGB on each scanline), perspective texture LUT mapping for big enemies and bosses, and for the Mode 7 perspective rotating island title screen. On SNES that has a kinda slow CPU and addressing mode, having 8 channels of DMA, where each can be setup to use HDMA and the top scanline is never cared for, it is a very cool feature!

However, the GBA changed that into only having 4 DMA channels, and 2 of them are usually used for sound (and other stuff), the GBA draws the top scanline (scanline 0) so its offset needs to be set very quickly when V-Blank interrupt is hit. Games that fail the top scanline on the GBA include Metroid Fusion/Zero Mission, Super Mario Advance 2 - Super Mario World.

However, Super Mario Advance 3 - Yoshi's Island does not fail the top scanline. All the effects that use HDMA works very nicely, except the backdrop! Because YI uses so many tile animations and palette animation per frame, the CPU runs out of time for a frame during heavy calculations like when Yoshi transforms and during the GOAL sequence (Yoshi sends Baby Mario and eggs to the next Yoshi while Goal text is waving), and the gradient backdrop is not updated until a couple of scanlines down on the screen. SNES never seems to fail that (looking at captures from real hardware), even with its slow CPU.

Then we come to the Nintendo DS. Just like GBA, it has 4 DMA channels, and they work in the same way. Only all the data modified and read by the CPU (ARM9) is data/code cached, so it is very very easy to miss the first scanline (scanline 0) during V-Blank. It is also very easy to get fooled you succeeded to update the top scanline, when you actually failed (tricky to actually see the result). New Super Mario Bros. DS succeeds the top scanline (as can be seen in title screen and first level), so it is a pretty well programmed and tested game!

My guess is that HDMA cannot be used during NiFi and WiFi communications, either because of CPU or DMA being blocked, or DMA channels being used for communication? Just think about the multiplayer game where each connected DS is lock-stepping the game frames, the high priority stuff to be processed is game input like touch screen, and there might not be time left to update the top scanline before the screen starts drawing again. I don't really know, but I've tried to make HDMA work during multiplayer (MvsL mode) but the game hang. I know the GBA can't use HDMA during its multiplayer games because of CPU time.

Feel free to test HDMA in NSMBDS some more, and write more about it. I am always interested.

That is awesome! Gives me a pretty good idea how a platform works. I am a platform freak, and NSMBW is really interesting when it comes to platforms because of the 4 player support and bilinear filter rendering.

So from my work on the NSMBW, I had almost no luck finding anything because of debugging floating point values. I like fixed point better, because you can store and check integers at any value (whereas floating point values converted to integers or float constants for testing fails, as a whole number such as 40 might actually be 39.999999f, which truncated to an integer becomes 39 and not 40). And the very well written and awesome working camera stage wrapping system written in NSMBDS were no longer supported in NSMBW because of floating point.

Two classes in your code: are very interesting to me.
In NSMBDS a (rotating) platform is responsible for moving the player riding it, while the player is responsible for entering and exiting that platform. That system is very neat because it keeps the player from falling off a platform that moves at a high speed, even when standing at the very edge of it. The platform moves the player from its own origin, which is the cause of perfect sync relationship when being rendered to the screen, that only fails one frame during enter and exit of the platform.
Pushing stone blocks that push players sideways are not perfect sync, and makes players visibly appear inside a fast moving stone block (because player moves and collides with the wall, before the wall has moved).

You seem to have a good understanding of how sprites are rendered as well. That is quite interesting!

Motions between pixels are bilinear interpolated. That's why the texture containing stage tiles have a border of 4 or so pixels so that when a vertex is rendered between pixels on the screen, there won't be any visible gap. The bilinear interpolation makes the synced interactions between sprites look perfect when moving sub pixels. Something that NSMBDS suffer, resulting in anything riding a platform wobble back and fourth. Its a big deal to me. I rather would have NSMBDS use the math from Super Mario World where the Mario sprite moves the same amount of pixels as the platform he is standing on, no matter if the platform is moving slower than one pixel per frame.
The math is correct in NSMBDS and NSMBW, only they render sprites both hoping the 3D graphics will interpolate the resulting pixels. the Nintendo DS's 3D graphics is very bad anyway (such as clipping and flipping textures).


So StandOnTopCollider is typically the (rotating) platform I was talking about above. It has one value being the distance from the platform's left edge to the player, which is transformed using the angle of the platform to put the player there. In NSMBDS it uses (fixed point integer) square root to find the distance. Does it use square root in NDMBDS as well?

Physics is then the type of collision that NSMBDS doesn't have support for. I have zero knowledge of it. It is one very interesting collision detection because it can act as ground and walls and roof, and how the player can detect that, and account for multiple collision creaziness like walking onto one from tile ground, or getting crushed. So they are build of solid boxes and solid circles? So the big grass circle in 1-1 is also a round solid object?


Oh, and the wrapping support in NSMBW, I was thinking about stage wrapping similar to the multiplayer levels. They just hardcoded that wrapping mode to work for the tile screen in NSMBW (because they are all running to the right hand side keeping the scroll value from getting negative). The issue is that floating point requires modulo for wrapping (and extra stuff for wrapping negative values), and a f-modulo operation is an expensive divide.
For integer and floating point values, a simple AND operation (least expensive) will take care of wrapping, no matter if negative or not.

Yea, it is not a bug... But long before I knew that, and while searching for a fix, I thought it was a bug because no other major 2D Mario games had this annoying "feature", and it seemed random when it happened. Anyway, the topic name "Bug fix" stays because it is a fix of an annoying random thing (good description of a bug), and I want as many people to know about it. Any other topic description, like "Feature fix" wouldn't really get attention from people in the same way.

Having this clear, there are still other "issues" that could potentially be fixed, like Mario/Luigi auto-turning in the direction of a jump while landing (fixed in NSMBWii), and slope force values being opposite from NSMBWii, making Mario/Luigi walk slower downhill and faster uphill, when that clearly feels and looks wrong.