26

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.

Chip's Challenge on DOS

2
  • the C64 didn't really have a bitmap mode like that. It was more like a console or a hardware-accelarated ZX Spectrum with more modes, i.e. it had character cells or tiles or attributes, and sprites. 320x200 resolution, 16 colors, but any 8x8 cell could have only 2 colors, or 4 colors with double-wide pixels. And the whole screen could be fine-scrolled, and sprites could be layed over it. So it was not a directly "memory-mapped" "bitmap". Sep 13, 2021 at 20:11
  • Thanks for the info, but this question was about MS-DOS. Funnily enough I'm more interested in C64 at the moment, I found MS-DOS to be a bit frustrating. Sep 14, 2021 at 10:21

7 Answers 7

34

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.

10
  • 1
    Very interesting. I wasn't aware there was a "frame buffer." I suppose it's not a dedicated section of RAM and you have to allocate it yourself. I'll put it after the user variables (I'll see if I have enough room, I still have a lot to learn about MS-DOS. I'm more used to working with game consoles than traditional computers so a lot of the things I'm used to are handled by dedicated chips without my input. As for the mouse "eating away" at the screen, the best solution I've found is to hide it when drawing to the screen, silently move it then have it reappear elsewhere. Sep 4, 2021 at 12:20
  • 2
    You can have 4 semi-independent layers in 16-color modes and palette trickery youtube.com/watch?v=iSVAFEbB_j8 That runs smoothly on a 286/12 or even 286/10. Youtube isn't smooth of course. Those who got to see that back in the day probably remember it. And VGA allows setting the starting address of the video page, which allows for smooth hardware scrolling. Though still just one plane. And then there's a screen split which allows you to have a separate stationary part in the bottom of the screen, used for the score display here: youtube.com/watch?v=MSaohyJ_E2w&t=120s Sep 4, 2021 at 13:25
  • 4
    @puppydrum64 No, the frame buffer is a dedicated area of RAM, located on the graphics card. it's were the frame displayed is stored. Hence the name. Do not confuse with modern software managed frame buffers, this is about the real hardware.
    – Raffzahn
    Sep 4, 2021 at 15:35
  • 2
    A couple of minor quibbles... Regarding mouse handling, few DOS games actually supported the mouse, and games that did pretty much always had their own cursor handling (if they displayed a cursor at all). Early mouse drivers didn’t support VGA anyway. It was documented that the mouse cursor had to be hidden before screen updates, this was always a known problem and the only programmers that “got round to anticipating it” were those who didn’t read docs (which admittedly wasn’t unusual). Sep 4, 2021 at 16:57
  • 1
    Regarding double-buffering etc., it doesn’t help ensure a consistent framerate, it helps avoid screen tearing and seeing screen updates as they happen. Sep 4, 2021 at 16:58
10

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.

14
  • ...though, as the 4.77 MHz page on the DOSBox wiki says, "DOSBox has only one speed control, and it slows down all computer instructions by the same percentage (more or less). It is therefore not possible to tell DOSBox to slow integer math by X%, floating-point math by Y%, and non-math by Z%, etc. Near-perfect 4.77 MHz speed will not be possible until someone builds an XT emulator specifically for this purpose." and it provides a benchmark tool for you to experiment with to find the best match for your host CPU.
    – ssokolow
    Sep 4, 2021 at 8:09
  • 2
    IIRC, my 286/12 was able to rep movsb at most something like a 320x50 area from main memory to mode 13h video memory at the 70 Hz refresh rate. 8 bit Magic VGA ISA card. Far from 320x200 x 100Hz. That machine was scrapped decades ago already, so can't test. Sep 4, 2021 at 17:18
  • 2
    @piiperiReinstateMonica it makes a huge difference if a 286/12 is using ISA at default 6 (or 8) MHz and one WS, or if that is as well run at 12 MHz and zero WS, doesn't it?
    – Raffzahn
    Sep 4, 2021 at 17:21
  • 3
    Pedantically: DOSBox is very accurate to the environment it emulates, a DOS computer being defined no more specifically than by its instruction set, the DOS services, and the hardware memory and IO map. It just doesn’t seek to be accurate to any specific DOS computer. So it’s because there’s no one DOS computer that DOSBox is accurate. … or, more likely, I’m arguing semantics.
    – Tommy
    Sep 4, 2021 at 17:29
  • 1
    @Tommy Kinda semantics, but not wrong either. Let's agree that there have been endless variations in real Hardware, while Dosbox is (as you describe) more of an abstract best case szenario.
    – Raffzahn
    Sep 4, 2021 at 18:19
10

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!)

enter image description here

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:

enter image description here

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?

9
  • 2
    If disabling the color animation disables the background sky stripes, it most likely is not a "raster bar" effect where you need to update a single palette entry after every few scanlines. It would be extremely difficult to make it look stable, with all of the keyboard, timer and soundcard interrupts happening asynchronously. Most likely it really uses the same color stripes of 16 colors, and depending on the player Y offset you simply update all color entries of the stripes to make it look like stripes move up or down at different speeds.
    – Justme
    Sep 7, 2021 at 6:37
  • That's possible :) Though the size of the stripes (the period of the pattern) in the main game window would indicate that they'd have to dedicate 32 or 64 colours to the parallax sky alone to achieve that. There's no way there's only 16 colours used, since 16px is the size of Jazz and period is longer than that. If the background had 32 colours, the background landscape tiles would have to be somehow processed to work with that system - the diagonal line tiles would have to have a 0-15 and 16-31 version somehow.
    – knol
    Sep 7, 2021 at 18:06
  • It could be waiting for every 16 lines to copy a block of colours, I suppose, but that would be even more fuss! I'll have to take a dump of the VGA ram at some point and see for sure. The NO COLOR sky definitely looks a lot different to the parallaxed sky. i.imgur.com/ijfkwHE.gif
    – knol
    Sep 7, 2021 at 18:15
  • Mistake in my comment: Jazz isn't 16 either he's 32. :)
    – knol
    Sep 7, 2021 at 19:45
  • 1
    Excellent answer! The lack of good platformers for PC (well, sans Commander Keen & few others) was noticeable until the mid nineties (perhaps ~1993ish onward) when PCs began to be in the high end 386, 486 range with multiple megabytes of RAM and could actually do smooth scrolling without all the demoscene wizardry! Sep 8, 2021 at 8:23
3

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.

2

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.

0

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.

3
  • 2
    The question is only about MS-DOS. Discussing the issue on other platforms does not answer the question.
    – DrSheldon
    Sep 5, 2021 at 18:53
  • The question assumes layers, which is independent of OS, and not universal, and concepts that existed in software predating MS-DOS (this is a retro tech forum).
    – hotpaw2
    Sep 5, 2021 at 18:58
  • 2
    This is a retro computing Q&A site, but not all questions in it require a history of the features they discuss... Sep 5, 2021 at 21:13
0

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:

enter image description here

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.

enter image description here

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?)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .