Scrolling
Moderator: Moderators
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Scrolling
Hello NES dev
I have a question about scrolling
I understood how the loopy_v and loopy_t makes scrolling possible, my question is from programmer point of view
as I understood, I f i will use vertical mirroring , I put the name table data in " a " name table and the hidden screen in the "b" name table section
http://wiki.nesdev.com/w/index.php/File ... iagram.png
then during programming , when I detect that the player is near the edge and pressing , I write the x and y of the top left tile to scroll in the next frame
first , am I right in what I said ?
second , if I am right, when I debugged a game to see this , I haven't seen that ! so why ?
I have a question about scrolling
I understood how the loopy_v and loopy_t makes scrolling possible, my question is from programmer point of view
as I understood, I f i will use vertical mirroring , I put the name table data in " a " name table and the hidden screen in the "b" name table section
http://wiki.nesdev.com/w/index.php/File ... iagram.png
then during programming , when I detect that the player is near the edge and pressing , I write the x and y of the top left tile to scroll in the next frame
first , am I right in what I said ?
second , if I am right, when I debugged a game to see this , I haven't seen that ! so why ?
Re: Scrolling
You are right, but the problem is that scrolling by giving the adress of tiles by $2006 only control coarse scrolling. This is largely inpractical, and this is normally used only in split-screen raster effects (aka scroll changes in the middle of the screen) because we have no choice. But when we do "plain" scrolling, we use $2005 and $2000 writes only, since this allow us to control not only the coarse scrolling, but also the fine scrolling (i.e. where to scroll within a 8x8 tile). I hope that made sense.
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: Scrolling
ok this is good,
So why i didn't see this in emulator ppu debugger?
So why i didn't see this in emulator ppu debugger?
Re: Scrolling
Which game are you trying? Try putting a breakpoint on writes to $2005.
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: Scrolling
I was trying in megaman game
I used an open source emulator to view the name tables but what I found that 2 name tables are similar ( due to mirroring ) and the other two are black ( I expected to see the next screen in them )
I used an open source emulator to view the name tables but what I found that 2 name tables are similar ( due to mirroring ) and the other two are black ( I expected to see the next screen in them )
Re: Scrolling
Oh then you tried a Mega Man in the 3-6 range. Those have a rather unconventional scrolling engine, where, like you observer, only one name table is used. They use the horizontal mirroring when scrolling horizontally and vertical mirroring when scrolling vertically, in order to never show the 2nd name table, which is reserved for special effects/animations and minibosses.Muhammad_R4 wrote:I was trying in megaman game
I used an open source emulator to view the name tables but what I found that 2 name tables are similar ( due to mirroring ) and the other two are black ( I expected to see the next screen in them )
You can observe, for example, Mega Man or Mega Man 2 in order to see more convnetional scrolling in action.
Re: Scrolling
That is, if you call Battletoads and Super Mario Bros. 3 "unconventional". But seeing as they were released later in the NES's life, perhaps they are.
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: Scrolling
Alright
I have debugged megaman 2 and found u said
but what is the other way to scroll with only 1 nametable ?
I have debugged megaman 2 and found u said
but what is the other way to scroll with only 1 nametable ?
Re: Scrolling
Turn off the "display left 8 pixels" bits in PPUMASK. Then update single 8-pixel-wide columns of the nametable that enter this area. Because 16-pixel-wide attribute columns straddle this area, some artifacts are unavoidable unless you have 15 sprites to spare and not many per line. These artifacts can be seen at the far right of the screen in Super Mario Bros. 3, for instance.
Re: Scrolling
Alfred Chicken and Felix the Cat are examples of games that use a column of sprites on the far right of the screen, combined with background masking on the left side of the screen, to completely avoid horizontal scrolling glitches.
As a general rule, the tile map needs to be larger than the viewport by at least the width/height of 1 block of which scroll updates consist of, in order for there to be no scrolling glitches. On the NES, blocks are usually 16x16, since that's the smallest area affected by background attributes. Many capcom games use 32x32 blocks when updating the background, though, so those need more extra room for scroll updates.
Under normal circumstances, the NES has plenty of room for updates in one axis, which depends on the type of name table mirroring you use, but the other axis ends up with no extra space at all. Many games didn't care about this and just left the glitches there (or partially masked them), hoping that the televisions of the time wouldn't make them very obvious.
With 1 screen mirroring, you have to worry about glitches on both axes, since there's no extra room in any direction. You can either reduce the viewport and make room for the updates, by masking the leftmost 8 pixels and using sprites to hide the rightmost 8 pixels, in the case of horizontal scrolling, and/or disabling background rendering at the top and bottom 8 scanlines (Jurassic Park does this using CHR bankswitching and all black tiles), in the case of vertical scrolling. Or you can just leave the glitches there, like many developers back in the day did.
As a general rule, the tile map needs to be larger than the viewport by at least the width/height of 1 block of which scroll updates consist of, in order for there to be no scrolling glitches. On the NES, blocks are usually 16x16, since that's the smallest area affected by background attributes. Many capcom games use 32x32 blocks when updating the background, though, so those need more extra room for scroll updates.
Under normal circumstances, the NES has plenty of room for updates in one axis, which depends on the type of name table mirroring you use, but the other axis ends up with no extra space at all. Many games didn't care about this and just left the glitches there (or partially masked them), hoping that the televisions of the time wouldn't make them very obvious.
With 1 screen mirroring, you have to worry about glitches on both axes, since there's no extra room in any direction. You can either reduce the viewport and make room for the updates, by masking the leftmost 8 pixels and using sprites to hide the rightmost 8 pixels, in the case of horizontal scrolling, and/or disabling background rendering at the top and bottom 8 scanlines (Jurassic Park does this using CHR bankswitching and all black tiles), in the case of vertical scrolling. Or you can just leave the glitches there, like many developers back in the day did.