How did DOS games manage to have multiple background layers?

Question

Seems like VGA only has one background layer, it appears to be a typical bitmap screen like most home computers of the 80s (Amstrad CPC, Commodore 64 etc.) where each pixel's color is stored in a section of memory that can be written to directly. The closest I can get on DOS (I'm using DOSBox if it's relevant) is the mouse cursor, which seems to "eat away" a portion of the screen when it spawns, after which it can move over top of text without erasing what it passes over.

For an example of what I'm asking, please take a look at this screenshot of Chip's Challenge for MS-DOS. The yellow credits text scrolls over the background. Is it on its own plane somehow? Is every letter a "mouse cursor?" Or, is the screen constantly being redrawn with the letters in their new position? The movement of the text is so smooth it appears to be hardware scrolling like you would see on the NES or Super Nintendo but as far as I'm aware MS-DOS PCs don't have that.

Answer 1

Seems like VGA only has one background layer, it appears to be a typical bitmap screen like most home computers of the 80s (Amstrad CPC, Commodore 64 etc.) where each pixel's color is stored in a section of memory that can be written to directly.

Most video cards of the day could theoretically have up to four pages of video memory, as they had 256 KiB of storage, and only 64 kB was needed per screen for a 320×200 resolution. There was only one displayed "layer" (or plane, to be technically correct) at a time, though. You couldn't render two different things and have one overlay the other, as you do with modern video cards.

The closest I can get on DOS (I'm using DOSBox if it's relevant) is the mouse cursor, which seems to "eat away" a portion of the screen when it spawns, after which it can move over top of text without erasing what it passes over.

This was a feature of the mouse driver software. It would store whatever was underneath the cursor when drawn, and then replaced when the mouse pointer moved. This was independent of video memory.

Some special video modes wouldn't work with this default behavior, in which case the programmer had to draw a custom cursor. The mouse driver would simply suggest where the correct position was in this case.

In fact, some games that updated the screen frequently would have the mouse pointer "hidden" until you moved it. The driver didn't know it needed to update the pixels on the screen. Programmers eventually got around to anticipating this and fixed it with custom cursors.

For an example of what I'm asking, please take a look at this screenshot of Chip's Challenge for MS-DOS. The yellow credits text scrolls over the background. Is it on its own plane somehow?

No, video cards of the day only displayed one plane at a time. The programmer could choose which plane to display in certain modes, however, in a method of page flipping. This allowed the next frame to be rendered ahead of v-sync, so when the page was flipped, it provided an instantaneous change to the display.

Is every letter a "mouse cursor?"

No, they were just normal bitmaps. Things like transparency and multiple layers were not yet possible at the hardware layer; they were managed in software entirely.

Or, is the screen constantly being redrawn with the letters in their new position?

Closer. Each frame is drawn either off-screen, and the displayed plane would be selected for each frame, or in a memory buffer, and then blitted to the screen during v-sync (e.g. with DMA or a simple "memcpy" loop).

The movement of the text is so smooth it appears to be hardware scrolling like you would see on the NES or Super Nintendo but as far as I'm aware MS-DOS PCs don't have that.

They didn't have hardware scrolling per se, but they could use double-buffering or plane swapping to provide a consistent framerate. One such article that appears to do a pretty good job of explaining it is this one.

The unchained/Mode X mode was incredibly useful, as it allowed full access to 256 KiB of video memory at the cost of some complicated algorithms to get pixels where you wanted them. However, for most games, this produced a very nice output at 60+ frames per second. Some of the best games used this technique for quite a while.

In summary, memory back then was at a premium, but developers had a lot of tools available to them provided by the hardware. In a sense, it was still "hardware accelerated", but in a very primitive form. As video memory expanded into megabytes and finally gigabytes of memory, entirely new APIs appeared, such as display lists and other techniques.

However, back in those days, every pixel had to be accounted for, and programmers came up with clever techniques to make those frames as smooth as possible.

Answer 2

Is it on its own plane somehow?

No, as you assumed, VGA has only one plane(*1).

Is every letter a "mouse cursor?" Or, is the screen constantly being redrawn with the letters in their new position?

The latter. Most likely it's composed of a background image moved into the frame buffer, overlaid by the text layer. (*2)

The movement of the text is so smooth it appears to be hardware scrolling like you would see on the NES or Super Nintendo but as far as I'm aware MS-DOS PCs don't have that.

No, it doesn't. Then again, note that the above runs at, in Dosbox terms, 3000 cycles. That's the rough equivalent of a 14-16 MHz 80286 (or 12 MHz 386) if not better. Such a machine (with upclocked ISA-bus) is able to redraw a VGA screen at rates past 100 Hz. More than enough to keep text smooth.

Dosbox isn't meant as an emulation to be as historically exact as possible, but to enable people to run games in an acceptable manner. Therefore it's not a historically exact emulation of a specific machine architecture/configuration, but a rather abstract approach to let games run for gamers, not historians.

Try fixing cycles to 350 and you'll get closer to what an original PC-XT would deliver :)

---

*1 - Though it has multiple pages, which could be used to smoothen animation by page flipping.

