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?
  • 1
    \$\begingroup\$ Its one game on which i recollect as a gift from my childhood \$\endgroup\$ – Vishnu Dec 14 '10 at 6:04
  • \$\begingroup\$ For a video of this game in action to see the scrolling effect Nav is talking about, see dosgamesarchive.com/download/dangerous-dave \$\endgroup\$ – Tim Holt Dec 14 '10 at 7:12

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.

  • \$\begingroup\$ Wow! good to get info from someone who had actually worked on those video modes in assembly! \$\endgroup\$ – Nav Feb 24 '14 at 9:54
  • \$\begingroup\$ @Nav ehm... you are actually talking to Romero himself :-) \$\endgroup\$ – Gianluca Ghettini Jun 18 '16 at 21:27
  • \$\begingroup\$ @GianlucaGhettini Well, it's a user with the photo of Romero that's available on the internet. Would John Romero create an account just to answer one question? Can't be entirely sure :-) It's quite odd though, that you commented just one day after I played Dangerous Dave after a very very long time. \$\endgroup\$ – Nav Jun 19 '16 at 17:19
  • \$\begingroup\$ @Nav according to his tweet here: twitter.com/romero/status/679769135681826817 he actually told Todd Replogle how to do EGA smooth scrolling for Duken Nukem, which is exactly what he's stating in this answer. I doubt someone pretending to be him knows about it.. :-) \$\endgroup\$ – Gianluca Ghettini Jun 19 '16 at 17:25
  • \$\begingroup\$ This article confirms that user42604 is indeed Romero gamasutra.com/blogs/DavidLightbown/20170223/289955/… \$\endgroup\$ – mastazi Jan 10 '18 at 2:41

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

  • 3
    \$\begingroup\$ "Somehow it doesn't seem as fun as manipulating hardware registers though :)" - True :) \$\endgroup\$ – Nav Dec 14 '10 at 11:13

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


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...


  • \$\begingroup\$ This game would be using the 320x240 video mode. \$\endgroup\$ – Skizz Dec 14 '10 at 16:04
  • \$\begingroup\$ Skizz I was thinking that too, but I found some screenshots of the game that were 640x400 - an EGA resolution. There were different versions of the game, and I am guessing the early ones were 320x200. \$\endgroup\$ – Tim Holt Dec 14 '10 at 16:10

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.

Hope you'll learn from looking at the code.

  • 1
    \$\begingroup\$ And in case you want to see a timelapse of him making the game: youtube.com/watch?v=ZV-AFnCkRLY \$\endgroup\$ – はると Dec 14 '10 at 8:55
  • 1
    \$\begingroup\$ -1, although it looks the same, it's clearly not using the same method at all. \$\endgroup\$ – user744 Dec 14 '10 at 10:05
  • 2
    \$\begingroup\$ I am aware that this is not the exact method John Romero used in 1988. But since @Nav wanted to create something similar I didn't except him to program it using Applesoft BASIC on an Apple II computer. The code I linked to, clearly gets the same job done as you pointed out. \$\endgroup\$ – はると Dec 14 '10 at 11:06
  • \$\begingroup\$ Thanks Joe, but Eibx is right that I was looking for alternate ways too. \$\endgroup\$ – Nav Dec 15 '10 at 4:43

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.