My lizard is the Lizard of NES Scrolling
One of the things that made the NES special when it was released was the amount of detail in its background graphics. It was really quite amazing compared to the coarse, chunky graphics of the previous generation of home consoles.
It wasn't just enough to have all this extra detail: it had to be able to move smoothly too. A lot of the early NES games were content to have all their action take place on a single stationary screen, but over its lifetime smooth scrolling backgrounds seemed to become an essential part of most games on the system.
With the limited means available to Nintendo at the time, it was quite a significant engineering problem to get these impressive graphics to slide around!
I've talked a bit before about the tile maps used in NES graphics, but I'll try to explain a bit more about why it works this way.
Using a grid of tiles broke the problem of detail into hierarchical layers to make it more manageable. Modern computers have enough memory to and processing power to simply store each pixel on the screen individually, but the NES had neither the memory nor the bandwidth to accomplish this.
Many computers had already been using a tile grid for displaying text characters (e.g. CGA). Instead of storing every pixel, the screen is covered with a grid of characters, each selected from a smaller set of character tiles. On the NES, you can cover a whole screen with tiles using just 1024 bytes (1 kilobyte) of data. It was important to be able to cover a large area with a small amount of data, because the bandwidth for updating it was very limited.
The NES had to send new data to the graphics chip during the very brief vertical blanking period between frames. Outside this time, it was busy generating the TV picture signal, so it could not be interrupted. Because of the limited speed of the CPU, this left time for only about 100 bytes to be sent: enough for a couple of rows-- just enough to make scrolling practical!
This grid of tiles is known in NES development as a namemtable, and represents the coarse, top layer of the NES graphics hierarchy.
The individual tiles were drawn with 8x8 4-colour pixels, each requiring 16 bytes. The full collection of 256 tiles required 4096 bytes (4k) of memory in total. This is how the fine detail, bottom layer of the hierarchy was stored, and it's usually referred to as either CHR (an abbreviation Nintendo derived from "character"), or the pattern table.
Because of the high volume and density of information in the CHR, it takes a lot more bandwidth to make changes to it. Most NES games for this reason do not directly make changes to the CHR, using read-only memory to store the data, though there are many exceptions and ways around the bandwidth limitation.
So, having accomplished very detailed backgrounds with this hierarchical grid of tiles, how do we get them to move around?
If we need to pan the image on the screen over to the right, a simple way might be just to copy every tile entry one space to the left. This could work, except for the bandwidth problem: we can only update part of the screen at a time! It would take many frames and have a visible tear between the two partially updated screens during the transition. Sluggish and ugly.
Instead, we want to leave the data where it is, but just tell the graphics chip to start drawing the picture starting from the second column rather than the first. What happens when it reaches the edge of the screen in memory, though? The GPU knows to wrap around back to the other side, like Pac-Man. All we have to do is fill in the wrapped column with new tiles!
That's a good start. Now we can scroll the screen but only have to update a single column at a time, but it's not very smooth, is it? What we really want is per-pixel scrolling, not per-tile, so we have to think about the other layer in the hierarchy too.
If the GPU can start partway through the tile, you can scroll to any pixel you want, but remember that we have to work with the tile grid too. If you are showing half a tile on the left, and half a tile on the right, that's an extra column of data that needs to be part of the screen! When it's wrapped around, the same tile can't simultaneously be the old half tile on the left, and the new half tile on the right. One of them is going to show the wrong tile.
To deal this this problem you either need a background data buffer that's larger than the screen, or you need to hide the edges of the screen. The NES actually takes both approaches, strangely, and both are somewhat incomplete.
In my update about sprite rendering I mentioned how the NES has an option to hide the left 8 pixels of the screen. This also hides the left edge of the background. It's enough to cover a single column of 8x8 tiles, but unfortunately the NES tile maps have 16x16 colour regions (see my previous update on tile maps), so even if it could hide the tile error at the edge, some incorrect colours are still going to stick out.
One or two games even went so far as to manually compensate! Teenage Mutant Ninja Turtles (1989) places 16 black sprites along the right edge of the screen to hide the scrolling errors.
The other approach, though, is having a background that's bigger than the screen. The NES GPU actually reserves 4 kilobytes of memory for 4 screens in a 2-wide, 2-high arrangement, which wraps around at the edges. This would almost be perfect, but there's an important limitation: even though it reserves 4k, it only had a 2k RAM chip, so there's really only enough memory for 2 screens!
This may seem like a strange decision, but RAM was an expensive component, and also not available in 4k packages: it was either going to be 2k or 8k. (I think it's to do with how pins on a chip come in pairs: 2 pins = 2 address bits = 4x size increments.)
Nintendo has a curious long history of "dual screen" devices too...
The intention was that 2 of the 4 screens would be duplicates. They have unique addresses in memory, but they end up being redirected to the same physical place in the RAM chip. This technique is known as mirroring. It was actually accomplished by passing one of the nametable RAM's address lines through the cartridge, so each game could choose either a horizontal or vertical arrangement that would be hardwired by a connection inside the cartridge.
In this way, the NES was designed to make games that could either scroll horizontally, or vertically, but over time many techniques were developed to do more complicated things.
A lot of early NES games did not try to scroll the screen. They simply did most things within a single screen, sometimes using the second one as an auxiliary to switch to during transitions.
Lizard was originally conceived as a single screen game. In a previous update about my influences, I mentioned Prince of Persia (1989), which was itself a single screen game. I was especially inspired by the grid arrangement of its rooms, and how that lent itself to mental organization while exploring.
Since internally the NES has two screens, it can be sensible to design your game to be two screens wide (or tall). You can prepare the whole field at once, and not have to worry about updating it for scrolling.
Since the double wide update, Lizard has had this kind of arrangement, where every room is exactly two screens wide. The wider rooms gave me more space to work with, and I think the scrolling improves the way things feel too, but the rigid boundaries also let me retain the "grid of rooms" arrangement that was my original goal.
To go beyond the limit of two screens, you can continuously update the offscreen part of background memory with new rows or columns. Note how the colours are not updated at the same time as the tiles in this example from Ice Climber (1984); this is because the tile and colour information are actually stored in separate locations. It's okay, though, as long as you've updated both before the screen scrolls them into view.
One of the first features added to NES cartridges replaced the hardwired background mirroring with a switch you could toggle in software. This allowed games like Metroid (1986) to scroll seamlessly both horizontally and vertically, but not at the same time.
Most games that did scrolling in both directions at once had to choose between scrolling errors on the vertical edge, or the horizontal edge, depending on which mirroring option was taken.
On NTSC region systems, the top and bottom 8 pixels were usually cut off by the television. Blaster Master (1988) prefers the horiziontal arrangement for this reason, though on PAL systems scrolling errors would be seen at the top and bottom of the picture.
Gauntlet (1985) extended the two screen idea to four screens by including its own nametable RAM inside the cartridge, and bypassing the NES' internal RAM instead of mirroring it. This made it practical for it to put large numbers of enemies directly on the background, more than could have been handled with sprites alone.
Status Bar, Raster Splits
Mixing continuous scrolling with a fixed status bar was a difficult problem on the NES. There are a lot of different techniques for this, and each game usually required a unique solution that fit its design.
The basic technique for a status bar uses a raster split technique. On a CRT the TV picture is drawn in real time, line by line, each line known as a raster. For a lot of video game systems, this meant that with very careful timing, you can make changes to the GPU on a particular line, splitting the screen into two parts.
The Guardian Legend (1988) uses a horizontal arrangement of nametables here, even though it's a continuous vertical scroll. This is okay, though, because the status bar is used to cover the part of the screen that would show the scrolling seam error. At the raster split point, the GPU's scroll position is changed immediately to the status bar's location.
Do you notice the curious blue rectangle at the left side just above the status bar? This is actually used to time the raster split! The NES didn't really have any practical built-in timer, but it did have the ability to test one sprite for overlap with the background in real time. By positioning the sprite at the raster split point on the screen, as soon as that overlapping sprite gets rendered by the TV you know it's the perfect time to switch the scrolling.
Most games tried to hide the timing sprite in some way. Super Mario Bros. (1985) stuck it in the coin indicator, which is why it seems to partially overlap Mario's boot.
A lot of later games would include a timer device inside the cartridge to make more complex raster effects possible. Here in Shatterhand (1991) it creates a parallax effect that makes the slower moving background appear more distant. Note how the two "distant" strips never update the nametable; they are simple loops that are two screens wide.
Super Mario Bros. 3
Super Mario Bros. 3 (1988) takes an interesting approach, sort of an extension of the two screen idea: all* levels in this game are exactly two screens high (whether or not the camera lets you go up there). This forced a horizontal seam error at the right side of the screen, though they did use the hardware feature to hide 8 pixels on the left side.
I quite like this solution, because it simplifies level loading. Instead of having to deal with updating data both vertically and horizontally, the level data can be streamed in entirely as vertical strips.
(* Well, not all of them. There are a few special levels like Pipe Land 7-1 that are vertically oriented instead.)
Above I mentioned that even though CHR changes are high bandwidth, there are ways to get around it. Even though there is only a 4k window of memory for CHR background tiles, the cartridge hardware can map larger memories into that window with a technique known as bank switching. I discussed this a little bit in my update about ROM space, but basically what it allows is an instant switch of one tileset for another.
Crisis Force (1991) uses CHR banking to create tiles that parallax against the background with a flipbook animation.
Solar Jetman (1990) scrolls on both axes, but mirrors the nametable screens in an unusual way. Instead of using one of the standard horizontal or vertical nametable mirroring arrangements, it maps all 4 to one half of the internal RAM at once, and then with a raster split it maps all 4 to the other half for the status bar. Because all 4 screens point to the same data at once, it can take advantage of both horizontal and vertical wrapping at the same time.
As with The Guardian Legend, it uses the status bar to hide the vertical scroll seam, though it does have visible errors horizontally.
There's endless variations here, and this barely scratches the surface. Because of how much the NES hardware exposed to the cartridge, there were a lot of possibilities. It was a popular and long-lived system, so there were a lot of very creative scrolling solutions over the years.
If you want to take a look for yourself, I recommend finding a debugging emulator that has a nametable viewer like FCEUX. (It's in the "debug" menu.)
Alright, after all that I should tell you where I'm at with Lizard.
I'm just finishing up the River Zone section of the game now. Still to go are the Mountain Zone boss and final boss, plus a couple of small odds and ends to tie up before we can begin beta testing.
I'm sorry it's been so long since the last update. I wanted to make the next one about scrolling to go along with the river, so I put writing the update off until that task was done. Unfortunately, I am not very good at working linearly, and I ended up working on a bunch of other stuff in tandem with the river (and it's just me, so "in tandem" really means I stopped working on the river to do the other things). There's been a final overhaul of the PC/Mac/Linux frameworks, a bunch of work on the two remaining bosses, and a lot of other smaller changes since the last update.
After everything above, though, I'd hope the River Zone scrolling would be pretty easy to understand. I use the sprite timer to split the screen at the top of the water. Not too fancy, just enough to give a little bit of parallax to the background. My goal with Lizard was never to push the hardware to its limit; I just thought it was a nice visual effect for this part of the game.
Funny too, because the river scrolling effect had been implemented a long time ago! It was actually in the demo ROM, just not accessible. To try it out: enter the password JLMNN, and before entering the password door, press and hold A and SELECT before pressing UP.
The recent work on the river has been everything but the scrolling. Animating this snake boss, for example, was an ordeal:
Anyhow, I'm really sorry I put off this update so long. I'll try to get some other updates out soon to make up for it.
For anyone interested in more frequent, more tiny updates, I created a twitter account for the game a little while ago:
I'll finish this update with two quick shout outs:
1. The 2016 NES Compo has just completed. It's a not-quite-annual competition of NES homebrew games, and this year's bunch were really great! There's a lot of cool games to try.
2. Jeffrey Wittenhagen is writing a book about NES Homebrew games, and I think that's cool. Its Kickstarter campaign is coming to a close very soon. Check it out if that sounds interesting: