Crazy Climber, Part 2: Tiles and the Scrolling Background
The graphics in Crazy Climber (1980) were quite advanced for the time, Phoenix being the only contemporary game of comparable sophistication. I went into great detail describing the animation and graphical setup of Phoenix, which made use of a pair of tilemaps. While Crazy Climber does use a tilemap, it also makes use of two kinds of sprites, with some enemies being rendered with a combination of sprites and tiles. Here I'll talk about how the game handles backgrounds and tiles, and in the next entry I'll talk about the sprites.
The Background and Tilemap
Scrolling
Crazy Climber was one of the first games to feature a scrolling background that did more than just loop. Each level has a distinct layout, which is represented in miniature on the left side of the screen.
The level layout is simple, with different areas being distinguished only by the number of gaps in the tower, but it has a clearly defined beginning and end, something that the scrolling backgrounds of Galaxian or Phoenix didn't have.
At any given moment in the game, the visible part of the tower is stored in RAM, in the tilemap, along with the scores, lives, etc. If you're running the game in MAME, you can actually look at this tilemap by pressing "F4". If I do that at the beginning of the game, here's what it shows:
At this point, it looks pretty much identical to what's shown in the game, with everything but the climber and the sign above the door (which I'll explain in my next entry in this series) represented here. If you look carefully, however, you'll notice that there's more space in the top and bottom of the tilemap than in the game snapshot. This is significant for reasons that will soon become apparent.
Now let's see what happens to the tilemap as the climber starts going up the tower:
This is all by design, however, and what we're seeing is the developers trying to work their way around one of the fundamental limitations of the tilemap approach to graphics. They want to be able to scroll the tower up and down smoothly, but because the tilemap is constructed from discrete 8x8 tiles, they would nominally be restricted to scrolling in 8-pixel jumps. While they could get around this restriction by storing tiles with every possible vertical offset, it turns out there's an even easier way -- to scroll, just adjust the position in RAM that you're using to draw the screen.
This means that, as the climber moves up, the position in the tilemap that corresponds to the bottom of the screen also moves up. Most of the time, this means that the screen draw will have to wrap from top-to-bottom of the tilemap.
This also explains the extra vertical space in the tilemap. As I said before, you can only change the map 8 pixels at a time in the vertical direction, so any smaller adjustments will have to shift the top/bottom of the screen into the middle of existing tiles. This is fine, but if you want to avoid wraparound effects, you'll need to make sure there are additional rows of tiles to shift into. If you watch the tilemap on the left carefully, you can see that whenever the climber pulls himself up to the next row of windows, the screen position moves up smoothly, but the adjustments to the tilemap are jumpy, occuring in 8-pixel chunks outside of the screen boundaries.
At any given moment in the game, the visible part of the tower is stored in RAM, in the tilemap, along with the scores, lives, etc. If you're running the game in MAME, you can actually look at this tilemap by pressing "F4". If I do that at the beginning of the game, here's what it shows:
At this point, it looks pretty much identical to what's shown in the game, with everything but the climber and the sign above the door (which I'll explain in my next entry in this series) represented here. If you look carefully, however, you'll notice that there's more space in the top and bottom of the tilemap than in the game snapshot. This is significant for reasons that will soon become apparent.
Now let's see what happens to the tilemap as the climber starts going up the tower:
Pretty weird, right? The left and right sides of the screen appear the same in both tilemap and game, but as the climber moves up, the tower seems to get jumbled in the tilemap.
This is all by design, however, and what we're seeing is the developers trying to work their way around one of the fundamental limitations of the tilemap approach to graphics. They want to be able to scroll the tower up and down smoothly, but because the tilemap is constructed from discrete 8x8 tiles, they would nominally be restricted to scrolling in 8-pixel jumps. While they could get around this restriction by storing tiles with every possible vertical offset, it turns out there's an even easier way -- to scroll, just adjust the position in RAM that you're using to draw the screen.
This means that, as the climber moves up, the position in the tilemap that corresponds to the bottom of the screen also moves up. Most of the time, this means that the screen draw will have to wrap from top-to-bottom of the tilemap.
This also explains the extra vertical space in the tilemap. As I said before, you can only change the map 8 pixels at a time in the vertical direction, so any smaller adjustments will have to shift the top/bottom of the screen into the middle of existing tiles. This is fine, but if you want to avoid wraparound effects, you'll need to make sure there are additional rows of tiles to shift into. If you watch the tilemap on the left carefully, you can see that whenever the climber pulls himself up to the next row of windows, the screen position moves up smoothly, but the adjustments to the tilemap are jumpy, occuring in 8-pixel chunks outside of the screen boundaries.
Background Objects
The choice to animate an object as a sprite or in the tilemap/background usually depends on a range of factors. Sprites can be moved more smoothly (in most cases), but have limits on the number that can appear on the screen at a time. As such, it makes sense that Crazy Climber animates the most common obstacle, the closing window, in the tilemap, since you will sometimes see 10 or more of these on the screen at a time. See the tilemap animations in the previous section for examples.
What's less obvious is the decision to use the tilemap for the people in the windows. In fact, the game has bitmap data for rendering them in sprite form:
I have never seen these sprites used, however. The game typically draws these folks from the tilemap. Here's a shot from the first stage:
Notice how the two lines of pixels just above the window sill are darker, giving the appearance that the person was hiding in the shadows. This effect is created by splitting the person into tiles with two different color schemes, shown below.
If they had used the sprites instead, there wouldn't have been enough colors to create the shadow effect.
Most of the remaining enemies are rendered with sprites, and I'll talk about that more in an upcoming entry.
Is the score display part of the same tilemap as the skyscraper? If so, what stops it from scrolling as the screen boundary moves?
ReplyDeleteTilemap hardware often had the ability to independently scroll a particular set of columns or rows. In this case, they're only scrolling the columns that correspond to the tower and leaving the score display unscrolled.
DeleteIt reminds me of how NES games did parallax scrolling (and Genesis games did multi-layer parallax scrolling) by adjusting the screen boundary on a per-scanline basis.
DeleteBut Crazy Climber is scrolling vertically on a horizontal monitor. That means it must be changing the screen top position mid-scanline. And that seems... crazy.