Side scrolling example

[SaucJedi]

Hi guys, I've been looking here and there but failed to find if there is some detailed (as much as possible) example about doing side scrolling on the NES, both ways (left-right).

Is there any I missed? Thanks

[Kasumi]

Something like this?

I have no idea how good that tutorial is, though. A quick check makes it seem like it only scrolls right, but figuring out how to scroll left when you know how to scroll right is like figuring out how to check is up is pressed when you know how to check if A is pressed.

There's also a lot of info in this topic where a bunch of people help someone who is trying to scroll.

[Denine]

I have no idea how good that tutorial is, though.

Looking fairly good, but it uses loop for BG updates during NMI.I think it's better to use unrolled writes from zero page, because it's faster.

figuring out how to scroll left when you know how to scroll right is like figuring out how to check is up is pressed when you know how to check if A is pressed.

Not really, IMO.You don't just check for\write different value but also need to read that value(meta tile\Tile itself) from different location.This engine updates only 1 half of 2x2 meta tile at...wait.A quick look into game reveals that there's no meta tiles used(just NameTable data), so it's easier, but space consuming.You want to use meta tiles to save some space.

[Kasumi]

Not really, IMO.You don't just check for\write different value but also need to read that value(meta tile\Tile itself) from different location.

The point I'm making is if you understand right scrolling, you can do left scrolling with no problem, just as if you understand how to read one button you can read another.

My program uses the exact same code for the meat of the left/right updates. All that changes are like four or five values setup beforehand that specify the column is that needs to be updated. It works because scrolling left to column 33 needs the same tiles and attributes as scrolling right to column 33. It's really not a big difference, or leap in logic.

[Denine]

Oh, I'm sorry them.

[Dwedit]

I made a 4-way scrolling test program once, let me know if you want the code.

[tokumaru]

I'm of the opinion that sharing code for scrolling is kinda awkward, because that part of the program heavily relies on how other things are implemented.

Scrolling is basically divided in the following steps:

1. detecting the need to render a new column/row;
2. finding and decoding the column/row from the level map into buffers;
3. calculating the destination address for the column/row in the name tables;
4. copying the data from buffers to VRAM during VBlank;

Step 1 involves watching the "camera" as it moves every frame. Whenever it crosses a block boundary (this happens when a certain bit - which depends on the size of the blocks that compose your level map - in the camera's coordinates changes), a new column (horizontal scroll) or row (vertical scroll) of blocks/metatiles has to be updated.

Step 2 is about using your camera's coordinates to calculate the coordinates of the row or column that has to be updated. Once you have that, you can decode the tiles and attributes into buffers. This step can obviously vary drastically depending on how your level maps are encoded.

Step 3 is when you use the scroll values to calculate the VRAM address where the decoded tiles must be written to. You obviously have to think about the attributes too.

Step 4 is just a straight copy. It's better you do it with the fastest code possible, in order to not waste much VBlank time on this, and be able to perform other tasks (update sprites, palettes, etc.) in the same VBlank.

You can see that the implementation of the above steps can vary greatly depending on the dimensions of your blocks (most people prefer 16x16-pixel metatiles, but several popular NES games use 32x32-pixel metatiles, which in some ways is more convenient on the NES) and the encoding used for the level maps (some games decode the maps into RAM beforehand, making them easier to read from, but other read the encoded data directly... some use RLE for compression, others use LZ, and several other crazy schemes). The type of name table mirroring also heavily affects the design of the scrolling engine. Since there's no universal standard for these things, the code for scrolling varies a lot from game to game, and what people here can show you might not fit your game's design.

[SaucJedi]

First, thanks everybody

@Tokumaru: I know that the PPU related parts are pretty coupled to how the rest of the game works but checking examples and developing from there is easier than starting from scrath IMHO

@Dwedit: that would be very interesting, specially when I understand better one way scrollling.