Overview of the VDP
The VDP (Video Display Processor) is the custom-built video chip responsible for rendering the Mega Drive’s graphics. More than any other component of the system, the VDP defines the console’s graphical characteristics and limitations. To understand the Mega Drive’s graphics means, in most regards, to understand how the VDP functions. In this section, I present an overview of the VDP’s features and capabilities.
Like most of the video chips of arcade boards and home consoles of the 1980s, the VDP is tile-based. A tile, in the case of the VDP, is an 8 x 8-pixel square, and it represents the most basic graphical unit that the VDP can display. All of the graphics of the sprites and background planes are composed of such tiles (note that since pixels can be transparent, a tile may appear to be smaller than 8 x 8, but the VDP still sees it as 8 x 8). Tiles are typically stored as data in the cartridge ROM and then transferred to the VRAM (Video RAM—the VDP’s memory), where they are referenced by the VDP when it renders the screen. Using tiles is advantageous because it reduces memory use and simplifies game development. Instead of having to reference the location of every pixel in order to draw the screen, developers only have to reference each tile, and the same tile can be referenced multiple times.
For NTSC televisions, there are two display sizes that the VDP can output: 40 x 28 tiles (320 x 224 pixels) and 32 x 28 tiles (256 x 224 pixels). PAL televisions, as used in European and other countries, have slightly different specifications that the VDP also supports, but for the sake of simplicity I will focus on NTSC here. The 40 x 28-tile mode, abbreviated H40 (in contrast to H32), was by far the most common mode used in Mega Drive games. H40 mode allows greater resolution and also displays pixels at an aspect ratio closer to 1:1 than H32 mode (in H32 mode, pixels appear horizontally ‘stretched’ on the screen—e.g., an 8 x 8-pixel square will appear as a rectangle). In this guide, I will always assume H40 mode unless otherwise mentioned.
The VDP supports two scrolling background planes, Plane A and Plane B. These planes are generally used to display a game’s backgrounds, platforms, foreground, and so on. Each one functions the same as the other, with Plane B being behind Plane A by default. Two planes can be used in unison to create a parallax scrolling effect—giving the illusion of depth—if they move at different rates (the techniques of line, row, and column scrolling, discussed below, can also be used to create parallax effects).
The VDP allows the size of the background planes to be set, and the following sizes are possible (horizontal x vertical, units are tiles):
- 32 x 32; 32 x 64; 32 x 128
- 64 x 32; 64 x 64
- 128 x 32
Note that both planes must be set to the same size; it is not possible to set each to a different size. Since the standard display size is 40 x 28 tiles, what happens if the background plane is 32 x 32 tiles? In fact, planes loop endlessly. When either the horizontal or vertical end of a plane is reached, it simply loops back to the beginning. Even if the plane size is less than the display size, the screen can still be fully covered with tiles, although some tiles will be repeated. If the developer wants a single full screen of non-repeating tiles, a plane size of at least 64 x 32 tiles is necessary (assuming H40 mode).
This raises another question: What is the point of having background planes larger than the display size? The VDP’s planes support an important function for 2D games: scrolling. The 68000 can tell the VDP to scroll one or both planes independently of each other either horizontally, vertically, or on both axes. This scrolling can be done pixel-by-pixel, meaning the scrolling movement is smooth, and the speed of the scrolling can be adjusted. Even though a plane might be larger than the display size, it can still be fully viewed by shifting it into the display area (e.g., as the player moves). The two 64 x 64-tile planes shown above, from Dynamite Headdy, scroll independently so that each can be fully viewed:
The maximum horizontal size of a plane is 128 tiles—beyond that, a plane will loop back around to its beginning. However, most side-scrolling games feature stages much longer than 128 tiles, yet the backgrounds don’t seem to loop. How is the background content kept unique while utilizing planes of limited size? Typically, the graphics of the background plane are loaded dynamically—streamed—as the plane scrolls. In Gunstar Heroes or Sonic the Hedgehog, for example, the plane size is 64 x 32 tiles. When the player moves forward (or, in the case of Sonic, forward, upward, downward, or backward), the CPU updates the VDP with information about the next column of tiles to be displayed on the plane (in both Gunstar Heroes and Sonic, only Plane A, the ground and immediate background, is updated; Plane B, the far background, scrolls unchanged in a loop). Therefore, the plane is not a constant, fixed image, but rather it is continuously being redrawn with new tiles as the player moves. The new tiles are drawn to the portion of the plane that is off-screen, so the player never notices.
The VDP can scroll the entirety of each plane horizontally and/or vertically, but it can also scroll portions of each plane. Horizontally, each scanline (1-pixel height) and each tile row (8-pixel height) can be scrolled independently—these are known as line scrolling and row scrolling (or cell scrolling), respectively. Vertically, each two-tile column (16-pixel width) can be scrolled independently—this is known as column scrolling. These scrolling techniques allow for a range of special effects. Perhaps the most well-known is their use to create parallax effects. The impression of depth can be created by having certain sections of the screen scroll at different rates relative to other sections. This effect is sometimes mistakenly thought to be created by a multitude of layers piled on top of each other, each moving at a different speed, but it is actually just individual parts of the same plane scrolling at different speeds.
The VDP also supports a window plane. This is actually rendered as a portion of Plane A that remains fixed in place and does not scroll with the rest of the plane, although the tilemap that defines it is different from Plane A’s tilemap. The window plane is typically used to display information such as the player’s health, lives, and score. Since using a window reduces the size of the game screen, some games opt to not use it and instead to display player info using sprites overlaying the background layers.
In addition to two scrolling background planes, the VDP supports a large number of on-screen sprites. Sprites are individual graphical objects that represent characters, enemies, items, and other typically small, moving things on the screen, and they are one of the main components of 2D games. To illustrate, at the most basic level, a 2D platformer is constructed from a scrolling background plane, a sprite representing the player character, and sprites representing enemy characters, items, and obstacles.
Sprites are formed from tiles (the same 8 x 8-pixel tiles as the background planes). The VDP supports sprites of different sizes, ranging from 1 x 1 tile to 4 x 4 tiles, including every permutation in-between (1 x 3, 3 x 2, and so on). The size of each sprite is defined individually, so there can be a mixture of sprites of different sizes. Since tiles can contain transparent pixels, it is possible for a sprite to appear smaller than 8 x 8 pixels, although it is still processed the same by the VDP. An on-screen object can also appear larger than the maximum 4 x 4 tiles by joining two or more sprites together. This does not require anything special from the programmer aside from always keeping the two sprites a fixed distance from each other. In fact, sprites can be freely joined together to create very large characters, although there is a limit to how many sprites the VDP can support.
A maximum of 80 sprites can be defined by the VDP at any one time. Note that a sprite is still counted as unique even if it shares the same graphic tile as other sprites (e.g., each independent bullet in a shoot-‘em-up is a unique sprite). In addition, there are per-scanline limitations on how many sprites can be displayed. On each horizontal line of the display, the VDP can render a maximum of 20 sprites and a maximum of 40 sprite tiles (320 pixels). The latter limitation is relevant in cases where sprites are made of multiple tiles in the horizontal dimension; if each sprite has four horizontal tiles, only 10 sprites can be displayed per scanline. If either the 20-sprite limitation or the 40-tile limitation is exceeded, then the VDP will not display any further sprites on that scanline. In such cases, how does the VDP determine which sprites to display? Each sprite is defined with a priority number relative to every other sprite, and the higher priority sprites are drawn before the lower priority sprites (note that this sprite priority is different than the display priority discussed in the next section).
Sprites in video games are often animated, especially for the player and enemy characters. ‘Animated’ here means that the sprites cycle through a series of animation frames to, for instance, give the impression of walking or running. The VDP does not do anything special to support animation. Rather, the 68000 just updates the VDP’s sprite information every few frames to reference a different graphic tile in VRAM (or, optionally, the sprite information is kept the same but the VRAM tile it references is swapped; this technique will be discussed in more detail later).
A final point to mention concerning sprites is that the VDP can flip a sprite across both its horizontal and vertical axes. This is an important feature for side-scrollers, for instance, since the player and enemy characters have to be able to face both directions.
We’ve seen that the VDP supports two independent, scrolling background planes. It also supports up to 80 sprites on-screen. In rendering the screen, the VDP combines the information from both planes and the sprites to determine what is in the active display area.
Here an important question is raised: how does the VDP know the order in which to compose the planes and sprites? Can a sprite, for instance, be rendered behind a plane? The answer is that the planes and sprites follow a particular display priority, and the VDP checks this priority to determine what is rendered on top. The priority for each plane and sprite can be set by the programmer, so that scenes can be created in which some sprites pass under background planes and so on.
Each tile of each background plane, as well as each sprite, can be set as either low priority or high priority. By default, when set at the same priority level, the planes and sprites (and the solid background color) are displayed according to the following priority:
Sprites > Plane A > Plane B > Background Color
This means that, by default, sprites appear on top of both planes. Note that the background color, which can be set via one of the VDP registers, always has the lowest display priority, and this cannot be adjusted. Among sprites, a sprite with a higher sprite priority will be appear on top of a sprite with a lower sprite priority (sprite priority, mentioned above, is different from display priority and refers to the order in which the VDP draws the sprites).
By setting a sprite or plane’s priority to high, that sprite or plane will always appear above anything with low priority. If multiple sprites or planes have high priority, then they follow the same default display order as just listed. The following diagram shows a basic breakdown of priorities:
The above diagram is potentially misleading, however, since a single background plane can have both low and high priority sections. For planes, priority is set for each tile, meaning there can be complex patterns of low and high priority sections. This might be used in a game to create depth, such as by having the player sprite pass behind objects placed at the bottom of the screen—the foreground—while not passing behind background objects, all on the same plane.
Another potentially misleading aspect of the above diagram concerns sprites. Sprites are always displayed relative to one another depending on their sprite priority; a sprite with high display priority but low sprite priority will appear behind a sprite with low display priority but high sprite priority. Therefore, regarding display priority, the diagram only reflects the behavior of sprites relative to the background planes, not to other sprites.
There is one major aspect of the VDP that I have yet to mention: color. Perhaps no other characteristic of the Mega Drive attracted more attention in comparisons to the SNES than its limited color capabilities (whether such matters are practically important is open to debate). In principle, the VDP supports 64 colors on-screen spread across four 16-color palettes. In practice, it is actually 61 colors. Sprites and planes cannot use the first color of each palette, since the VDP interprets this color as transparent. However, the background color can be set as the first color of a palette; therefore, including the background color, the VDP can display 61 colors on-screen. These colors are selected from a total of 512 colors. Each sprite and each tile of the background planes can use colors from only one of the four palettes, meaning each sprite or tile is limited to 15 colors.
The VDP supports several functions that can be used to increase the number of colors displayed on the screen. One of them is known as shadow and highlight mode. This mode allows the brightness levels of the palette colors to be adjusted to either a darker or brighter level. Apparent from the name, this is intended to be used to create a shadow effect, such as the shadow of a character or building, or a highlight effect, such as a spotlight or the rays of the sun. When this mode is activated, both shadow and highlight masking effects can be created by setting a sprite to a specific color and palette value; the sprite will then become transparent, and the shadow or highlight effect will apply to the background plane under the sprite.
The entirety of the background planes can also be shadowed if they are both set to low priority. Although the claim is true that shadow and highlight mode allows the VDP to display nearly three times its stated limit on the number of colors (some colors overlap, so the number is not truly tripled), the reality is that the mode is difficult to implement due to having to carefully manage layer priorities, and the games that used it did so sparingly.
Another function of the VDP that can be used to increase the number of on-screen colors is the capability to do mid-frame palette swaps. This is used in games such as Gaiares to create the effect of transparent water covering only a portion of the screen.
To accomplish this, the VDP is updated with new color palettes (or just individual colors) when it is in the middle of drawing the frame to the screen. The outcome is that one vertical section of the screen is drawn with one set of palettes, while another vertical section is drawn with a second set of palettes. This can be done more than once per frame, although there is a tradeoff that limits its use: noticeable dots—artifacts of changing the palette mid-frame—appear on each scanline where a color is swapped (skilled programmers can avoid the on-screen dots, although such instances were rare among released titles). Developers would typically cover the dots with a layer of sprites to hide them. Mid-frame palette swaps are an example of raster effects—effects that are done by modifying VDP values while the screen is being rendered. This will be covered in more detail later.
The normal process of sending data to the VRAM via the CPU is relatively slow (see here for an overview). For each piece of data to be sent, a movement instruction must be loaded from the ROM into the CPU, and then the CPU must transfer the data from its source address to the VDP’s data port (after writing to the VDP’s control port to initialize the transfer). However, the VDP includes a powerful feature known as DMA (Direct Memory Access) that speeds up the process of transferring data to the VRAM. With DMA, the VRAM gains direct access to the system bus in order to receive data from the cartridge ROM or the 68000’s RAM, bypassing the CPU.
To do a DMA transfer from memory to VRAM, the CPU writes to the VDP’s control port, telling the VDP the source address of the transfer, the destination address in VRAM, and the size of the transfer. The VDP then takes control of the system bus and the transfer is initiated. During the time of the transfer, the CPU becomes inactive, since it no longer has control of its bus. However, the transfer is about twice as fast as if done directly by the CPU. DMA therefore allows a greater amount of data to be sent to the VDP, which is very useful for quickly changing the displayed graphics.
Let’s summarize the discussion so far in regards to the VDP’s main capabilities. The VDP is tile-based, meaning the basic graphical unit that it can render is an 8 x 8-pixel tile. Tiles are used to construct the background planes and sprites which make up the screen. The VDP supports two background planes, Plane A and Plane B, and each of these planes can be scrolled either horizontally, vertically, or on both axes. Furthermore, horizontal scrolling can be done at the level of either the full screen, one-tile rows, or individual scanlines, and vertical scrolling can be done at the level of either the full screen or two-tile columns. A section of Plane A can be designated as a window plane that does not scroll.
The VDP also supports up to 80 sprites, but these are limited per horizontal scanline to 20 sprites and 40 tiles. Individual sprites can be of a range of sizes, from 1 x 1 tile to 4 x 4 tiles and anything in-between, and the VDP has the ability to flip sprites either horizontally or vertically. The order in which the planes and sprites are layered on the screen is determined by their priority setting, which can be either low or high. The VDP supports 61 colors on-screen across four palettes, selected from a total of 512 colors. Each sprite and each plane tile has access to a single 15-color palette. The number of on-screen colors can be increased using shadow and highlight mode or through mid-frame palette swaps, but both of these have limitations. Finally, the VDP has the ability to do DMA transfers, which are about twice as fast for loading data into VRAM compared to using the CPU.
Want to post a comment? You can do so here.