The Animation of Phoenix, Part 3: The Joys and Pains of Double-Tilemapping

Side-by-side images of the two tilemaps drawn in the arcade version of Phoenix (1980), as seen in the MAME GFX viewer.

My previous entries on Phoenix discussed the character animations and the paths of the enemies across the screen.  Here, I'm going to talk about how those things were achieved internally -- specifically, how the developers used a pair of tilemaps to animate everything in the game.  This was unusual for arcade games of the era; most developers used sprites to animate objects that spent a lot of time in motion.  In what follows, I'll talk about how the two approaches differ, and the benefits/drawbacks of each.

In Phoenix, each of the tilemaps was drawn from a different set of 8x8 tiles, both of which are shown below.  Note that each tileset could be displayed with any of 32 color schemes

The two tilesets used in the arcade version of Phoenix (1980).

Advantages of Tilemaps


The biggest advantage to using two tilemaps to construct all of the graphics in Phoenix, and probably the primary reason that the developers chose to do so, is speed.  Animating from tilemaps is very fast -- faster than sprite animations -- and in 1980, none of the existing sprite hardware was capable of animating as many fast-moving sprites as you see in the early levels of Phoenix.

[UPDATE 03/02/2020 - It is not always the case that tilemaps are faster for rendering moving objects than sprites because sprite hardware will sometimes be optimized for thing like collision detection, which will require extra CPU cycles if you're using a tilemap.]

Animation from the first round of the 1980 arcade game, Phoenix, showing the small fliers in formation and dives.

The most commonly used graphics hardware in shooters of the time was Namco Galaxian, and it only permitted 7 primary sprites at one time (excluding bullets).  In fact, the Galaxians were animated with tiles while in formation, and only converted to sprites when they started to dive.  The Pac-Man hardware had similar restrictions to Galaxian, only allowing 8 sprites on the screen at a time.

Namco would eventually develop specialized graphics hardware for Galaga (1981) that could animate full enemy formations with sprites, but it required a CPU dedicated entirely to moving the enemies.

Coordinated Motion

Another nice thing about the tilemap approach is that it makes coordinating the motion of the enemies very easy.

Slow motion animation from the first round of the 1980 arcade game, Phoenix, showing the small fliers moving in unison..

In an era when you needed to do everything with a bare minimum of CPU cycles, the tilemap offered a convenient way to keep the enemies in sync with one another.  Instead of having to coordinate the timing of seven independent hardware sprites, fliers are just separate tiles on the same map.  Coordination comes automatically, so long as you use the same tiles for each flier.  Phoenix made full use of this capability, and I think it's part of what gives the game its unique visual appearance.


Jumpy Enemy Motion

Animation comparing the 1979 game Galaxian with the 1980 arcade game, Phoenix.  Galaxian's diving sprites moved more smoothly than Phoenix's tiled birds.

One of the primary disadvantages of tiles is that you have to place them on a grid and can't place them any more precisely than the size of a tile.  This means that sprites tend to have smoother motion than tiled objects.  In the animation above, the Galaxian sprites clearly move more smoothly than the Phoenix flier.  Theoretically, you could achieve the same smoothness with a tilemap if you had tiles for every possible offset from the tile center, but doing so requires a lot of RAM/ROM and is seldom practical.

It could be argued that the jumpiness in the small fliers of Phoenix is actually a good thing; after all, their fluttering, jerky movements are very bird-like.  The same kind of motion could have been achieved with sprites, however, and presumably the designers would have preferred to not be restricted to jumpy motion.

Object Overlap

A close look at the first two rounds of Phoenix will reveal a major drawback to the tilemap approach to enemy animation:

Animation from the first round of the 1980 arcade game, Phoenix, showing the small fliers disappearing when they fly over one another.

Because the small fliers were all drawn on the same tilemap, they couldn't be overlaid on one another.  This meant that when they flew past each other, the game would have to decide to use the tiles from one set of enemies or the other.  In the above a snippet, which is shown in slow motion, the tiles from the ascending fliers are invisible briefly as the descending ones pass by.  Compare this to the descending enemies in Galaxian, which are made from sprites:

Animation from the 1979 arcade game, Galaxian, showing the enemies overlaying cleanly on a flyover.

Fortunately, the sprite overlap issue is barely noticeable in Phoenix at 60 frames per second because the enemies in the first two rounds are small and fast.  It would have been more noticeable with the large fliers, and this is likely the reason that they are left in strict vertical alignment in rounds three and four:

Animation from the third round of the 1980 arcade game, Phoenix, showing the large birds staying vertically separated.

Note that you can overlap enemies that are drawn on different tilemaps.  In the fifth round, the small fliers can be seen flying across the mothership without an issue:

Animation from the fifth round of the 1980 arcade game, Phoenix, showing the small fliers flying over the alien mothership boss.

Look around the edges of the mothership, however, and you'll see the symptoms of an overlap problem.  The background, including stars and planets, is in the same tileset as the mothership, so the edges of the mothership are left black.  This doesn't look too bad here because the mothership isn't moving, but you may have noticed that the background is not drawn at all in the rounds with the large fliers.  If it had been, the large flier tiles would have been constantly swapping out with background tiles, making the tiling obvious to the player.

So... Tiles or Sprites?

Objects that move around the screen a lot are usually better to draw with sprites.  The designers of Phoenix were clever enough to mask, and in some cases even exploit, the seeming drawbacks of animating with tilemaps, but for most games the lack of smooth motion and the overlap problems would have been game killers.  For example, imagine how the following scene from a game of Pac-Man would have looked if Pac-Man and the enemies had been drawn from tiles:

With tiles, the ghosts would not have been able to overlap smoothly, as the red and orange ghost do in the second half of the animation, and there would have been a flickering effect every time the ghosts passed one another.   And unless the designers stored ghost/Pac tiles with a wide range of vertical and horizontal offsets, their motion through the maze would have been jerky, making it harder for the player to distinguish the small speed differences between Pac and the ghosts.

Of course, every game faces different design challenges, so there are no hard-and-fast rules.  If Pac-Man had needed to draw hundreds of enemies in the maze instead of just four, the developers probably would have looked more seriously at the tilemap approach.  

As it is, Phoenix is not necessarily a breakthrough in game design, but rather a fascinating case of successfully taking the road less traveled.  Its graphical capabilities were arguably among the best of its time and it would have provided pressure on developers of similar games to give the player a more impressive visual spectacle.  Perhaps that's why the developers of Galaga went to such great lengths to improve their graphical hardware.


  1. It also looks like Phoenix makes heavy use of the "multiple tiles offset" trick to make movement smoother. Even the player sprite is a tilemap, not a sprite, and a bonus of using offset duplicates is that since this approach requires eight frames anyway, you can make it an eight-frame animation loop at no additional ROM cost, which they did.

    And with the large fliers, offset duplicates are used only on the X-axis, with the entire tilemap layer scrolled vertically to make them fly up and down. I'm sure you're aware of that, but I observed this from seeing the tilemap in motion (you can unpause the gameplay with 'P' while the tilemap viewer is open), and I found it too interesting not to mention.

    1. I didn’t know you could see the tilemap in motion, thanks for mentioning that.

      I did notice the offsets, but your comment about the big fliers lacking vertical offsets has me thinking that was another possible reason that they’re kept to strict vertical separations. Then they could only be moved smoothly up and down by shifting the whole map!


Post a Comment

Popular Posts