Games built for the Nintendo Entertainment
System were able to create a picture on the
screen using a background made out of tiles,
and some sprites made out of objects.
A total of 64 objects can be displayed at
a time, and only a single background is available,
which can display one of any 256 tiles in
each 8x8 pixel region.
This means if you want the camera to move
around the scene, you have to scroll the background
up, down, left, or right.
And doing so will move the entire screen at
once.
So how do so many games get away with what
looks like multiple background layers?
How do these status bars not move with the
level geometry?
How are these parallax effects achieved?
And how in the world can these backgrounds
move independently of both the foreground
and the status bar?
Let's take a look.
If you've watched some of the other videos
on this channel, you might already know the
answer to the first two questions.
Let's pause the game right here and look at
the raw background as it is stored in video
RAM, known as the nametable.
As you can see, the level geometry and status
bar data are both on this background as you
would expect.
However, the status bar is way down here,
which is not where it shows up on the screen.
It's as if the background is both scrolled
to this position and this position during
the same frame.
And somehow the NES knows to use the first
scroll position for the top part the screen,
and the second scroll position for the bottom
part.
To really understand what's going on we have
to know a bit more about how the image of
the game is drawn onto the television screen.
The entire frame is not drawn instantaneously.
Instead, the image is drawn from top to bottom,
left to right, in a pattern called a raster
scan.
While the electron gun is firing electrons
at the phosphorescent screen, causing it to
light up, the NES CPU is still busy executing
instructions from the game's code.
The instructions can very easily modify the
current image being drawn, while it's being
scanned in by the electron beam.
All it takes is to modify the PPU registers
responsible for indexing into the nametables
in a precise way, in order to have the background
appear to be in two places at once.
How exactly this is done depends on the game's
code itself and how the programmer went about
doing things.
Some games use a native NES functionality
called sprite zero hit in order to get a cue
from the picture processing unit that a certain
screen coordinate is about to be drawn to
the screen.
And other games use a feature of certain ROM
mappers, the programmable interrupt, in order
to ensure that a certain routine will execute
at an exact screen coordinate.
This is how simple background scroll modifications
can be done, like in every game that has a
status bar that stays in place on the screen.
For more complicated parallax effects, multiple
interrupts can be used.
Each frame, the amount the background is scrolled
by is different, resulting in different sections
moving at different speeds.
For games that don't have support for programmable
interrupts, precisely timed code execution
can be combined with the sprite zero hit.
For example, here in Battletoads, the scrolling
effects at the top of the screen are handled
manually by counting cycles, but a sprite
zero hit is used to time the scroll change
further down the screen.
The background position can only be adjusted
in between scanlines, which is why you can
split up the screen up horizontally into regions
that scroll differently, but never vertically.
The entire process of changing the background
scroll positions mid-frame is pretty finicky,
so a lot of the time, flickering or snapping
can occur when certain areas are loading or
if the game is lagging.
But now, how is this sort of effect achieved?
It really looks like there is a second background
plane scrolling completely independently of
the foreground plane.
If both of these are actually the same background,
then how is this updating in the middle of
the screen, when it was just made clear that
the background can only be changed between
scanlines?
This game, Metal Storm, has this effect along
the entire screen, so if it was super precisely
timed code, there would be no time to execute
code responsible for updating the actual game
states and logic.
And then here in Battletoads, there's even
a status bar at the top.
Let's go back and look at the nametable again
and see if that gives us a clue.
With the level geometry stablized in place,
you can start to see what is going on here.
It's not the background position, but the
tiles within the background that are updating!
All of the tiles that make up the backdrop
of the level are changed on the fly in tandem
with the camera's movement in order to fake
a second background layer.
How exactly is this pulled off?
Let's take this level for example.
The backdrop here is a 32x32 pixel repeating
pattern.
Let's see how many different tiles we would
need to account for every position the backdrop
could be in.
There are 32 possible horizontal offsets for
this block of tiles.
And for each of those offsets, there are also
32 possible vertical offsets.
So, 32 horizontal offsets times 32 vertical
offsets equals 1024 different potential states
that can exist!
But the background can only use 256 unique
tiles at one time, so this is a problem.
That, and you need room for all the other
graphics used for the walls, spikes, and platforms.
Now, Battletoads uses a ROM mapper that has
8 kilobytes of character RAM, or CHR RAM on
board.
This means it actually has memory dedicated
to storing graphics that can be read from
and written to (by default, the NES doesn't
support reading or writing graphics data via
the CPU).
Every frame, the pixels of these tiles are
nudged in the correct direction while still
occupying the same space in memory.
This involves modifying the raw 2 bits-per-pixel
graphics data bitwise.
In the end, only 16 tiles are ever used up
for the background, but each tile can take
on one of 1024 different possible states depending
on the position of the camera in the level!
But all of the other games shown here with
independently scrolling backdrops did not
have CHR RAM on board, so how did they manage
it?
Without writable memory, all possible states
had to be baked into CHR ROM images.
Then, these images were swapped out using
bank switching in order to create the illusion
of a moving background.
Now, to limit the number of CHR ROM banks
required to show all states, most of the levels
in these games only scrolled in one direction.
This reduces the number of states by a factor
of 32 for a 32x32 pixel repeating background.
For example, the background here in Mitsume
ga Tooru requires 32 CHR ROM banks, each of
which has 16 tiles in it depicting one of
the states it can have.
You can see while walking through this room
that the bottom half of this page of graphics
gets swapped out on every frame the screen
moves.
Just to show off a few more examples, here
are the CHR ROM banks of a few more games
featuring independently scrolling backdrops.
Sword Master uses a 32x32 pixel repeating
pattern for the blue mountains here, in addition
to a couple of programmable interrupts for
the status bar and the extra parallax on the
foreground.
This room in Bucky O'Hare uses a 16x16 repeating
pixel pattern, which requires only 16 CHR
ROM banks.
And this room in Metal Storm only uses an
8x8 repeating pixel pattern, but it scrolls
in both directions, requiring 8 times 8 equals
64 CHR ROM banks to be able to draw all possible
states.
You can even see other graphics flipping by
in the CHR ROM banks that belong to other
scrolling backgrounds, because the graphics
were efficiently packed into the ROM image
since only one background was ever in use
at a time.
Thank you for watching, and I hope you enjoyed
the video.
Retro Game Mechanics Explained is now on SubscribeStar.
This won't be replacing my Patreon page, but
complementing it by allowing supporters to
choose which platform to use.
Both pages will have the same content posted
to them, so there is no benefit to picking
one over the other.
See you next time!
