Doogie wrote:
How does scrolling work in the nametable sense is something else I've been wondering
I learned a lot from looking at how commercial games work. Open a game that scrolls in FCEUXD and open the Name table Viewer. I just looked at the game Layla for example. As you walk forward or backwards you can see how new columns of tiles are drawn.
Some game do it a bit differently. Castlevania, for example, updates larger squares one at a time from the top of the screen to the bottom. The advantage of working with squares of that size is that they match exactly the are covered by an Attribute Table byte, so this makes the handling of attributes easier.
Those are 2 simple examples, because they only scroll horizontally. Pick a game that scrolls vertically as well and you can see how it has to update rows and columns of tiles and attributes in order to display the correct portion of the level. This process is a litle complex, specially because you have to take Name Table mirroring into consideration as well.
The process is exactly how tepples explained. Create a camera that follows the main character, and by watching the coordinates of this camera (how much it moves) you will know when a new row or column of tiles or meta-tiles is necessary. You can tell where the row/column will come from (in the level map) and where it will go to (in the Name Tables) from its coordinates and direction.
Since everything I programmed so far used this kind of dynamic Name Table manipulation, I never needed to draw a full Name Table. A tool for arranging Name Tables is useful when you are making title screens, cut scenes and things like that, or when your game has a very limited number of screens.
Scrollers shouldn't be made with these tools, because the data needed to represent a full Name Table (plus the Attribute Table) is too much, even if compressed with generic algorithms like RLE or LZ. Games with large maps need a compact level map format, and a system to decode it to the screen.