33

I always wondered how the DOS games like Sky Roads, Turbo, Aladdin, Duke Nukem, Commander Keen 6 were written. I cannot find a good source. If I write a console application in C#, C++, Java etc.. It is always displayed and remains still. And it is always Text.

  1. How did they generate graphics?
  2. Were there any libraries to use?
  3. What languages they used?

Any good source will be appreciated.

Mustafa
  • 10,013
  • 10
  • 70
  • 116
  • Duke Nukem was built using the "build" engine, which has source code available [here](http://advsys.net/ken/buildsrc/). – user786653 Sep 18 '11 at 09:42
  • 2
    @user786653, Duke Nukem *3D* was built with that engine. Duke Nukem was a platform game for DOS, from 1991. – Prof. Falken Sep 18 '11 at 10:06
  • @Amigable: Oops, you're of course right. Hadn't thought about that game in 15 years. – user786653 Sep 18 '11 at 10:10
  • 18
    CAN SOME ONE EXPLAIN WHY IS THIS OFFTOPIC? Its programming related. Some people with high reputation but with low esteem makes me sick. – Mustafa Sep 20 '11 at 15:35
  • 4
    I didn't vote to close it, and did vote to re-open it. This question is sort of hit-and-miss regarding [the FAQ](http://stackoverflow.com/faq) though. "A specific programming problem": you can't figure out how to do graphics. "based on actual problems that you face": ...hard to tell. I wouldn't write games this way. If you're writing a programming history paper, then it is OT. "If you can imagine an entire book that answers your question, you’re asking too much": I have read several such books over the last 20 years :) IMO, your question is a 50/50 fit on this site. – Merlyn Morgan-Graham Sep 20 '11 at 17:48
  • Agreed 100 % with Merlyn Morgan-Graham. – Prof. Falken Sep 21 '11 at 09:16
  • For what it's worth, I wrote a space invaders style game in the 90s using only ASCII text. I used Borland Turbo C and could write characters to any location in the console. ;-) – James Dec 29 '16 at 14:13
  • 1
    OMG this is such a fun question! I liked Borland Turbo C back then but the graphics library that came with it was so damned slow that I had to copy assembly snippets from books and assembly experts I talked to on BBS while running up my phone bill to $400 in one month to speed up basic things like image blitting and rotation in mode 13h. I ended up voting to re-open. What fun! Why is it that all the most fun questions are always closed? –  Jan 05 '18 at 18:43

4 Answers4

22

Assembler, Pascal and C were popular languages. Graphics were generated by directly interfacing with the display hardware, for instance the Color Graphics Adapter. (CGA)

Probably there were libraries, but not like today, and libraries were often not shared outside a company.

A resource which would have been relevant in say, 1988, can be found here:

https://web.archive.org/web/20170910230837/http://gd.tuwien.ac.at/languages/c/programming-bbrown/advcw1.htm

Prof. Falken
  • 24,226
  • 19
  • 100
  • 173
9

How did they generate graphics?

Games from that era usually wrote directly to the graphics hardware. They mapped to a special place in memory, and directly manipulated pixels as if they were an array.

Were there any libraries to use?

Sound and network driver libraries were common. Which ones, I don't know - these days you wouldn't have to provide drivers along with your game due to the Hardware Abstraction Layer provided by the OS itself.

Besides this, there were the C/C++ language standard libraries. Game middle-ware libraries didn't become as common until after that era.

Examples of middle-ware are:

  • Physics libraries such as Havok
  • Image format loader libraries such as DevIL
  • Sound format loader libraries such as FMOD
  • Video handler libraries such as Bink

The DOS days were, however, the popular birth of the Game Engine. Examples from that day include:

What languages they used?

C and assembly were extremely common.

More rarely Pascal, or more other more obscure languages.


If you want to develop low-level software like was done in the DOS days, programming for an old game system might be a good idea. NES, C64, Gameboy and Gameboy Advance programming all require the author to utilize direct hardware access, and require you to know C or some form of assembly. You can use an emulator to run and debug your finished product, so it isn't as high a barrier to entry as current-gen consoles.

If you just want to develop a DOS-style game, these days you have a lot of graphics and sound libraries available to you. Instead of doing things exactly like they did, I recommend using one of those libraries. Allegro, SDL, PyGame, OpenAL, and OpenGL to name a few.

You will still be able to do low level graphics programming, but you will get your game running much faster, will have better tech support when things break, and your game will be cross-platform.

Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183
  • 4
    +1 I like your answer except that OP is not asking about how to do a new DOS game now, but how old DOS games were made then. It's like if some historian investigates how people farmed 100 years ago and you say, yes, but it's better to use a tractor. :) – Prof. Falken Sep 19 '11 at 12:11
  • 1
    @Amigable: Lol! You'd darn well better use a tractor ;) I interpreted this line as them picking up a hoe and starting to plow their field: "If I write a console application in C#, C++, Java etc.. It is always displayed and remains still. And it is always Text." – Merlyn Morgan-Graham Sep 19 '11 at 18:21
5

You are probably mixing up the notion of a console/terminal, that is, a text-only window fed by text streams with a few escape commands, with the DOS computer itself. The console is not DOS, and DOS is not the console.

A console takes care of displaying the text its client applications send to it via the input and output streams, of scrolling the old text up and statically displaying it. A console is a layer above the graphics hardware, and a service of the operating system, and you don't need it to display graphics. In DOS times, the program would directly write into the graphics buffer, circumventing the text-only display you see.

On the other hand, consoles exist today (such as xterm or the windows command prompt), and they have nothing to do with DOS.

thiton
  • 35,651
  • 4
  • 70
  • 100
3

The really old games were sometimes written in Assembler, as were the graphics libraries. But C/C++ was used a lot too.

I tried to write some graphics/game code too that time and I used C, Basic and Assembler. My favorite was the graphics mode '13' which was 320x200 in 256 colours. That graphics mode gave you two buffers of 64000 bytes, each byte representing a pixel on the screen. One buffer for drawing, one buffer that was displayed.

This very efficient mode, allowed you to easily plot pixes (each pixel being a byte). Because of the size of the screen, you could easily find the right pixel by bitshifting the Y coordinate and adding up X. Because of the two buffers, you could draw in the background, and swap a 'display pointer' when you wanted to draw the next frame.

But I admit, this was already a VGA mode. I haven't had much success with the really old graphics card. CGA was harder, and writing to the Hercules Graphics Adapter was really cumbersome and I never got the hang of it.

Here you can find a couple of old DOS games including source (none of them are mine): http://www.classicdosgames.com/misc/source.html

GolezTrol
  • 114,394
  • 18
  • 182
  • 210
  • If you have a computer with ISA, but which can run Linux, you can code for Hercules from Linux even. :) X11 even supports Hercules. Of course finding monitors these days is a problem. :) – Prof. Falken Sep 18 '11 at 10:03
  • 1
    Even though VGA hardware had 256K of RAM, that memory is organized as four 64K banks and mode 13h is limited to using one of them. There are a couple of other 320-dot modes (320x200 or 320x240), sometimes called "mode X", in which each group of four pixels is represented by one byte from each bank. For some kinds of rendering tasks that layout is a real bother to work with, but for others it works out very well, since display hardware includes a function to write a group of four pixels as a unit with either a uniform value, or with values read from another group of four. – supercat Sep 11 '14 at 13:23