Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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

5 Answers 5

up vote 10 down vote accepted

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

share|improve this answer
2  
"Somehow it doesn't seem as fun as manipulating hardware registers though :)" - True :) –  Nav Dec 14 '10 at 11:13
add comment

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.

share|improve this answer
    
Wow! good to get info from someone who had actually worked on those video modes in assembly! –  Nav Feb 24 at 9:54
add comment

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

share|improve this answer
    
This game would be using the 320x240 video mode. –  Skizz Dec 14 '10 at 16:04
    
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. –  Tim Holt Dec 14 '10 at 16:10
add comment

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.

share|improve this answer
1  
And in case you want to see a timelapse of him making the game: youtube.com/watch?v=ZV-AFnCkRLY –  Eibx Dec 14 '10 at 8:55
1  
-1, although it looks the same, it's clearly not using the same method at all. –  user744 Dec 14 '10 at 10:05
2  
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. –  Eibx Dec 14 '10 at 11:06
    
Thanks Joe, but Eibx is right that I was looking for alternate ways too. –  Nav Dec 15 '10 at 4:43
add comment

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.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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