
                  -====> DoomAttack 0.6 by Georg Steger <====-


DoomAttack is another port of Doom for the Amiga. Creating an Amiga version
was very easy, because ID Software have released the original source code
as public domain and therefore it's also 100% legal.


What's so special about *this* version:
=======================================

o Several routines have been rewritten in assembler

o The game is running fast even on my AGA 68030/50 68882/50 and will probably
  fly on 68040/68060 + GFX-Board (if it works :-?)

o The low detail mode routines (2 x 1) were fixed and the game is *very*
  playable in full screen on a 68030/50 machine

o You can use Keyboard, Mouse and Joystick

o You can make a IFF screenshot from inside the game.

o Three versions: one for 68030, one for 68040 (not tested) and one for
  68060 (not tested!)

o Network playing does *NOT* work!!!!!!!!!!!!


System Requirements:
====================

  o Amiga OS 3.0

  o 68030 (it's very probably also working on 68020) - FPU is *not* required
  
  o some memory (8 MB FAST is probably the minimum)
  
  o AGA or GfxBoard (not tested)

  o There are three versions of the executable. One compiled for computers
    with 68030m, one for 68040 machines and one for computers with 68060,
    which I hope should not contain any of the commands that on this CPU
    have to be emulated (I had to do this by hand, as GCC (or at least the
    version I'm using) does not have a 'm68060' switch.

In order to use DoomAttack you first of all need a WAD file. I have only
tested DoomAttack with a Shareware WAD (you can get one from the ID Soft-
ware Web site: http://www.idsoftware.com), that's one with the suffix
".wad". Anyway it will probably work with registered and commercial WAD
files, too.

Tip for italian users (and others, too!?):
==========================================

There's a PC Doom Demo archive in many of the CDs of Enigma Amiga Run. Just
have a look at the "ONLYPC" directory. There you should find a file called
"doom1_2.zip". There's a unzip utility for the Amiga on Aminet: "util/arc/
Unzip512x.lha". Simply type: "unzip doom1_2.zip" and the archive will be ex-
tracted to the current directory. After unzipping you will find several
files in the current directory, "DOOM1_2S.1" and "DOOM1_2_S.2" are the ones
containing the WAD file. The format of the two files seems to be ICE, but
inside there is a normal LHA file, therefore you can extract it diretly
with the Amiga. As the ICE file is split you first have to join the two
parts together: "join DOOM1_2S.1 DOOM1_2S.2 to DOOM.LHA". After that you
can use lha: "lha x DOOM.LHA". The warning "skipping extraneous/corrupt
data" can be ignored.


Installation:
=============

Either use the installation script (recommended!!) or do it by hand:

1) Copy the right executable to the directory containing the WAD file. 

2) Create a directory called "c2p" in the same directory and copy the
   chunky2planar routine (which is called "c2p", too) there.

3) DoomAttack needs to have the environment variable DOOMHOME (not HOME!
   I have changed) set to the directory containing the WAD file.

4) In order to speed up disk loading use "AddBuffers <disk:> <buffers>".
   One buffer is about 500 bytes. I suggest you to use a value between
   100 and 500, for example: "AddBuffers WORK: 200"

5) Before starting DoomAttack you should set the stack size to 150000,
   which I guess should be enough.

6) VERY IMPORTANT: If you want DoomAttack to run on GFX Board screen you
   must start it with the option "-rtg" (see below), because I actually
   don't know how to find out, whether a Screen mode is native or not!!!!
   DoomAttack has not been tested on GFX-Boards, so it might not work. In
   this case try a native Amiga mode.


