Mario 3 tried to be more than what the NES would let it.

Now don't get me wrong, I absolutely love Super Mario Bros. 3, and it's extremely advanced for the NES, but I can't help but feel like it was trying way too hard to do stuff the NES was simply not capable of doing. They tried to have not only horizontal scrolling like in the first Super Mario, but also have vertical scrolling, which led to them clipping the leftmost 8 pixel area as well as having the annoying incorrect attribute table on the rightmost 8 pixels. (I don't know if it's incorrect attribute tables, but what I'm talking about is the incorrectly colored area when scrolling.) They also tried way too hard to have a lot of palettes on screen, which leads to occasionally miscolored power ups or in the toad house, green fireballs. Of course, this could be just me.

They just didn't understand the NES that well back in 1987 during development.
Every technical problem the game has could be resolved if the game were redeveloped today. For instance, there's a >16 px black area at the bottom of the screen. Which means the entire playfield could be rendered on screen using Vertical Mirroring with no attribute clash.

You could use a 208px tall playfield, and 32px tall status bar, and four IRQ split points to make the 208px tall playfield wrap within a 192px area, show the status bar, and hide the bottom 16px.

There are many ways to implement clean 8-way scrolling on the NES, the developers of SMB3 probably just didn't think this was a priority. Look at Alfred Chicken, Jurassic Park or Gauntlet. Each of those games uses a different technique to implement glitch-free scrolling.


I guess I didn't play enough SMB3 to ever notice those problems, so I can't really comment on that.

I personally don't think SMB3 is "extremely advanced" for the hardware, I just think it's a well designed game.

SMB3 works perfectly for what the NES can do, and doesn't do (or fail at) things no other NES games do, except from purely gameplay design choices. Tons of NES games have scrolling on both axes, several that allow more than two screens high areas as well, and tons of NES games have the exact same glitches from it. And every single NES game had to deal creatively with the palette limits like that. Even the first SMB changes the color of powerups based on the area you are in.

The most unique thing SMB3 does is allowing destructable blocks all over large maps while allowing you to roam freely. That's absolutely only possible due to the 8kb wram on the cartridge. A lot of other games (especially from European developers) are much more creative with what they do.

If I had to chose an NES game that seems to go beyond anything you'd ever expect on the NES, it's Gimmick! And that game still manages to pull it off completely flawlessly.

I kinda feel like some developers resorted to using extra RAM a bit too soon. Sure it can speed up development time, and I can accept that as a valid reason to use it, but a lot of things that are attributed to extra WRAM could be implemented some other way if the developers had the time to think of more creative solutions.

On the topic of breakable blocks specifically, you could dedicate some RAM to the persistent state of objects and each block would only need 1 bit to represent its existence. If you have 256 bytes to spare for persistent object states, you could have 2048 breakable blocks. That's over 8 and a half screens full of blocks! I haven't played a lot of SMB3, but that sounds like enough even for levels that heavily rely on that gimmick. This is just a little more complicated to code, because you have to unpack the states as the camera moves and pack them back whenever blocks are broken, but I believe it's doable.

Compression as bitmasks is generally pretty convoluted on a 6502, unless there's some trick I don't know about.
A bigger problem though is that you need to identify which brick each bit represents, as they can be a LOT of different places between each of the many stages. I just can't see how to unpack it fast enough (without using a huge buffer anyway), but I'd love to hear some ideas. SMB3 already has a lot of other things to keep track of, and the stock 2K ram is pretty limited.

That said I absolutely agree that a lot of games that had the 8K extra didn't need it. I try to code my own projects around the idea that I don't, even if it would be a cheap cop-out some times.

Coincidentally, my Atari VCS game uses bit-based collision detection, for the player and enemies. It only uses 6 bytes of RAM.
It's not so much for saving RAM though, as much as it is saving a ton of ROM space, and overall frame time!

Indeed it's "just you". The attributes clash at the right edge of SMB3 is not representative of what the NES can do, they sometimes have as much as 3 pixels with wrong tiles and 10 pixels with wrong colours, when actually it can be optimized down to only 4 pixels of wrong colours (and 0 pixels with wrong tiles). Plese see this demo to see how they could have it done, if they implemented scrolling properly.

Well, the same can be said about many other things in game programming, don't you think? Like I said, the straightforward thing to do is indeed to use an extra 8KB of RAM and forget about it, or you could keep thinking and end up devising something more advanced.

One way to do it would be to pack breakable blocks into objects of 4x4 bricks (requiring 2 bytes of state), or whatever size is more convenient for your level design. Then, when decoding the active portion of the level map to RAM, "patch" that using the states of the blocks in the same area. Whenever a block breaks, locate its parent object based on its coordinates and update its persistent state. It's certainly not a no-brainer, but it's definitely not undoable either if you have the time and determination to design such a system.

The way these features are designed might affect the level layout a bit, so I'm not necessarily saying you can recreate SMB3 levels 1:1 without the extra RAM, but had the development team gone with another strategy from the beginning, they'd probably be able to create levels just as dynamic that would have had the same impact on players.


Once you realize the Atari 2600 only has 128 bytes of RAM and that somehow people were still able to make moderately complex games on it (I created a RAM layout to fit a screen-by-screen puzzle platformer in that machine and things were really tight!), 2KB starts looking pretty spacious!

You can use most of the stack page for other things. You can reuse the same RAM for different purposes in systems that don't run concurrently (i.e. don't make every variable/array global). You can even sacrifice some sprites and get 3.5 bytes of extra storage for each unused OAM slot (the Y coordinate must be > 239, so you can even use its lower nibble for other purposes). As a last resort, even VRAM can be used for storage of things that are not accessed all the time (if you use CHR-RAM, you can probably afford to lose a few tiles).

Again, the solutions aren't always straightforward​, but if you know beforehand most of the features you'll need to implement and you have the time to do it, you can usually create a memory map that'll be able to accommodate it all, unless you're going for something really unconventional that's not typical of 8 and 16-bit games. I personally think that finding creative ways to make game features fit in 2KB of RAM is a very fun exercise!

Like I said, it might not be possible to backport SMB3 to only 2KB of RAM now and get the exact same final product, but had this limitation always existed, the resulting game would probably feel equivalent in every way, if time wasn't such a big constraint.