Description
-----------
Deadline 2 is a multi player tank war / racing game for Linux and X11.
Computers on a LAN can participate in a game, and two players can play
on one computer.

The sourcecode is modular and less than 2000 lines, so if you want to learn
some of the technical details of game programming (or hack something), this
may be a good place to start. However, if you dislike pointers, stay away.

Requirements
------------
Linux, the game and X11.

if you want to edit maps : xfig.
if you want to create textures : netpbm.
if you want to modify it : g++, XFree86-devel.

Usage tips
----------
Run deadline2play for a simple 1 computer, 2 player game. Give focus to
  (keep the mouse inside) the right hand window.
Run "deadline" (no parameters) on one computer. People across the network can
  join with "deadline name.of.server.com". The server automatically downloads
  the map and the graphics to the clients, so only the executable file is
  needed. You can FTP it or run it directly over NFS.
Run deadline with -help to see what other options can be used.
Edit .dlrc (should be in /usr/lib/games) and place it in your home
  directory to redefine the keys (the xev program may help with this).

Put this in you fvwmxxx.rc file, so that screen uses the palette of the game
  while playing, even if you take the mouse out of the window :
  ColormapFocus FollowsFocus
  Style "*" SloppyFocus

If you want to edit the map type "xfig /usr/lib/games/dl.fig". Closed
  polygons is used to create walls with. The game will complain if they
  are not closed. They must also be convex, meaning all the corners must be
  less than 180 degrees. You must use multiple convex polys to make larger
  non-convex (concave) objects. Text is used to indicate special places :
  S   : a starting point.
  H   : health. Not implemented.
  W   : weapon. Not implemented.
  A,B : the line a player must cross to complete a lap. "A" must be on his
        left, and "B" on his right, to be credited with a lap. It is best to
        put "A" and "B" inside (different) walls.
  Color indicates the texture of the wall.

History
-------
The original "Deadline" was written by Frans van den Bergh and others as
their 3rd year computer science project. It used Java and was very
experimental.

Nic Roets wrote "Deadline 2" from April 14, 1998 to some time later that
year. Frans van den Bergh created the new textures using POV-RAY.

The longest game was 1 hour (about 80 frags each).

The main reasons for writing it were:
1. To write some code I can use later.
2. To learn TCP networking a better, and test the synchronization idea.
3. To learn low level X11 a little better.
4. To reimplement triangle mapping functions in a much cleaner way.
5. To show that it is only necessary to optimize one part of a program, or
   if the profiler / experimentation suggests it.
6. To test the idea that the shorter a program the better. I try to use each
   assumption only once, so that changing it will not be a major task.
7. To (re)invent collision detection. (Entities moving in straight lines,
   without rotation is quite easy, because the time of collision can be
   calculated directly) Since I allowed for the more complex situation where
   entities can rotate, I decided to use a binary search to find the first
   collisionless time.
8. To show that Linux utilities can enhance productivity.
9. To prevent boredom during death matches.

Remarks:
First I used simple C code, and got about 30 frames per second (fps) (at 320
  by 240) on a simple image on my 120 Mhz Pentium. Then I enabled MIT-SHM
  and got 50 fps. Then I used assembly (machine) language under gcc and got
  about 100 fps. Then I saw that with a lot of bullets flying around CPU
  usage went up to 60 %, so I implemented bounding boxes (not a binary
  search partition, which is the next step) and usage fell to 20 %.

The synchronizer idea really paid off when the need to use one keyboard/
  display for two games arose. No planning was initially done for this, but
  implementation was quite easy.

Blocking reads does not wait for the read to complete ! What it boils down
  to is that a program which happily used a stdin as a blocking stream for
  input cannot be given a socket. See ReadAll in synchronizer.h.