It's also possible to start DoomAttack from Workbench by double-clicking
the DoomAttack_ClickMe icon, first, which sets DOOMHOME and increases the
buffers. (Don't double-click it more than once per boot!!)

Anyway Doom eats a lot of memory and therefore it might be better booting
"with no Startup Sequence". To simplify the starting in this case you can
copy the "DoomAttack_Start" file to S: so that after having booted without
Startup Sequence it will be enough typing "S:DoomAttack_Start" to get the
game running. "DoomAttack_Start" sets the DOOMHOME environment variable,
adds some buffers to "Work:" (change this if the volume containing the Doom
files has another name on your computer!!!!), sets the stack to 100000 and
starts DoomAttack.

You can do this from Workbench, too, by simply double-clicking the Doom-
Attack_BootStart icon and resetting the computer when the requester telling
you to do so, appears. If you are interested in how this work: When you
double-click DoomAttack_BootStart the script with the same name will be
executed. The scripts mounts a small RAD disk (called DoomRAD:) and creates
a startup-sequence for it. The RAD disk has the highest boot priority and
therefore autobooting will happen from there, when you reset the computer.
The startup-sequence created by the script (BTW: to set DoomAttack options
edit the "setenv DOOMOPTIONS" line in this script) sets up some assigns,
starts the monitor drivers, sets the environment variable DOOMHOME, in-
creases the stack size, kills the small RAD disk and then starts DoomAttack.


Options:
========

You can set them with shell arguments (if you use DoomAttack_Start script
you must edit this file) or with tooltypes (only if you start DoomAttack
from Workbench). The '-' char is part of the option and tooltypes must
contain it, too!

-rtg		       IF you want to use a GFX-Board screenmode you have
                       to specify this option. If you do so DoomAttack will
                       render the framebuffer with either WritePixelArray8
                       or WriteChunkyPixels depending on whether you are
                       running OS3.1 or not.


-fps                   Displays the frames per seconds in the upper left
                       corner of the screen. Doesn't work very well in
                       "-rtg" (or single buffered) mode - the display
                       flashes ...

          
-rendercontrol         Can be used together with "-fps" to see how fast the
		       rendering would be, if there was no need to chunky2-
		       planar (or copy) from the framebuffer to the screen
		       bitmap. You can switch the FrameBuffer-to-Screen
		       routine on and off with CAPS LOCK. If CAPS LOCK is
		       on, there will no screen update, but you will still
		       see the fps.


-nodoublebuffer        Switches double-buffering off. Double-buffering does
                       actually only work with native screens (i.e. if you
                       don't use the "-rtg" option), because I don't know
                       how to do double-buffering on GFX-Boards.


-zonesize              By default DoomAttack tries to alloc one block of 6
                       MByte, which will be freed only when you quit Doom.
                       If allocation fails, it decreases the size by 50
                       KByte, again and again, until allocation succeds.
                       With -zonesize you can tell DoomAttack how many
                       KBytes (!!!!! not MBytes) it shall try to alloc
                       first. You should not go under 3000 KByte, although
                       I'm not quite sure as this probably depends on the
                       WAD file (I've only tried one).

-displayid	       Supply the (numeric) id of the screenmode you want to
                       use. You can specify it in hexadecimal format. For
                       example "0x21000" would be PAL:Lowres. You usually
                       don't have to use this option because you can force
                       a Screenmode requester to pop up by holding down
                       one of the SHIFT keys when starting DoomAttack (the
                       requester will not appear immediately). The screen-
                       mode will then saved to the config file ".doomrc"
                       when quitting Doom. BTW: You can edit ".doomrc" with
                       a normal Editor.


-c2proutine	       Specify an alternative chunky2planar routine. By
                       default DoomAttack tries to load "PROGDIR:c2p/c2p",
                       and that's actually the only one available, so this
                       option can't actually be used.

                       BTW: If DoomAttack couldn't load the c2proutine it
                            will automatically switch to "-rtg" more.
                            
                            At the end of all Init-Routines DoomAttack will
                            display in the output window, whether it is
                            running in "-rtg" or in "chunky2planar" mode.


-forcedemo             Forces to run the demo even if it "is from another
                       game"


-norangecheck          There are some bugs in the rendering engine (= in the
                       original source code) which sometimes can make it
                       try to  render outside the framebuffer (=> can cause
                       crash). Therefore by default there are range checks
                       in the routines to avoid this. This might slow down
                       overall speed a little bit. With this option you can
                       replace the render routines with faster ones not
                       containing the mentioned range checks, at your own
                       risk!! There will probably be only a very small speed
                       increase, therefore I think it's better not using
                       this option!


-nosound               Disable sound. Actually only sound effects (no music)
                       are working and this anyway slows down the game a 
                       little bit.


-coolmap               You will get a rotating map, which makes orientation
                       a lot easier. 


-joypad                Allows you to use a CD32 Joypad. The routines are
                       based completely on ADoom from Peter McGavin and
                       have not been tested!


Controls
========

CURSOR LEFT            rotate left
MOUSE LEFT
JOYSTICK LEFT     

CURSOR RIGHT           rotate right
MOUSE RIGHT
JOYSTICK RIGHT

CURSOR UP              walk
MOUSE UP
JOYSTICK UP
RIGHT MOUSE BUTTON

CURSOR DOWN            go back
MOUSE DOWN
JOYSTICK DOWN

CONTROL                shoot
JOYSTICK FIRE
LEFT MOUSE BUTTON

SHIFT                  run

ALT
MIDDLE MOUSE BUTTON    strafe

RETURN                 show last message in game/ "enter" in menus

SPACE
MMB DOUBLE CLICK       use / open door

NUMERICPAD *           gamma correction

HELP                   pause game

` (above TAB)          save IFF screenshot - standard name DOOMxx.IFF

SHIFT + ` (above TAB)  save IFF screenshot - ask for name with ASL requester

F5                     switch low detail (2 x 1 Pixels) on/off

+                      increase window size / map zoom

-                      decrease window size / map zoom



FINAL NOTES:
============

o The game from time to time crashes at exit. There seem to be a lot of
  bugs in the original source code. I have fixed some but there are
  still crashes. Reboot your computer after quitting DoomAttack. I don't
  take any responsibility for any damage that occures. You have been
  warned!!!
  
o The actual c2p routine is optimized for 020/030 (no blitter) and is based
  on a routine I found in the "rtgmaster" archive. If someone wants to send
  me faster ones, or routines optimized for 68040/60 ...

  The c2p routine could be optimized a lot as it actually chunky2planars
  always the whole screen and always in 1 x 1, even if you have shrunk the
  display window to it's minimum size.
  
  BTW: The c2proutine may be destructive

o If Joystick control or Mouse control does not work, load ".doomrc" into
  an editor and set "usemouse"/"usejoystick" to 1. You can also disable
  them by setting "usemouse" and/or "usejoystick" to 0, which can speed
  up the game a little bit.

o The FPS display ("-fps" option) slows down the game a little bit.

o Native Amiga screenmodes with 30 kHz slow down the game considerably. If
  possible use a normal 15 kHz mode.

o Expect new and faster versions with even more routines converted to
  assembler, soon!!!

o Don't expect networking to be supported in future versions. I don't know
  anything about it.
  
o I could implement MOD playing routines, if someone sends me a cool and
  fast (!) routine and one that, if possible, uses the audio.device (well,
  unless this is too slow).
  
o Can someone tell me how to check whether a certain screenmode is native
  (i.e. planar planes which have to be in chip memory) or from a GFX-
  Board. I've heard that checking the Flag DIPF_IS_FOREIGN is not working
  with all GFX boards.

o And how do I do fast double buffering on GFX-Boards? I've heard something
  about ScrollViewPort(). Remember: I don't have a GFX-Board and there does
  not seem to be anyone here in South Tyrol, having one :( Therefore you
  have to explain me *everything*.

o I have removed the checks for divison by zero in many places, where I
  think they are not necessary. Anyway I was not always 100% sure, so if
  you get a 80000005 GURU let me know! I have been reported by several
  users that V0.5 indeed produced divide by zero expections. Therefore
  I have re-written the division by zero checks in some places. If you
  still get GURUS with this version let me know and don't forget to
  specify in which occasion the GURU happened. I have also attached a
  small utility called Div0Killer, which prevents software failures to
  appear if a division by zero occures. You can start it somewhere in
  the startup-sequence with "run <>NIL: Div0Killer".
  
  You can find "Div0Killer" in the "Tools" directory. It has no icon so
  select "View all icons" from the Workbench menu.
  
  WARNING: The usage of Div0Killer might result in unexpected behaviour,
           not only of DoomAttack, but of other programs too, if they make
           a division by zero and continue their work, just like if nothing
           had happened. Avoid it's usage if possible!


===========================================================================
Send comments, suggestions, bug reports (in German (preferred), Italian or
English) to (Sorry if I don't reply every single EMail, but I'm getting
far too many of them, so that I probably will only answer the ones asking
questions with a possible delay of some days!):

Georg Steger, Hochlercher 30, I-39030 St. Johann/Ahrntal
EMail: steger@pass.dnet.it
