How did they make the screen move in Dangerous Dave?

Question

I've made games in BASIC when I was a child, and I was curious about how the graphics were done in the 1988 version of Dangerous Dave made in C++; especially because they didn't have any worthwhile graphics packages those days. Remember how when Dave reached the edge of the screen, the entire screen graphic used to move leftward in a sweeping motion? I remember reading that Romero had used a special technique to do that. I've been wanting to create something like Dave, and was wondering

1. what graphics package/method they used for Dave?
2. and how to make the entire screen graphic move like they did?

Answer 1

My 1988 version of Dangerous Dave was the Apple II version. The scrolling was done by moving all the screen bytes over then drawing a new tile on the edge of the screen - repeat 20 times for a full screen shift. The Apple II version was written all in 6502 assembly language.

On the PC, the 1990 version, I wrote graphics code in 80x86 assembly language for all video modes at the time: CGA, EGA, VGA. Dangerous Dave PC is the only game I know of that has all 3 video modes in it and switchable at any time (F2), even in the middle of a jump!

To scroll the screen quickly, it was all in assembly language and I used a similar technique as I used with the Apple II version - quickly move bytes in video memory and draw a tile on the right side. In EGA it was trickier because to do anything quickly in EGA mode required the use of Latch Mode for memory moves. I remember teaching Todd Replogle how to do that so Duke Nukem 1 would be a fun game (a slow Duke Nukem would not have been cool).

The game code for Dangerous Dave PC was written in C, in the Borland C 3.0 IDE. Most debugging was done in Turbo Debugger on a 12" amber monitor plugged into a Hercules card.

Answer 2

Ah I remember these techniques from my DOS days. Moving the video RAM around with blitting to perform scrolling would have resulted in jerky scrolling. EGA introduced the the vertical and horizontal pixel panning registers which could be used to set the screen origin (where in video memory the video card started displaying data from). Because there is no memory copying going on this is almost instant and can be used for very smooth and fast pixel by pixel scrolling on EGA and VGA if you have direct access to the hardware registers. Most scrollers in DOS would have used this, and this part of the code would probably have been written in assembly language to directly access the hardware registers. These methods aren't really valid anymore though. To achieve a similar effect now, I think on modern graphics hardware you could probably do it fast enough just redrawing the entire screen each frame. The other method I can think of is using OpenGL or DirectX and rendering a texture to a quad twice the width of the screen and moving that. Somehow it doesn't seem as fun as manipulating hardware registers though :)

Answer 3

Edit: Here is a link to an article from Dr. Dobbs that discusses sideways scrolling. It may be the method used for this effect.

http://www.drdobbs.com/184408045

---

It's hard to judge exactly how this was done, but consider that this game was written for a very specific hardware specification - DOS with a EGA video card (640x480 pixels). The code probably is doing some pretty low level manipulations of video memory to make the scroll happen smoothly.

Here is a website that talks about programming DOS graphics that might give you a sense of what it would be like...

http://www.phatcode.net/res/224/files/html/index.html

Answer 4

Metagun (game developed by Markus aka Notch aka MineCraft guy) has the same scrolling feel you're looking for.

The game is Open-Source and written in Java.

• Game: http://www.mojang.com/compo/metagun/
• Source: http://www.mojang.com/compo/metagun/metagun-source.zip

Hope you'll learn from looking at the code.

Answer 5

I can think of two ways this has been done:

1. Brute force: just draw the scene
2. Mode-X and panning registers. Draw the bit to be scrolled into view and adjust the panning registers to scroll the scene. You would need to redraw the top display area each frame, but that is less work to do than drawing the main play area. You wouldn't need to redraw the bottom area as there was a register in the hardware that would cause the video DACs to read from address 0 at a given scan line (so the bottom area would be at address 0 in video ram and the top would start after the bottom area)^*.

I'd probably go with 1) as there's not much graphically going on, there may be some self-generated code to blit and clip images at the edges. One possible technique that a collegue of mine was working on back then was self-writing sprites, that is, the sprite data wasn't data, it was code. This meant there were no transparency checks and the data read of the blit was effectively free (this was on a 386 where each instruction was read and then decoded so instead of read code->read data->write data it was just read code->write data). It worked amazingly well - we got lots of huge sprites on multiple parallax layers running at 25fps+.

But we are talking about Romero here and there's probably a bit of exageration going on about the techniques.

• I did actually do this in my first major DOS game, and there's a bug in some hardware whereby the address reset happened a scanline too soon so you'd have a half-height pixel between the two sections.