*2 - Well, EGA and most SVGA cards do provide a single 'sprite', usually used as mouse cursor.

Answer 3

Geenimetsuri's answer about colour cycling is a very good point that deserves a demonstration. :)

Here's a GIF taken from the end of the first level of Episode 1 of Jazz Jackrabbit. I've slowed it down so you can see the layers. (Jazz runs at 60Hz and is famous for its speed!)

Jazz Jackrabbit uses Mode X for the main gameplay screen. Mode X is a 256 colour mode which provides a single bitmapped layer of indexed colour pixels, like mode 13h. However, unlike mode 13h, it allows the programmer to use the panning and memory offset configuration fields of the VGA hardware to scroll the screen over a region of video memory to provide a large 'virtual screen'. This means that as the camera moves around the 2D world, only new tiles coming into view on the edges of the visible screen need to be drawn, instead of the entire contents of the screen being redrawn every frame†.

There seems to be a number of independent layers used in the Jazz Jackrabbit animation above:

• The static status bar that does not scroll with the rest of the screen.
• The large landscape graphic that moves freely.
• A coloured gradient sky in shades of blue.
• Jazz himself appearing on top of the landscape.
• The static sun sprite disappearing behind the cloud on the right.

Despite Mode X only allowing a single bitmap layer, Jazz somehow has all five elements moving independently, some partially overlapping others. Let's look at them in turn.

The static status bar is implemented using the automatic split-screen feature of the VGA that uses the Line Compare configuration fields to show a non-scrolling horizontal region beginning at a given screen line. This feature lets the programmer split the screen into an upper freely scrollable section, and a lower fixed section.

The upper section is the normal scrollable Mode X bitmapped indexed colour screen, so all the 'layers' you see in that region are either software sprites drawn onto and later erased by redrawing the landscape at that location, or effects created by manipulating the palette.

Look very closely at the blue sky gradient. Notice how it moves at a different rate to the camera when Jazz jumps - it's properly parallax scrolling! If you don't believe me, watch how the lightest bar of the sky matches the height of the green platform on the left when Jazz is standing, but descends slower than the landscape does when he jumps. Prompted by Justme in the comments, I've looked closer into how this effect was achieved:

Jazz (at least on this level) dedicates the last 100 VGA palette colour indices to containing the sky gradient. When background tiles are painted onto the display region, the transparent colour is replaced with a value between 156 and 255 based on the tile pixel's Y position in the world, increasing by 1 every two pixels down the world. This results in a looping pattern 200 pixels tall consisting of 2 pixel tall horizontal bands that repeats down the world behind all the visible foreground tiles. I've modified Dosbox to force the range 156-205 to be black-to-green and 206-255 to be red-to-yellow and recreated the jumping GIF with this forced palette so you can see it in practice:

Since the sky colours in this new GIF stay the same every frame, the green/red sky looks attached to the landscape like flat wallpaper rather than appearing with parallax. (You can tell from the twinkling red diamonds in the background that the rest of the palette is still able to be modified in real-time.)

To make the sky appear to move independently of the landscape when COLOR ANIMATION is enabled, Jazz manipulates the sky colours in the VGA palette every frame. As the sky gradient colour set is copied into the VGA palette, it's offset to a new position based on the camera's vertical position (looping within the 156-255 region in the palette). This makes the coloured gradient bars appear to move at a different rate to the hardware scrolling on screen, even though the contents of the video memory aren't changing.

If you set Jazz to NO COLOR ANIMATION in the Options menu, the palette copying only happens once when the level begins. Since the gradient bar colours remain at their positions in the palette, the sky is static and scrolls with the camera like it's a striped wallpaper on the same plane as the rocks, which it essentially is.

_{I originally thought the sky gradient was a set of raster bars (where a single dedicated colour index representing 'sky colour' is altered on a scanline-by-scanline basis in real time). Since you can see the red/green stripes in the GIF above, I was clearly wrong. :) You can read my explanation of how I suggested raster bars would be applied in this answer's edit log.}

The static sun appears to be another layer, doesn't it? Unlike the Amiga, there are no hardware sprites for VGA to use for this. It's a software sprite drawn onto the Mode X screen (masked behind the existing scenery - reading, comparing, writing) and then erased and redrawn in a new position on the next frame. Jazz himself is drawn the same way, but not masked since he appears on top of the landscape. (When you jump, sometimes you can see Jazz and the sun disappear together when he crosses certain Y values in the world. I think that's to do with the Mode X screen coordinates vertically wrapping, meaning a whole new screen needs to be assembled from tiles and the sprites being ignored for that one costly frame (deliberately or otherwise).)

† Most versions of Jazz support an optional /VGA command-line switch that uses an alternate renderer that (ostensibly) bruteforce draws the entire VGA display instead of using Mode X though. :D

See also this question: What DOS games used Mode X as described by Michael Abrash?

Answer 4

The movement of the text is so smooth it appears to be hardware scrolling like you would see on the NES or Super Nintendo but as far as I'm aware MS-DOS PCs don't have that.

To add a bit on the above excellent answers and comments...

You had several other tricks you could employ on a PC to "emulate" smooth scrolling.

First one, and very widely used in DOS games, was color cycling (aka palette rotation, palette shifting).

Instead of repainting pixels you changed the color they represent. You could do fantastic effects for what was essentially free compared to proper full screen animation. The technique has made a bit of comeback with HTML5 (see this page or e.g. YouTube for examples).

The other option was bit more arcane and related to video memory paging discussed above. You didn't have to flip the entire page, but you could also just shift where the "view-port" begins, and do various masking operations, such as splitting the screen into two halves (as already mentioned in the comments), or even literally scroll the pixels.

The real fun was in managing the process.

You could access most of the functionality from swapping video mode to modifying palette using hardware interrupts (mostly tied to int 10, see e.g. this list), but as the name implies they interrupt whatever the CPU was doing to serve the request. Therefore the preferred for most tasks was to write directly to video memory and access all the other video card functionality using hardware ports as those generally took much less time to process.

In case you're interested in what the inner workings are, I suggest you take a look at the Free VGA website.

In the end, beyond color cycling and page flipping (I think most often this was done from system memory, i.e. you drew the next frame in memory and copied that after vertical sync as accessing system memory was much faster), I suspect the other available techniques were much less used as redrawing a full screen just didn't take that much time for it to matter.

Answer 5

An EGA or VGA game that used 16-color graphics mode could exploit those cards' bit-planar architecture to create either a 7-color foreground and 2-color background, a 3-color foreground and 4-color background, or 1-color foreground and 8-color background, without having to do any save/restore operations on the background. I don't know to what extend games did this, but some styles of games could benefit from such ability. On the VGA, a game that used 4-color backgrounds would also be able to do a smooth cross-fade between two background designs if no foreground content was being shown.

Answer 6

The very idea of hardware full screen bitmap layer overlays in the Amiga OCS was based on the software layer compositing done by game developers for Apple II and early MSDOS games (Budge's Pinball Construction Set, Artwick's Flight Simulator, et.al.) Budge's blit routines, in turn, were influenced by bitblit concepts that propagated to Apple Lisa group from U.Utah and Zerox Parc research. All originally done in (clever) software for hardware that supported displaying only a single bitmap per video frame (most early personal computers with bitmap graphics capabilities, including the the Apple II and the first 8088 PCs).

A Singer Link flight simulator could do large hardware overlays, but could not run DOS games.

Answer 7

On the other end of the MS-DOS era from CGA and EGA games and Chip's Challenge (1991), there's late VGA games like Tyrian (1994) and Rayman (1995) that look like this:

How does Tyrian manage to have sprites, the large grey platform, the trees, semi-transparent clouds, semi-transparent orange explosions, and the dynamically positioned real-time ship shadow below everything except the player's ship itself?

The answer is manually. :) There's no hardware acceleration used in Tyrian as far as I can gather. The game runs in standard VGA Mode 13h, giving the programmers a 320x200 region to draw into, using 8-bit indexed colour (256 colours). Pixels in mode 13h are accessed like a big linear array of memory, so all the programmer needs to do is write a value from 0-255 at a location, and it'll appear there. There's no hardware layers, scrolling, sprites, double-buffering or anything else.

Tyrian redraws the entire game pane every game frame, basically throwing raw processing power at the problem, thanks to Pentium-era processors being fast enough to make it possible. Drawing sprites and tiles quickly is done with efficient routines for skipping groups of pixels when not needed (blank rows of sprites, vacant tiles in backgrounds, skipping to the correct tile in a background partially off-screen or returning early), moving pointers to the next line/tile fast, and so on.

To draw these layers, Tyrian draws the elements farthest to nearest, one on top of the other, erasing the pixels underneath as each one is drawn. First the tree layer, then the sky (which is semi-transparent), then the grey layer, then the explosions (some of which are also semi-transparent), then the player's shadow, then the enemies, then the player's ship. (It may not be that exact order, but you get the idea. :) )

I don't think there's anything that allows the large opaque section of grey platform to prevent the drawing of the green tiles underneath it, it's all just drawn as-is. The sidebar and status bar are persistent and unchanged for the most part so they don't need to be redrawn. For transparency/blending, Tyrian has functions that blit sprites directly using a mask, or blit taking a specified hue, or blit as a darkened area using the mask (menu shadows, player's ship shadows). Semi-transparency is implemented by taking on the colour of the new sprite's pixel and blending the brightness of the existing and new pixels.

Tyrian's palette is organised as rows of hue with ascending brightness, which allows blending to take place by selecting a row (the high nibble of the byte) as the colour and interpolating the column (the low nibble of the byte). That's how the orange explosions and blue sky work. The entire sky layer itself and various types of blending are optionally enabled based on the Detail Level.

You can see all the algorithms yourself in the OpenTyrian source code. It's a C++ rewriting of the original Pascal source, but it still uses indexed colour internally. I don't know if the original Tyrian directly drew to the VGA memory mapped region for all its compositing, but it's more likely it allocated a 64000 byte region for all its drawing, then block copied it at the end of the frame, since that wouldn't be constrained by the slow data reading speed of older cards. (If I'm not mistaken?)