Sprite Raster Effects

A Guide to the Graphics of the Sega Mega Drive / Genesis

Raster effects, discussed here, are effects created by writing data to the VDP’s tables or registers while it is in the middle of rendering a frame. We’ve already seen raster effects such as palette swapping (writing to CRAM mid-frame) and vertical scaling (writing to VSRAM mid-frame), as well as enabling shadow and highlight mode mid-frame (see the Mega Turrican example here).

Raster effects can also be done by making mid-frame changes to the sprite attribute table. One of these effects is known as sprite multiplexing, which can be used to display more than the VDP’s limit of 80 sprites per frame. Take a look at the snow in the following example from the unreleased prototype of Stone Protectors:

The snow in this scene from Stone Protectors was created by making changes to the sprite attribute table mid-frame.

The first thing to note is that the snow is not drawn to a background plane. Both planes are clearly visible as the screen scrolls. Also note that the snow appears to be falling in layers–three layers, in fact. Each snowflake is actually one sprite. So how many sprites are on-screen at once? Let’s count them in the following scene:

OK, let me give you a hand. The emulator Exodus has a nice feature that outlines sprites:

The emulator Exodus can outline each sprite, as seen here.

That’s a lot of sprites! Here’s how many I counted:

Non-snowflake sprites: 44
Snowflake sprites: 74
Total: 118

We’re clearly way beyond the VDP’s limit of 80 sprites per frame.

Let’s isolate the snowflakes a bit more to see what’s going on:

The background planes have been removed to better see the snowflakes. Notice that they seem to fall in three layers.

Some more details become clear here. There are five different sizes of snowflakes, and they seem to fall in three layers. Within a single layer, two snowflakes are never on the same scanline. The foremost layer, falling at the fastest rate, passes in front of the player character, as does the middle layer. The sprites of the middle and back layer stop falling before they hit the bottom of the screen (where the ground would be).

Let’s further isolate just the foremost layer of sprites:

The foremost layer of snowflake sprites. These are all made from a single entry in the sprite attribute table.

Here we can see that no two snowflakes are ever on the same horizontal line. More specifically, they are vertically spaced about eight lines.

So how is this impressive effect accomplished? The entirety of the on-screen snowflakes are made from just three entries in the sprite attribute table–one for each layer. Every eight scanlines, the sprite entry is re-written with a new horizontal and vertical position (and, sometimes, a new tile to change the size of the snowflake). This process of re-writing the sprite entry is done across the vertical length of the screen every eight lines, with the end result that the screen is covered with snowflakes, all generated from just three sprites. To animate the effect, each frame the positions of the snowflakes are shifted down one or several lines (the rate of the shift determines how fast the snowflakes appear to fall).

Now, let’s turn to another raster effect related to the sprite attribute table. Take a look at this scene from Castlevania: Bloodlines:

Notice the reflections in this scene from Castlevania: Bloodlines.

We’ve seen this stage before, as an example of vertical scaling and shadowing. Now, let’s consider what’s happening with the reflections.

A straightforward possibility is that the characters and their reflections are just separate sprites, with the reflection sprites having their vertical orientations flipped. However, something strange happens when the characters are submerged in the water. Take a closer look here:

Notice how the sprites disappear line-by-line as they hit the top of the water.

The most interesting thing here is that the sprites disappear line-by-line as they hit the water. This cannot be easily accomplished through standard changes to the sprite attribute table. A sprite is either drawn or not–there are no ways to half-draw a sprite. This also isn’t an example of priority–the sprites are not passing behind any high priority tiles here. It’s possible that the sprite tiles themselves are being re-written each frame to reduce their size, but there is a simpler way of accomplishing this effect.

Unlike the example from Stone Protectors, changes are not being made to individual entries in the sprite attribute table mid-frame. Instead, the entire table itself is changing mid-frame. There are two tables stored in VRAM, and when the VDP’s rendering reaches the water line, the VDP register that stores the location of the sprite attribute table is updated to point to a different table.

But let’s take a step back here. We have to first understand an important aspect of the sprite attribute table. Any time new data is written to the table, the VDP stores half of that data in a sprite cache. Specifically, it stores the Y-position of the sprite, the sprite’s size, and its link data. Even if the VDP is pointed to a different sprite table, the cache will not be updated unless new data is written to the table. So, when rendering each scanline, the VDP references the Y-position stored in the sprite cache and the X-position stored in the sprite attribute table. Even if the VDP is pointed to a different sprite table, it will still use the Y-position from the previous table (unless data is written to the new table).

So what exactly is happening in the Castlevania: Bloodlines example? There are two sprite attribute tables in VRAM, which we can call Table 1 and Table 2. The VDP is pointed to Table 1 at the start of the frame. This table contains two copies of every sprite, differing only in their X- and Y-positions (and necessarily their link data). Critically, one of these copies is placed off-screen at the Y-position where the reflection will occur. The following diagram shows this:

A selection from the sprite attribute table labeled Table 1. Note that there are two copies of each sprite, one of which is off-screen at the Y-position where the reflection will occur. The green dashed line indicates the water line, where the VDP will be updated with Table 2.

Once the rendering process reaches the water line, the VDP’s register is updated with the location of Table 2, but no data is written to this table, so the VDP still uses the sprite cache from Table 1. An example of this is seen here:

Here we see Table 2, which contains new X-positions and a new V Flip value. The VDP still uses the Y-position stored in the sprite cache from Table 1. Any part of the first sprite below the water line will now be drawn off-screen at an X-position of 1, and the Y-position, size, and link data from the sprites are irrelevant since they are taken from the sprite cache.

The sprite appears at its new X-position, vertically flipped. It’s shadowed since it’s low priority and S/H mode was also enabled at the water line.

Critically, any part of either sprite that passes across the water line will be drawn off-screen at an X-position of 1. This is how both sprites seem to disappear line-by-line as they hit the water. The new sprite attribute table simply contains a new X-position for that part of the sprite.

In summary, all sprites above the water line are drawn from the sprite data contained in the first sprite attribute table. Once the water line is reached, the VDP switches to Table 2 and uses the X-position and flags (priority, palette, orientation, tile index) from that table, together with the Y-position, size, and link data from Table 1, which is stored in the sprite cache. By switching the sprite attribute table mid-frame, any sprite passing across that point will be partially drawn off-screen.

This same effect was used again in stage 6 of Castlevania: Bloodlines to an even greater extent:

The same effect seen in stage 6 of Castlevania: Bloodlines.

Here, it appears that the screen is warped in several places. When the sprite passes across a particular vertical point, its X-position is shifted to make part of the sprite appear at a different horizontal location. This is the same effect as the water reflection, but instead of re-drawing the sprite off-screen at an X-position of 1, it is re-drawn on-screen at a different X-position.

Return to Table of Contents

List of Effects:

Want to post a comment? You can do so here.