Short: Amiga port of DOOM v1.1 Author: Peter McGavin (p.mcgavin@irl.cri.nz) Uploader: Peter McGavin (p.mcgavin@irl.cri.nz) Type: game/shoot Action: NoStart ADoom 1.1 20 Feb 1998 ---------- This archive contains an Amiga port of DOOM, compiled as directly as possible from ID Software's Linux DOOM source code. On 26th Dec 1997 I learnt that ID Software released the source code of DOOM and made it available by ftp. So I immediately downloaded it and tried compiling it with SAS/C 6.58 for the Amiga. This archive represents my results after about 25 evenings and 6 days. I am now back to my full time job and only have time to work on ADoom in spare evenings and weekends. You can get the original ID Software Linux DOOM source from: ftp://ftp.cdrom.com/pub/idgames/idstuff/source/doomsrc.zip Source code of ADoom, which includes all my changes, is in a separate archive on Aminet. ADoom is OS-friendly and multitasks. ADoom puts up an ASL requester for the ScreenMode. Sound effects, ECS support and 68040-optimised C2P are included since version 0.1. Version 0.4 adds 68020-optimised blitter-assisted C2P and double-buffering. Version 0.5 adds music. Version 0.6 adds 68030-optimised blitter-assisted C2P. From version 1.0 you can run ADoom in higher display resolutions than 320x200. For examples, 320x256, 640x480 and 1024x768 all work. This is an enhancement which is not available in the original PC DOOM. Low detail mode (2x1), which can provide a significant speedup on 68030, is available and working from ADoom version 0.6. From version 1.0, ADoom supports many features of DeHackEd, a PC utility which can patch many of DOOM's internal tables according to a .DEH format configuration file. ADoom can read .DEH format files and patch the same internal tables. You can use a joystick in the 2nd gameport from v0.2. AmiTCP network support was added in v0.2, but so far is rather unstable and slow, even with a direct ethernet connection between 2 fast Amigas. Experimental support for a raw protocol over a null-modem cable and for ethernet IPX were added in v0.9. Thanks to several people who sent me icons for ADoom. I put them in the more_icons subdirectory in this archive. REQUIREMENTS: ------------- A 68020+ Amiga running at least OS 3.0, with at least about 4 Mb of fastmem. ADoom works with gfx-cards, AGA or ECS (EHB) using C2P. Unless you have 68040+, you should have an ECS or AGA Denise chip or a gfx-card. Theoretically the combination of 68020 or 68030 with OCS won't work because OCS can't do long blits used by the 020/030 C2P routine. On the other hand, two different people wrote to me that ADoom worked just fine for them with 68020/30 + OCS --- weird. A Zorro3 (or faster) graphics card, CyberGraphics and 68040+ are recommended. A 68040+ and ethernet are recommended for networking. -------------------------------------------------------------------- | YOU NEED TO GET A WAD FILE THAT WORKS WITH LINUX DOOM AND PUT IT | | IN THE SAME DIRECTORY AS ADOOM. | -------------------------------------------------------------------- Otherwise you get the message: "Error: W_InitFiles: no files found" WAD files typically have names like DOOM1.WAD and DOOM2.WAD. Not all WAD files work. It seems that some older WAD files are rejected because they leave out some information that ADoom requires. In particular, early registered DOOM WADs do not work. I think these same WAD files fail to work in Linux DOOM. It is possible to upgrade at least some old WAD files using freely available patches from ftp://ftp.idsoftware.com/idstuff/doom/. However you need a PC to apply the patches. (Well it would probably work in PC-Task, but the upgrade procedure is slow on a Pentium.) I'm told that early registered DOOM WADs can be upgraded to DOOM 1.9 and then to Ultimate DOOM, both of which work in ADoom. DOOM1.WAD from "http://surf.to/adoom/" works fine, as should the latest shareware WADs from ID Software's WWW site. I was told that at least some Macintosh WADs work too, as does the registered DOOM II WAD. One person told me that any "Doom2 PWAD" works, whatever that is. A couple of people said they got the 4th episode of Ultimate DOOM to work by changing the name of the WAD file to doomu.wad. Many people have asked me which WADs work and which don't, but I'm afraid the above is about all I know at the moment. To play third-party WADs with non-standard names, you must have a *registered* WAD in the same directory as well. Then you should start ADoom with the -file option specifying the third-party WAD, e.g: ADoom -file Satan666.wad The -file option doesn't work if you only have a shareware WAD. If you want to apply several patch WADs at once, put them all after a single -file argument, e.g, ADoom -file patch1.wad patch2.wad patch3.wad I use a stack size of 150000 bytes, but that's probably overkill. I don't know what the stack requirements really are yet. It's probably less than 4096 bytes (because it worked OK from the icon when I forgot to set the stacksize). An FPU is neither required nor used (except on 68060). An MMU is neither required nor used (except -mmu option on 68040/68060). HELP, I'M SWAMPED WITH E-MAIL: ------------------------------ Thanks for all your e-mails about ADoom. I enjoy reading them. However please note that I received upwards of 40 messages per day for several days. Now I'm back to my full-time job, so I only get time to work on ADoom and catch up on e-mail on my spare evenings and weekends. I apologise in advance if you don't receive a reply. Yes I know the Descent source is out. At least 14 people told me. Sorry I don't have time to port it right now. There are a couple of ports done by other people already... And no, ADoom wouldn't be any faster if it used the FPU, because DOOM doesn't do any floating-point arithmetic... SPEEDING UP DISK LOADING: ------------------------- Several people reported ADoom taking 10 minutes or more to load the WAD file at the start of the game. Really it should only take 10 or 20 seconds or so. If you find it's too slow, try adding more disk buffers with the AmigaDOS ADDBUFFERS command. Adding 300 buffers can vastly increase the disk-loading speed. One person recommended DynamiCache instead, but I haven't tried that. There are more hints on this topic in the UserHints.txt file. RESOLUTION: ----------- ADoom works by default in 320x200 resolution. From version 1.0 you can select higher resolutions with the -width and -height options or the WIDTH and HEIGHT icon tooltypes. For example, the command-line: ADoom -width 640 -height 480 runs ADoom in 640x480 resolution. When the ScreenMode requester comes up, you should then select a 640x480 mode. 640x480 is highly detailed, but runs only slowly unless you have a 68060. You should always choose a width that is a multiple of 64 (AGA) or 32 (ECS or gfx-card). In any resolution you can flip between high-detail (1x1) and low-detail (2x1) modes during play in the Options Menu or by pressing F5. The maximum resolution supported is 1600x1280, which shows incredible detail but runs like molasses even on a 68060. Note that 640x400 in ADoom is different to 640x400 in MacDOOM and ShapeShifter. ADoom in 640x400 uses 1x1 (or 2x1 in low detail) pixels. MacDOOM in ShapeShifter uses 2x2 pixels. MUSIC: ------ ADoom supports music based on .MUS-player source code sent to me by Joseph Fenton of MicroCode Solutions. Music requires an extra file not included in the archive because of its size. You should download ADoom_Instr.lha from Aminet and unpack the file MIDI_Instruments into your ADoom program directory. Music is disabled by default because the MIDI_Instruments file is distributed separately. Once you have the MIDI_Instruments file, enable music with the -music option or MUSIC tooltype. Joe greatly improved the MIDI_Instruments file over the version supplied with ADoom 0.5. Joe says "You might want to give my brother Michael some credit as well, he wrote the event handling and the Player Interface code; I did the PlayNote and interrupt audio engine and instruments". Enabling music adds to the atmosphere, but it also slows the game down and leaves only 2 channels for sound effects. Without the music you get 4 channels for sound effects. From version 0.6 you can disable all sound effects with -nosfx or the NOSFX icon tooltype. That leaves audio channels free so you can use your own music player in the background. From version 0.8, the music volume is lowered and clicks and pops eliminated. KEYBOARD: --------- Most keys are mapped the same as on a PC. However the Amiga doesn't have F11, F12 and PAUSE keys. On the Amiga, press '[' for F11, ']' for F12 and HELP for PAUSE. Many people complained about the keyboard layout, especially CTRL for FIRE. It's possible to customise the keymap in .doomrc --- see UserHints.txt. In version 0.6 I changed the Right-Amiga key to send the same code as CTRL (was the same as Right-Alt in 0.5) and I disabled the Left-Amiga key so screen-flipping doesn't set things off. Someone just pointed out this wasn't such a good idea. AmigaOS uses Right-Amiga and arrows together for moving the mouse pointer when you don't have a mouse. From version 1.0 ADoom is sensitive to international keyboards. I am unable to test this, however. From version 1.0, you can use the numeric keypad for controlling your player by default. The keypad keys 4,5,6 & 8 control movement and direction. The keypad keys 1,3,7 & 9 can be used for strafe. (These controls can be overridden in .doomrc.) MOUSE: ------ Mouse support was added in version 0.3, but it is disabled by default. That's because it slows the game down. To enable the mouse, start ADoom with the -mouse option, or use the MOUSE icon tooltype. CD32 JOYPAD: ------------ Gabry (ggreco@iol.it) emailed me some CD32 joypad handling code. It is disabled by default because it requires lowlevel.library. If you want to try it, use the -joypad option or JOYPAD tooltype. SEGA CONTROLLER: ---------------- From version 0.9, I added Joe Fenton's SEGA controller code. To enable it, use the -sega3 or -sega6 options or SEGA3 or SEGA6 tooltype. I have not been able to test this code. The rest of this section was written by Joseph Fenton : There are two new flags: -sega3 look for a 3 button Sega controller. -sega6 look for a 6 button Sega controller; you MUST use this on a Sega 6 button controller or it won't work correctly. The button mapping is as follows: Start = Space (Action) A = Strafe Right B = Fire C = Strafe Left On the 6 button controller you also get Mode = Esc (Menu) X = Return (Enter/Show last message) Y = Shift (Fast/Run) Z = Tab (Map on/off) A Sega Genesis controller may be use on the Amiga as long as you swap lines 5 & 7, and put a 470 ohm resistor between lines 5 & 7. The controller plug pinout is: 1 2 3 4 5 6 7 8 9 The best way to switch the lines is to open up the controller and change them on the circuit card. Note: doing this will make the controller incompatible with SEGA equipment; if you make the changes, you are on your own; I will not be held responsible for any damage incurred by performing the above procedure. If you aren't comfortable doing your own conversion and don't know anyone who can help, DON'T TRY IT! Get yourself a CD32 joypad. This is ONLY for people who know what they are doing and want the range of controllers available for SEGA equipment. SAVING THE SCREENMODE: ---------------------- If you don't like the ScreenMode requester every time ADoom runs, you can save your favourite ScreenMode as an icon tooltype. First, watch the output of ADoom when it starts up and note the DisplayID of the ScreenMode you selected. It will be something like $40420000. Now click the ADoom icon once and select "Information..." from the Icons menu. Click on NEW and type in: SCREENMODE=$40420000 replacing $40420000 with the DisplayID you noted. Delete any other SCREENMODE tooltypes. Finally, click SAVE, and start ADoom again. Alternatively, use -screenmode on the command line, e.g, ADoom -screenmode $40420000 MEMORY: ------- ADoom has a built-in disk caching system that automatically tries to keep the most important game information in memory, minimising disk accesses. ADoom automatically allocates a 6 Mb block of memory for the cache if it can, otherwise it tries to allocate the biggest block it can, bigger than 2 Mb, while still leaving 2 Mb of fastmem free. You can override ADoom's default cache size determination algorithm with "-heapsize " option or "HEAPSIZE=" icon tooltype, where is in kilobytes. If you set the heapsize to less than about 2000 kb, ADoom might fail to load certain WADs. The shareware WAD works with "-heapsize 1000". Setting the heapsize is useful if you only have a small amount of memory, or if you want to set aside memory for an enormous cache. The smaller the heapsize, the more ADoom will access disk during play. If you have only 4 Mb of fastmem (or less), try "-heapsize 2000" or even "-heapsize 1000". FPS COUNTER: ------------ From version 0.8 you can use the -fps option of FPS icon tooltype to put a continuously updated frames/second counter in the top-left corner. From version 0.9 it is in the top-right corner. Note that this slows down ADoom slightly. The official way to measure FPS is to use the shareware doom1.wad, high detail, 2 steps down from max window size, "Adoom -mmu -forcedemo -timedemo demo3" after a clean reboot and SetPatch, then apply the formula: FPS = (gameticks / realticks) * 35 By this method, speeds in excess of 31 frames per second have been reported for ADoom version 0.7 on 68060 Amigas with CyberGraphX. See http://www.balldesi.demon.co.uk/ for the latest speed results of various Amiga DOOM ports. ROTATEMAP AND MAPONHU: ---------------------- Cyril Deble sent me some patches to make the automap display on the main 3d view and rotate like in Alien Breed 3D. From ADoom version 0.8 you can use two command lines/icon options -maponhu : map on headup -rotatemap : automap rotate Cyril warns: "A small bug accurs when you use a non full screen view with the automap the border are not refreshed as the border is buffered... You have just to change the clipping area of the automap to make it work ok. "I don't get too much into the code and i don t have time to do any further change hope it will be usefull for something... It's rather nice for me to include it into ADoom and i have noticed no slowdown while the map is on the 3D view... My config is 060/AGA The bug which didn't rotate "markers" with the map should be fixed in version 0.9. DEHACKED: --------- DeHackEd is a PC utility which patches DOOM's internal tables according to a .DEH format configuration file. It can, for examples, change the attributes of barrels so they float and chase you, make corpses explode when you shoot them, change the speed and fire-rate of projectiles, make all enemies look alike, and so on. Patch WADs (used with -file) differ from .DEH files, in that patch WADs patch a registered WAD file, whereas .DEH files patch the DOOM program itself. Cyril Deble sent me some source code for parsing .DEH format files which I included in ADoom. Once you have a .DEH format file, usage is: ADoom -deh .DEH patches are applied to the ADoom program in memory, not permanently on disk. There are many .DEH format files in the public domain. I put some samples in the deh subdirectory. Please note that not all features of DeHackEd are supported in ADoom. NETWORKING: ----------- ADoom 0.9 supports 3 different network protocols: TCP/IP, IPX and raw null-modem. Unfortunately ADoom generates a vast amount of network traffic and loads both the network and the CPU. I recommend at least a 68040 for networking. A fast connection, such as ethernet, helps a lot too. One slow machine in the network game slows everyone down. There seems to be a problem getting past the first level of DOOM2 in network mode unless you specify -deathmatch. TCP/IP: ------- AmiTCP networking in ADoom is based on the Linux DOOM source code. It works between Amigas and also with Linux PCs using TCP/IP on a fast network. You need either AmiTCP or Miami on your Amiga for it to work. Make sure you are using a recent version of AmiTCP or Miami. Fast Amigas and a fast connection help a lot too. It's best over ethernet and OK over AmigaLink. It works over a serial line with SLIP or PPP too, but people with 68030s reported unplayably poor performance. TCP/IP does not work to PCs running MSDOS or Win95, unless perhaps you can find a PC version of DOOM compiled from the Linux source code which supports TCP/IP. Several people told me Win95Doom TCP/IP does not work with ADoom. To start ADoom across 2 computers called fred and bob, say: 1: Make certain both computers are using identical WAD files; 2: Make certain you can PING fred from bob and vice versa; 3: On bob, enter: "ADoom -net 1 fred" 4: On fred, enter: "ADoom -net 2 bob" If there are 3 computers, called fred, bob and sue, say: 1: Make certain all 3 computers are using identical WAD files; 2: Make certain you can PING between all computers by name; 3: On bob, enter: "ADoom -net 1 fred sue" 4: On fred, enter: "ADoom -net 2 bob sue" 5: On sue, enter: "ADoom -net 3 fred bob" It's normal for screens to go blank sometimes during the startup phase. On Linux I used DOOM compiled from the source code available from: ftp://ftp.cdrom.com/pub/idgames/idstuff/source/doomsrc.zip I don't know whether other Linux DOOM implementations are compatible. So far I have tested up to 3 computers. The code is pretty untested and your mileage may vary. IPX: ---- IPX is the ethernet protocol used by MSDOS versions of DOOM. ADoom uses G.J.Peltenburg's amipx.library version 1.1 or higher for IPX. You can get this library from Aminet. After several evenings of struggling with the library and with checksums and big-endian/little-endian problems and with version number problems, the protocol finally seems to work, sort of... Unfortunately I did not foresee another problem. The PC version of the DOOM program I've tried so far does not exactly match Linux DOOM, even when using exactly the same WAD file. In my experience, the game often gets out of sync (consistency failure) or quits unexpectedly. So far I've only used DOOM2 version 1.666 on the PC. Perhaps version 1.9 would work better, because that's the PC version recommended for net-play with MacDOOM. Between 2 fast Amigas, ADoom with IPX works reasonably well using a2065.device. Hopefully it also works using ariadne.device and other Sana2 ethernet devices. First you should install G.J.Peltenburg's amipx.library version 1.1 or higher (from Aminet) and configure your Network number, Node, Device driver, Unit number and Frame Type in amipx_prefs. I use the Frame Type "Ethernet 802.2" and just set everything else to 0. Note that you need amipx.library at least version 1.1. Version 1.0 doesn't work. (Well, v1.0 might work with ariadne.device...) The syntax for starting ADoom with IPX is: ADoom -netipx For example: ADoom -netipx 2 ADoom automatically waits until the number of nodes specified are found on the local ethernet, then starts the game. You should all specify the same number of nodes and you should all use the same WAD files and other options. So far I have tested up to 2 Amigas and 1 PC all at once. The code is pretty untested and your mileage may vary. If you try IPX between an Amiga and a PC, there are 2 more options you MUST know about. The -pcchecksum option tells ADoom to calculate net packet checksums the same way the PC version does. By default, ADoom calculates net packet checksums the same way Linux DOOM does, which is different. (Linux DOOM just sets the net packet checksum to 0.) If you don't use -pcchecksum, the PC will reject and ignore (nearly) all game packets. The -forceversion option fools a PC into thinking you are running a particular version of DOOM. I use -forceversion 106 with DOOM2 version 1.666, for example. The default is -forceversion 110 for version 1.10. PC DOOM rejects any DOOM program that identifies itself as a different version number. Sorry I don't know an easy way of working out what number you need after -forceversion to impersonate a particular version of PC DOOM. Try -forceversion 109 with DOOM2 version 1.9, perhaps. I'm very interested to know your experiences with ADoom between PCs and Amigas using IPX. I'm told ADoom works with MacDOOM over IPX too, by the way. Thanks to G.J.Peltenburg for sending me the freely available IPX support source code from ID Software's ftp site, after modifying it for his amipx.library. DIRECT NULL-MODEM: ------------------ So many people requested a raw null-modem protocol that I sat down and implemented it for version 0.9. Well it was mainly an exercise to prepare myself for IPX. It only works between 2 Amigas with the serial ports connected by a null-modem cable. It uses 7-wire CTS/RTS handshaking, so a simple 3-conductor cable won't work. I'm pretty sure null-modem won't work between an Amiga and a PC, because I made no attempt to match the protocol. In other words, it requires 2 Amigas. I suppose it would work between 2 Amigas over a telephone line with modems. You would need to manually dial and make the connection first. Then you would need to shutdown the connection program before starting ADoom. The Hayes modem command at&d0 might be useful for leaving the modem on-line between shutting down the connection program and starting ADoom. The ADoom syntax is: ADoom -netserial For example, you could enter: ADoom -netserial 1 serial.device 0 38400 on one Amiga and ADoom -netserial 2 serial.device 0 38400 on the other. One of the Amigas is always node 1 and the other one is always node 2. It is not necessary to use serial.device. In fact artser.device or 8n1.device, if you have them, probably work more reliably or at higher speeds than serial.device. I think you should use the highest speed that both Amigas cope with. My experience is that 38400 is about the limit for 68030 Amigas. My 68040 WarpEngine works OK with artser.device at 57600. If you set the speed too high, ADoom will probably behave erratically or lock-up after a while. If you set the speed too low, I suspect the game will run only very slowly. The game tends to slow right down when there are lots of active monsters anyway. Try -deathmatch -nomonsters perhaps. I recommend you start ADoom on node 2 first. That's because node 2 is the "listener" during the setup phase. If you start ADoom on node 1 first, ADoom on node 2 is likely to open serial.device while node 1 is part way through sending a setup packet. That could lead to synchronisation problems and possible lockups. CONSISTENCY FAILURE: -------------------- Several people reported their net games ended unexpectedly with a message like: "Error: consistency failure (24805 should be 24806)" What's going on is that DOOM calculates a kind of checksum of the game's status --- player and monster positions and that kind of thing --- and sends it to all the other players in every net packet. If all the programs and WADs are identical, then they all calculate exactly the same checksum. However, if someone is using a slightly different WAD version or an incompatible version of DOOM, then a monster might be one more pixel to the left, say, and the result is "consistency failure". The test is very precise. All net nodes must run compatible versions of DOOM and all must use exactly the same WAD file and game options. To be compatible, 2 versions of DOOM must provide exactly the same features. Furthermore, they must use exactly the same random number generator and they must round arithmetic calculations exactly the same way. I have to be careful adding new features to ADoom. For example, I can't use the random number generator for anything new, nor can I add any new features that might change player and monster positions. If I optimise anything, I can't make any approximations. Otherwise ADoom definitely won't work with PC DOOM any more. Please keep this in mind if you send me source code for inclusion in ADoom. (The ideal solution would be to compile DOOM for all different platforms, MSDOS, Win95, Mac, Linux, Amiga, PSX,... from a single source. Then new features can be added simultaneously on all platforms. Now there's a job for someone...) I suspect "consistency failure" might also happen if you get network errors, such as serial line overruns. Try lowering your serial line speed, and make sure hardware handshaking is working properly. Also, if you all specify -pcchecksum things might be more reliable. That's because the default Linux net packet checksum isn't really a checksum at all. It's always 0. So any errors in the net packet are not detected unless you all use -pcchecksum. (The net packet checksum is different to the consistency checksum.) MISCELLANEOUS NEW OPTIONS: -------------------------- Several new options were added in version 0.9. Each has a corresponding tooltype. -cpu force use of routines optimised for, e.g, 68060 -rtg forces single-buffering and WritePixelArray8() -native forces use of C2P routine (crashes if not planar) -ehb forces use of 6-bitplane extra-half-brite code -mousepointer leaves the mouse pointer on -forceversion send different version number to other net node(s) -pcchecksum calculate net packet checksums the PC way (not Linux) CHUNKY TO PLANAR: ----------------- For native screenmodes on 68040+, ADoom uses a CPU-only C2P routine. For EHB on 68040+ it also uses a comparison buffer. I timed it on my WarpEngine as being faster on average than a routine without a comparison buffer. The comparison buffer method is temporary until I can figure out some sort of list of dirty-bounding-boxes thingy. From version 0.4, ADoom in native Amiga modes (AGA and ECS) double-buffers. From version 0.4, ADoom uses a blitter-assisted C2P routine on 68020/30. The blitter does the latter half of the C2P conversion in chipmem while the 3D engine renders the next frame to fastmem. It also double-buffers --- a necessity for this approach. On a 50MHz 68030, C2P CPU-time is 3 times less than in version 0.3. Unfortunately it looks as if C2P is only a small fraction of total time anyway, maybe 10..15%. In version 0.6 I replaced the AGA 68030 C2P that did 2 CPU merges and 2 blitter passes with one based on Mikael Kalms' routine that does 3 cpu merges and 1 blitter pass. C2P for ECS (EHB) modes takes longer because there is an extra table lookup for each pixel. It converts 8-bit -> 6-bit. ADoom renders to fastmem and uses WriteChunkyPixels() or WritePixelArray8() on gfx-cards. Several people asked me to make a version which renders directly to the CyberGraphX framebuffer, like Trance's AmiDoom and RTGMaster. I started doing this, but didn't finish. I did some more work on it for ADoom version 1.0, but it's still not working properly. To try it with CyberGraphX, use the -directcgx option or DIRECTCGX icon tooltype. Double-buffering with -directcgx works properly now and eliminates the flicker. However I'm having major problems reading anything back from a CyberGraphX Window. ReadPixelArray8() from the non-displayed part of the Window seems to return junk. Is there a bug in cybergraphics.library? Similarly LockBitMapTags() followed by memcpy() from the base address seems to return junk. Is the GVP Spectrum 28/24 frame-buffer write-only? Anyway, the symptom with ADoom -directcgx is that the screen wipe at the start of each level makes a mess, but everything else seems to work. RENDERING: ---------- Version 0.5 uses fast column and span renderers by Aki Laukkanen. Aki supplied seperate 68060-optimised routines. These are selected if you have a 68060, provided you have SetPatch and 68060.library correctly installed. PICASSO96: ---------- I developed ADoom using CyberGraphX and I have not tested ADoom with Picasso96 graphics libraries. On the other hand, many users reported ADoom works just fine with Picasso96. A couple of people reported problems with the P96 1.34a update. See UserHints.txt. ZORRO-2 GFX-CARDS: ------------------ ADoom works with Zorro-2 graphics cards, but you will likely find that performance is slightly worse than in AGA modes. That's because the memory transfer speed of Zorro-2 is slower than 32-bit chipmem --- believe it or not. With a fast-enough CPU, ADoom uses the all the memory transfer bandwidth in both cases. That's in spite of converting chunky to planar at the same time in the case of AGA. That's also in spite of FAQs still arguing that planar is 8 times slower than chunky for texture-mapping. So choose an AGA mode for better performance. Or, better still, get a Zorro-3 (or faster) gfx-card, and the right buster chip for it. 68060: ------ Several people reported extremely poor performance on their 68060 systems, although that was mostly with ADoom versions before 0.5. If that happens to you, try using the FastExec (whatever that is) "SSP to FastMem" option. Several 68060 users told me that made a huge speed difference. Shaun Falkenberg (shaunf@box.net.au) suggests the equivalent option in MCP might be better because it saves a reboot on cold startup. OxyPatcher is yet another alternative. ADoom 0.5 uses 68060-specific fixed-point routines which don't use 64-bit MULS & DIVS on 68060. You must have SetPatch and 68060.library correctly installed for these faster routines to be selected. Version 0.6 uses the FPU for both fixed-point multiplies and divides on 68060. Version 0.5 used the FPU for fixed-point divides and 32-bit integer instructions for fixed-point multiplies on 68060. In version 0.6 I added the -mmu option and MMU icon tooltype to mark the chunky buffer and chip raster as "imprecise" using the MMU. I used Aki Laukkanen's MMU code for this. This may speed up ADoom on 68040+MMU and 68060+MMU systems slightly, by better scheduling memory accesses. LIMITATIONS: ------------ Play-tested for a few hours on an A3000 + WarpEngine + GVP Spectrum + Cybergraphics running OS3.1 and Enforcer, on which it seems to run very smoothly. Many people reported success with earlier versions of ADoom. I think I finally fixed all the crash on exit bugs. I think the teleport bug is fixed. Outstanding bugs possibly include problems with -record and -playdemo, problem using -timedemo without also -forcedemo, network problems and problems loading the original registered doom.wad. A couple of people reported crashes on exit with the -fps option in version 0.9. However bugs are becoming rarer these days. Hopefully I didn't introduce too many new ones in the latest version... Someone told me the mysterious "PNAMES not found" bug, reported by about half a dozen people, is still present in version 0.9, so it's probably still there in version 1.0 too. On the other hand, I can't reproduce this problem. I wonder if it might be a symptom of a corrupt WAD file. WORLD WIDE WEB SITES: --------------------- There is no official ADoom Web page. Sorry, but I just haven't got time to support one. However I'm quite happy for anyone to make ADoom available from their page. There are several web pages specialising in DOOM for the Amiga. Some good ones are: http://adoom.ml.org/ has about 6 other Amiga DOOM ports http://surf.to/adoom/ fast mirror of http://adoom.ml.org/ http://homepages.which.net/~bartlett/ the Amiga DOOM Bible http://hem2.passagen.se/sids/adoom/ an ADoom-only page http://www.balldesi.demon.co.uk/ for the latest speed benchmarks http://www.boehme.demon.co.uk/aliens.html some tested 3rd party WADs http://fiction.pb.owl.de/~frank/ for a PPC port of ADoom and Aminet, of course. BUGS FIXED: ----------- 1.1 ADoom couldn't open keymap.library on OS3.0 Amigas. Fixed. Restored MAXVISSPRITES, MAXDRAWSEGS and MAXVISPLANES to their original values. They took up too much memory and often caused structures to be allocated in chipmem, slowing the game down. 1.0 ADoom should now be sensitive to international keyboards. Bug with palette colour index 0 not being set in v0.9 fixed. EHB modes on 68020/68030 flickered badly when the display flashed in v0.9. Fixed. ADoom now precalculates all 14 possible EHB palettes for the gamma level whenever the gamma level changes, so there is no stall when the palette changes in the game (except when you change the gamma level). ScreenModeRequester defaults to a more intelligent ScreenMode. 0.9 Made it possible to CTRL/C out of network synchronisation wait loop. Applied patches to am_map.c supplied by Cyril Deble to fix bugs map markers and boundaries with -rotatemap and -maponhu. Fixed some serious memory allocation/deallocation bugs in w_wad.c. See amiga_notes.txt. The TURBO tooltype corresponding to the -turbo option (whatever that is) isn't a flag, it takes an argument. ADoom was treating it as a flag. Fixed. 0.8 Got rid of the warning message for every sound effect when -nosfx is used. Lowered the volume of music and sound effects. That eliminated the clicks and pops in music and enabled the full range of the sound effect volume slider to have effect. Fixed (harmless) missing #endif in d_main.c. Fixed bug in r_things.c, info.c and info.h. I wonder if this fixed the "PNAMES not found" bug. See amiga_notes.txt. Applied patch supplied by Aki to DrawColumn_060() in amiga_draw.s to fix problem with red stairs and random pixels on 68060. 0.7 In 0.6 I accidently introduced a serious bug into the C2P routine used for 68040+AGA and 68060+AGA. Fixed this for version 0.7. In 0.6 I accidently introduced a serious bug in the MMU cleanup routine when -mmu is used or the MMU icon tooltype is used. Fixed for version 0.7. 0.6 Fixed bug in low detail mode and re-enabled it, thanks to a note from Georg Steger , the author of DoomAttack, and some assembly code from Aki Laukkanen. The monster-counting bug (also the problem with "Dead Simple") was caused by SAS/C generating unexpected code for function pointer comparisons in "if" statements with CODE=NEAR. See amiga_notes.txt in the source archive. Version 0.5 had a bug in the DrawSpan() routines which left bright dots scattered around the floors and ceilings and red stairs at the start. Applied patch supplied by Aki Laukkanen. Music tones are now PAL/NTSC sensitive. Fixed the bug which sometimes caused crash on exit when music is enabled. 0.5 The call to BestModeID() in amiga_video.c had an unterminated taglist. Fixed. Whoops it never worked under OS2.1 after all. For now I've changed it so ADoom refuses to start on less than OS3.0. Currently I think LoadRGB32() is the only V39 function used. ADoom 0.4 was also calling BestModeID() and failing to autoopen lowlevel.library. 0.4 Gamma correction tables weren't being used in ECS modes. Fixed. Set default task priority to -5 because ADoom is unfriendly to other tasks otherwise. Added -taskpriority commandline option and TASKPRIORITY icon tooltype, so you can set whatever priority you like. I think I finally fixed the crash on exit bug. Two commas were missing in dstrings.c. I haven't had a crash for a long time now. 0.3 In ADoom versions up to 0.2, setting graphics detail LOW and then resizing the display resulted in corrupt graphics. Crashes were possible. Indeed, LOW detail didn't work at all. This appears to be a bug in the original Linux source. I can't see how LOW detail is supposed to work, so for now I've disabled LOW detail in ADoom 0.3. ADoom exclusively allocates the 2nd gameport for the joystick. It seems that many people have something in their startup which exclusively allocates the gameport, in which case ADoom v0.2 refuses to run. BlitzBlanker is one such culprit. ADoom 0.3 runs with the joystick disabled if it can't exclusively allocate the gameport. Added -forcedemo option in v0.3 to override the version check when playing demos. The FORCEDEMO icon tooltype does the same thing. There is a risk something might go wrong if the versions don't match, but I haven't observed any problems so far. Early versions of DOOM had a sound pitch change feature. That is, the same sound sounds effect could be played at different notes. I reproduced this feature in ADoom 0.1 and ADoom 0.2. However more than one user told me this feature was removed from recent versions of DOOM and some effects sound wrong in ADoom. Therefore I disabled the pitch change feature in ADoom v0.3. It is still there and can be enabled with the -changepitch option or CHANGEPITCH icon tooltype. 0.2 Early versions of ADoom required the HOME environment variable to be set. This confused a lot of people. Since version 0.2, ADoom saves its prefs file (.doomrc) in the current directory if HOME is not set. Early versions of ADoom crashed if there wasn't enough memory available. Since version 0.2, ADoom checks the result of the main (up to 6 Mb) memory allocation. There are still a few places where small memory allocations are not checked. THANKS: ------- Thanks to John Carmack and ID Software for one of the best games ever! Peter McGavin. (p.mcgavin@irl.cri.nz) ============================= Archive contents ============================= Original Packed Ratio Date Time Name -------- ------- ----- --------- -------- ------------- 1237 736 40.5% 06-Jan-98 15:13:26 ADoom.info 344744 188352 45.3% 20-Feb-98 17:47:40 +ADoom 4376 1111 74.6% 14-Feb-98 22:49:00 +ADoom.info 38151 16087 57.8% 20-Feb-98 17:34:12 +ADoom.readme 2567 452 82.3% 06-Jan-98 15:13:38 +ADoom.readme.info 31777 10808 65.9% 20-Feb-98 17:45:34 +amiga_notes.txt 38255 38255 0.0% 07-Feb-98 10:14:34 +Amipx1_1.lha 2100 297 85.8% 31-Jan-98 13:33:52 +doomwad_ft.info 628 258 58.9% 06-Jan-98 15:13:38 +more_icons.info 214606 78788 63.2% 19-Feb-98 21:41:12 +UserHints.txt 2567 450 82.4% 06-Jan-98 15:13:38 +UserHints.txt.info 22018 3700 83.1% 10-Feb-98 21:42:24 +DMARMY3.DEH 4557 1006 77.9% 22-Aug-95 02:13:46 +FUN_2.DEH 25815 3526 86.3% 23-Aug-95 23:39:58 +TURBO.DEH 5059 5059 0.0% 03-Feb-98 22:30:32 +doomwad_ft.lha 1440 684 52.5% 03-Feb-98 22:32:06 +doomwad_ft.readme 1237 735 40.5% 01-Jan-98 10:26:38 +ADoom.info 3501 2615 25.3% 01-Jan-98 16:36:26 +ADoom.MWB.info 10078 6650 34.0% 01-Jan-98 16:36:26 +ADoom.NI.info 5317 5317 0.0% 19-Jan-98 18:47:48 +ADoomNI.lha 7312 4828 33.9% 31-Jan-98 13:29:22 +Doom.info 19489 19489 0.0% 03-Jan-98 09:55:02 +Doom_icon.lha 1614 1216 24.6% 01-Jan-98 10:26:42 +start_doom2.info -------- ------- ----- --------- -------- 788445 390419 50.4% 21-Feb-98 06:22:44 23 files