nesdev.org

Why does Super Mario Bros 3 have background scrolling artifacts on the right side of the screen* when Super Mario Bros 1 and 2 don't?






*I remember finding an explanation for the artifacts, but I can't remember where it was.

Smb3 uses horizontal mirroring (vertical arrangement of nametables) so it can update the entire vertical area as it scrolls.

The NES can only have an offscreen buffer to update tiles/attribute bytes(These control the palette the background tiles use) on one axis. (The programmer chooses which axis)

Super Mario Bros. only scrolls on one axis, so it can update the attributes before they're on screen. Super Mario Bros. 2 only scrolls on one axis at a time (if I recall correctly), so it can always update the attributes before they're on screen. Same with Metroid.

But Super Mario Bros. 3 is capable of scrolling on both axises in the same frame. It is set up to have its offscreen buffer for vertical scrolling, but not horizontal scrolling. That is why the player can see the palette changing by the right edge of the screen.

Like the others said, it's because of the type of scrolling it uses. Since the NES only gives you 2 screens (name tables) to work with, you can organize them either vertically or horizontally (by selecting horizontal or vertical mirroring), so you only get a hidden area where you can perform screen updates seamlessly in one axis.

For games that only scroll in one direction this is not a problem, but once you scroll in both you have to pick a place for the scrolling artifacts. There are ways to get rid of those artifacts, of course, but the programmers of SMB3 probably didn't think that was important.

For games that only scroll in one direction this is not a problem, but once you scroll in both you have to pick a place for the scrolling artifacts. There are ways to get rid of those artifacts, of course, but the programmers of SMB3 probably didn't think that was important.

There is no way to COMPLETELY get rid of them, but there is a way to come pretty close. However Nintendo really went pretty lame with SMB3 because there is up to 10+ garbage pixels on the right, while it's possible to have only at max 3 on the left and 4 on the right (never simultaneously) which is much less noticeable such as seen here.

I show hot it *could* have looked if Nintendo's programmers were better in this totally shitty unfinished scrolling demo here.

Also SMB3's border looks bad because of the light blue (or wathever other) color bands vertically, especially on NTSC where the horizontally "underscan" area is filled with the BG color.

Bregalad wrote: I show hot it *could* have looked if Nintendo's programmers were better in this totally shitty unfinished scrolling demo here.

But it only scrolls horizontally? The reason there's artifacts if because the way they stacked the screen. This isn't stacked and doesn't scroll up. Although I have a feeling that's why it's unfinished....cool demo though.

Bregalad wrote:There is no way to COMPLETELY get rid of them

Isn't the additional nametable RAM to have four nametables is the way?

Shiru wrote:

Bregalad wrote:There is no way to COMPLETELY get rid of them

Isn't the additional nametable RAM to have four nametables is the way?

And the A/B/B/A diagonal mirroring would get off of lots of NTSC systems, although they'd exist on pal. But only on the corners.

Bregalad wrote:There is no way to COMPLETELY get rid of them

Of course there is, four-screen mirroring being the most obvious way. But even if you're stuck with only 2 name tables, there are a few techniques to completely blank the otherwise glitched areas. Since it uses an MMC3, SMB3 could very well have used interrupts to hide the top and bottom 8 scanlines, and vertical mirroring instead of horizontal (exactly like Jurassic Park does).

You guys are right there is a lot of ways to completely get rid of them but they aren't "convenient".

1) 4-screen VRAM (really a waste if hiding the artifacts is the ONLY think that made you use additional VRAM)
2) Using a vertical bar of solid black sprites (then you're stuck with only 7 sprites per line for gameplay...)
3) Using raster split to use a completely blank CHR-bank (needs timed code or IRQs + a blank CHR-blank)
etc...

Also Jurassic Park does not have a status bar so that method wouldn't work for SMB3. It would have to use the complex method used in Krusty's Fun House.

But it only scrolls horizontally? The reason there's artifacts if because the way they stacked the screen. This isn't stacked and doesn't scroll up. Although I have a feeling that's why it's unfinished....

You bet it. I was going to du a multi-directional scroll demo with a single screen of VRAM used. Not sure if I'll finish it someday but multi-directional scroll is really evil to get working.

I actually always thought it was somewhat lazy of SMB3 to have tile glitches. You can see actual tiles that are not updated at the right for a pixel or two, but there's no reason for that when you're hiding the left eight pixels. That stuff can be completely hidden.

Bregalad wrote: Not sure if I'll finish it someday but multi-directional scroll is really evil to get working.

I'm more curious to know how the attribute glitches seem to only show a max of 3ish wrong colored pixels instead of a max of 8 at the right.

I've got multidirection scrolling working, and have had it working forever, but I still have a max of 8 pixels at the trailing edge of the screen.

Edit: OOooh. Clever little trick. I just read more into your posts. So it shows wrong colors attributes on BOTH sides, so there are less of them. I may think about doing that, but I think I prefer to just keep it all at the trailing edge of the screen Kirby style.

Then again... the demo shows that it seems pretty rare that BOTH sides of the screen will have glitches at the same time. And considering I didn't even notice it was doing stuff on the left until I really checked... hmmm...

Kasumi wrote:I actually always thought it was somewhat lazy of SMB3 to have tile glitches. You can see actual tiles that are not updated at the right for a pixel or two, but there's no reason for that when you're hiding the left eight pixels. That stuff can be completely hidden.

easy to say that 25 years later they were probably happy with 4 way scrolling at that time

and it certainly doesnt seem to have hurt game sales much

This scrolling artifact, along with other artifacts such as the shadows behind blocks, lead me to believe that SMB3 for NES was an amateur retelling of SMB3 for Super NES. See explanation at TV Tropes.

But in a way, keeping attribute artifacts at the right side might be the best policy because the right side is more likely to be within overscan.

tepples wrote:the right side is more likely to be within overscan.

Really? My TVs all gave me the exact opposite impression.

I believe that with the knowledge and tools we have today we have little excuse to program free scrolling engines with visual glitches, so I do everything I can to avoid those on the software level.

EDIT:

tepples wrote:See explanation at TV Tropes.

BTW, I didn't find this funny at all...

tokumaru wrote: BTW, I didn't find this funny at all...

yeah.. doesnt help the image references is a dead link too :-p