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