SMB3's right-side scroll artifacts: Why not in SMB1, SMB2?
Moderator: Moderators
-
- Posts: 2158
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
I honestly hate horizontal mirroring... I think since our eyes are side by side, we have a more panoramic vision, and thus notice the glitches on the left and right edges of the screen more so than we would on the top and bottom. Also, I seem to remember talking about this a year or so ago, and I think Bregalad made a note that glitches are more noticeable if they occur in the direction you are scrolling. This is a good point too.
I hardly ever see vertical glitches; maybe it's just my TV. Like others said, they're also easier to mask by blanking out scanlines.
I hardly ever see vertical glitches; maybe it's just my TV. Like others said, they're also easier to mask by blanking out scanlines.
If you want free scrolling and a background status bar, the easiest solution is single-screen mirroring, but that comes with color artifacts on the sides, like in SMB3.tepples wrote:Vertical mirroring is probably ideal if your status bar is sprite-based. But if your status bar is background, you'll probably need to use a mapper IRQ to skip the rows of the map dedicated to the status bar.
An option I have considered but never actually used because I never had the need for a background status bar is to draw the status bar every frame in a safe place. Sounds a little extreme, but with highly optimized/unrolled code it should be possible to draw it in 8 scanlines or so... That would be done during the visible frame, so it wouldn't steal any VBlank time. One day I might try this.
Interesting idea. Could be used with mappers like UNROM to get multidirectional scrolling and a background based status bar on top. Wouldn't even waste cycles for the status bar area if some static timed task could be run there... I might give this a try.tokumaru wrote:An option I have considered but never actually used because I never had the need for a background status bar is to draw the status bar every frame in a safe place. Sounds a little extreme, but with highly optimized/unrolled code it should be possible to draw it in 8 scanlines or so... That would be done during the visible frame, so it wouldn't steal any VBlank time. One day I might try this.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
I imagined using the first few scanlines of the frame to draw the status bar (since those scanlines are outside the safe area you wouldn't want any information there anyway) and then a sprite hit would indicate the end of the status bar. At that point you might need to blank a few more scanlines, in order to avoid vertical scrolling glitches. Please let us know if you code something like this!thefox wrote:Could be used with mappers like UNROM to get multidirectional scrolling and a background based status bar on top. Wouldn't even waste cycles for the status bar area if some static timed task could be run there... I might give this a try.
True, I forgot about sprite 0 hit (although the polling would still waste some cycles, but at least it'd allow running some variable timed task during the status bar as long as its worst case run time is known). I'll keep you posted.tokumaru wrote:I imagined using the first few scanlines of the frame to draw the status bar (since those scanlines are outside the safe area you wouldn't want any information there anyway) and then a sprite hit would indicate the end of the status bar. At that point you might need to blank a few more scanlines, in order to avoid vertical scrolling glitches. Please let us know if you code something like this!thefox wrote:Could be used with mappers like UNROM to get multidirectional scrolling and a background based status bar on top. Wouldn't even waste cycles for the status bar area if some static timed task could be run there... I might give this a try.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
I understand your point, and that's your opinion.I honestly hate horizontal mirroring... I think since our eyes are side by side, we have a more panoramic vision, and thus notice the glitches on the left and right edges of the screen more so than we would on the top and bottom.
However have you checked my unfinished demo against the real SMB3 ? You'd notice the attribute glitches are MUCH less noticeable in my demo in fact if you didn't KNOW they were there you are likely not to ever notice them. Even more so on PAL hardware where 2 pixels aren't rendered on the right edge (and on the left too but it's hidden by $2001 masking anyways).
You should play Final Fantasy in Nintendulator and you'll definitely have a hard time NOT so see them.I hardly ever see vertical glitches; maybe it's just my TV. Like others said, they're also easier to mask by blanking out scanlines.
By the way it's good to see you're back.
Useless, lumbering half-wits don't scare us.
Nintendulator doesn't emulate NTSC overscan. It shows the entire picture that the emulated RGB PPU generates.Bregalad wrote:You should play Final Fantasy in NintendulatorCelius wrote:I hardly ever see vertical glitches; maybe it's just my TV. Like others said, they're also easier to mask by blanking out scanlines.
I've found another technique to make mirroring glitches harder to see: draw blank tiles in the row of tiles that crosses the seam. A blank tile never has the wrong attribute. I use this for the scrolling text in Concentration Room and my multicart engine.
Absolutely, that's exactly why I was saying that. Sorry I forgot to mention it at firsttepples wrote: Nintendulator doesn't emulate NTSC overscan. It shows the entire picture that the emulated RGB PPU generates.
This is an interesting technique. It will probably work wonders for scrolling text (hem hem... such as the Power Pak Menu which currently looks terrible on my PAL NES). However for a scrolling level it might be just as noticeable if tiles "pops" in and out when scrolling. If would work fine in a game with overall dark graphics, but not so good with a game with overall bright graphics.I've found another technique to make mirroring glitches harder to see: draw blank tiles in the row of tiles that crosses the seam. A blank tile never has the wrong attribute. I use this for the scrolling text in Concentration Room and my multicart engine.
Also it would add unnecessary tile updates for scrolling.
That being said I'd still consider doing this as it's better than showing the wrong tiles.
Useless, lumbering half-wits don't scare us.
-
- Posts: 97
- Joined: Sat May 28, 2011 10:30 am
I just happened to be watching the ending to Bubble Bobble 2 when I noticed it has the same artifacts, but vertically.
http://www.youtube.com/watch?v=FOMg5kL1Dxg&feature=related
Happens about half way through the video, when scrolls upward.
http://www.youtube.com/watch?v=FOMg5kL1Dxg&feature=related
Happens about half way through the video, when scrolls upward.
You shouldn't be surprised, a lot of NES games suffer from that. I'd guess that 98% of the games with 8-way scrolling have glitches either vertically or horizontally, and a good portion of the games that scroll in only one axis have them too, without any good excuse.
Many of the Mega Man games for example have scrolling glitches, even though they only scroll in one axis at a time. There's no (real) excuse for that, since they use a mapper with mirroring control. I believe that the reason they simulate 1-screen mirroring is to always have one free name table for the in-game menus. With just a little extra work (i.e. allowing the menu to be split across both name tables or even re-rendering the whole background when leaving the menu) they could have avoided the glitches.
Many of the Mega Man games for example have scrolling glitches, even though they only scroll in one axis at a time. There's no (real) excuse for that, since they use a mapper with mirroring control. I believe that the reason they simulate 1-screen mirroring is to always have one free name table for the in-game menus. With just a little extra work (i.e. allowing the menu to be split across both name tables or even re-rendering the whole background when leaving the menu) they could have avoided the glitches.
Mega Man 1 used UNROM which has not mirroring control. On the vertical scrolls you will see some glitching at the bottom. I honestly think they just reused that same engine for at least the next game and did not mess with the scrolling.
Maybe someone more familiar with the code of the Mega Man series can comment.
Maybe someone more familiar with the code of the Mega Man series can comment.
Some TVs cut off a lot of vertical space, horizontal too but not to such a degree. For example, the TV a friend and I played NES on all the time, didn't have a problem with it until we tried Legacy of the Wizard and you couldn't really see where the ladders are on the bottom of the screen (maybe only 1 or 2 rows of pixels visible).
Same goes for the top 8 scanlines, you can see it an every emulator pretty much, but on any TV that I've seen, it's not visible at all. Maybe that's why it's so obvious in that Bubble Bobble 2 video.
Same goes for the top 8 scanlines, you can see it an every emulator pretty much, but on any TV that I've seen, it's not visible at all. Maybe that's why it's so obvious in that Bubble Bobble 2 video.