Date: Tue, 24 Nov 1998 13:45:37 -0500 From: David Jeffers <jeffers@redrose.net> To: freebsd-questions@FreeBSD.ORG Subject: DOOM fans -This is what you want.... Message-ID: <19981124134537.A709@primus.mynet.net>
next in thread | raw e-mail | index | archive | help
Download 'lxdoom' using the info given below. This is a Linux port that runs perfectly using the linux emulator under FreeBSD 2.2.7-RELEASE, using X-Windows. You can play any game including PWADS, total conversions, Ultimate Doom, Final Doom, whatever. Enjoy! LxDoom README ============= LxDoom is a version of Doom, designed to run on Linux either under XFree86 or using SVGALib. Doom is a 3D game originally by iD software. LxDoom is based on Boom, a freely available port of Doom for DOS, written by TeamTNT (http://www.teamtnt.com). LxDoom is released and maintained by Colin Phipps (cph@lxdoom.linuxgames.com) and I am eager for feedback! See the LxDoom homepage at http://lxdoom.linuxgames.com for information about lxdoom, downloading the latest version and complete source code. Requirements ------------ - a copy of Doom, Doom ][, Ultimate Doom or Final Doom (specifically, the IWAD file) - Linux (i386) (you could theoretically recompile the sources for any version of Linux (UNIX too?), though I doubt it would be that easy) - Either - A working XFree86 installation (MITShm extension and System V IPC support highly recommended) or - A copy of SVGALib (I strongly suggest that you upgrade to the latest version) Changes from v1.1.0 to v1.1.1 ----------------------------- - Fixed crash using -warp parameter with SVGALib version - Fixed music server communication code - Should compile using glibc For further revision history, see the end of this file. Features -------- * Boom compatible: LxDoom is directly based on the source code for Boom (maintenance release 2.01, with all updates available up to 1998/09/14). That means that - all the original Doom & Doom ][ levels work - virtually all bugless Doom & Doom ][ PWAD files should work - the majority of Doom & Doom ][ v1.9 demos should work (maybe others too) - all Boom PWAD files and demos (for v2.01) should work - dehacked patches and BEX patches are supported using -deh parameter The command line parameters for all these features are the same as for Boom. * X windows - LxDoom uses XFree86 to display the Doom screen, as well as collect keyboard and mouse input. So if you can use XFree86, you should have no problems using LxDoom. * SVGALib version - nearly as fast as Dos Boom with normal vid card, and should use the acceleration on accelerated cards supported by SVGALib (not tested yet) * Sound support: If your linux kernel provides /dev/dsp support for your soundcard, then LxDoom can also give you the Doom sounds too. Or if you use an alternative driver, which provides equivalent support on a different device (e.g the PC speaker driver) then LxDoom can use that instead. * Networking: Network support is included for netgames over TCP/IP based networks. * Misc: Joystick support, 'multitasking-friendly'. * Music interface: Using a compatible music server LxDoom can now play music. You can get a compatible version of musserver from my site. Installing & Using LxDoom ------------------------- To install lxdoom, create a directory somewhere and copy the following files there: lxdoom boomlump.wad sndserv (if you want sound support) and the text files If you want the man file for lxdoom, copy it either to the LxDoom directory, and read it using 'man -l lxdoom.6'; or copy it to your man/man6 directory, and then you can read it using 'man lxdoom'. Next, you have to tell LxDoom where to find your IWAD (that is, your doom.wad or doom2.wad). You could use the -iwad parameter, but a better way is to create a symlink, e.g ln -s /dos/games/dos/doom2/doom2.wad ./doom2.wad Finally, running LxDoom. Just make sure that you are in the LxDoom directory, and type ./lxdoom -file boomlump.wad You _must_ prefix lxdoom with ./ even if you put it in your path, because of the way Boom calculates the directory that it is in. Alternatively, set the environmental variable BOOMPATH to point to the directory where lxdoom will by default store its config & temp files. If you don't want sound, or you don't have a sound card, also add the -nosound parameter. lxdoom will load and run faster then. You _must_ include boomlump.wad, to get certain required resources. If you really wanted to, you could merge it with your IWAD, but I wouldn't recommend it. Note: boomlump.wad is different from that supplied with previous versions of lxdoom. If you have a previous version, you can safely delete the old versions and just use this one. Note: boomlump.wad is also different from that created by Boom or other Boom clones with their -dumplumps parameter, as it includes more stuff that they keep in the EXE. It is the same as all versions of LxDoom v1.x Finally, for machines with lots of RAM, add the -heapsize parameter. This tells lxdoom how much RAM to use for cacheing data from WAD files. Linux is so good at cacheing disk I/O that you can usually run with the default 4 MB easily. But for big WADs, or if you get serious slowdown, try '-heapsize n' to increase the heap size to n MB (I find that '-heapsize 8' is enough for almost all levels). People with very limited RAM (8-12 Mb) can: - disable sound - use -heapkb to set the heapsize in kilobytes, so you can fine tune the amount of memory lxdoom uses - use the 320x200x256 X-server video mode described below, to avoid using -2 which uses extra memory - better, use the SVGALib version which will save memory by not needing X loaded, and is faster anyway. XFree86 version --------------- The XFree86 version of LxDoom is the file lxdoom. You can probably just use your existing XFree86 configuration to run lxdoom with few changes. You have to make sure that you are running in a supported graphics mode. lxdoom will exit with an error if you are not. You will be best off using a 256 colour mode: to change the colour depth of your XFree86 setup, edit your /etc/XF86Config file. Replace any existing DefaultColorDepth lines with: DefaultColorDepth 8 line. (Remember to take a backup). Alternatively, if you don't want the change to be permanent, just use 'startx -- -bpp 8' when starting X, instead of the usual 'startx'. If you normally use a DirectColor or TrueColor mode at 16 bpp, then lxdoom now also supports this - but it is a slower than using lxdoom in 256 colours. Try it and see how it goes. If you use a high graphics resolution or a small monitor, the lxdoom window may be too small for LxDoom to be comfortably playable. In tht case, if you have a powerful PC, try running lxdoom with the -2 parameter. This makes the window twice as big in both directions. If that is still too small, try the -3 parameter instead. The problem with the -2 and -3 paremeters is that they slow down lxdoom considerably. If you find that these are too slow, you can try the more radical solution. This is only recommended if you have manually edited your /etc/XF86Config file before, and have a rough idea what the sections are for: - Back up XF86Config - Make sure that you are using the SVGA server. If you are not, you may be out of luck. You could try running the xf86config program to select the SVGA server, but I haven't tried this and don't know if it will work. - Edit XF86Config - Find the section that begins Section "Screen" Driver "svga" - find the Modes line for the 8 bpp colour depth - add a mode "320x200" - save and try it out. You should be able to cycle through modes (on my server it's CTRL+ALT+<+/-> and find the low-res one. If that doesn't work, it may be because your card driver doesn't support a compatible clock setting. You can try changing to the Generic VGA device, by editing your Scren section to look a bit like this... Section "Screen" Driver "svga" # Use Device "Generic VGA" for Standard VGA 320x200x256 Device "Generic VGA" # Device "VidCard" Monitor "Monitor" DefaultColorDepth 8 Subsection "Display" Depth 8 # Omit the Modes line for the "Generic VGA" device Modes "320x200" ViewPort 0 0 Virtual 320 200 ... As you can see, the xf86config script with my XFree86 puts in a lot of helpful comments. If yours has done too, do whatever it says for the 'Standard VGA 320x200x256' mode (after all, all I am doing is folowing those same instructions). However, remember that doing this will probably make X unusable for anything but Doom. Personally I'd recommend putting up with a small window, using <CTRL>-<ALT><+/-> to step down to 640x480 for lxdoom. At least, you could write a short shell script to swap XF86Config's according to whether you want lxdoom or serious X. WARNING: Fiddling with XF86Config is dangerous. If you have configured your monitor or video card incorectly, then damage to your monitor or even worse could result. I cannot be held responsible for any such damage. Please read the relevant XFree86 docs before trying anything like this; they have similar warnings and disclaimers. lxdoom now only grabs your mouse pointer while actually playing, and it can be released at any time by PAUSEing. If you don't want to use a mouse, use the -nomouse parameter when launching lxdoom. SVGALib Version --------------- SVGALib is a graphics library developed specifically for Linux/i386, which provides games like LxDoom high-performance graphics functions. You have to have a compiled version of SVGALib installed to use the SVGALib version of LxDoom, which is the file lsdoom. * Security: SVGALib provides near-direct hadrware access for games that run using it. That is why it is faster than XFree86 for games. BUT that means that you have to be the superuser (root) to run anything that uses it. So you can run lsdoom as root, _or_ you can make lsdoom always run as root. To do the latter, do the commands (as superuser): chown root lsdoom ; chmod a+rxs lsdoom This tells Linux to always run lsdoom with root privileges, regardless of who runs it. Recent versions of SVGALib will release these privileges once the game is running; however I will not pretend that this is safe, since lsdoom does most of the file reading/writing before it is in graphics mode. It is, however, better than always running it as superuser. Note: I found that I also had to 'chmod a+r /dev/mouse'; other devices may also require this * Setup: Read the SVGALib documentation for information on configuring your screen, video card and mouse to work nuder it. LxDoom asks SVGALib for all those settings, so you have to edit /etc/vga/libvga.config to set them up. Most video cards are autodetected, and /dev/mouse and Microsoft serial mouse are usually the default. Note: A badly configured SVGALib can be a security hazard, can cause your machine to lose keyboard input (try telnetting if possible if this happens, else you have to reboot), or can damage your monitor. I cannot be responsible for any damage caused by improper use of SVGALib, even if my code is directly or indirectly resposible. Other Devices ------------- Items in this section relate to other input/output devices supported by either version of LxDoom. * Sound: You can disable sound support with the '-nosound' parameter. You may want to do this if: - you have no soundcard - your kernel is not compiled with sound support - the kernel driver fo your card does not provide /dev/dsp support - your computer is too slow to cope with sound processing - you want to run multiple copies of LxDoom If you use have an alternative device for producing sound, which is compatible with /dev/dsp, LxDoom can use that as well. You could just symlink /dev/dsp to your other device, or you can: 1) Run LxDoom once with the -nosound parameter. 2) Exit normally 3) Edit boom.cfg 4) Change the line snddevice to the device that sound output should be sent to 5) Save boom.cfg and try it out! * Joystick: To use a joystick in LxDoom, run LxDoom once first and then exit. This creates boom.cfg in the LxDoom directory. Edit boom.cfg. There is a use_joystick line - change the number on this line to the number of your joystick (usually 1, maybe 2 if you have 2 joystick ports). To disable the joystick for an individual session, us the '-nojoy' parameter. Multiplayer - Over a TCP/IP network ----------- You have to add the following parameters: -nodes followed by the number of players -net followed by the player numbers of this machine followed by the hostnames (or IP addresses prefixed with a .) of the other machines in the game. + any other parameters (e.g -warp 1 -deathmatch -altdeath etc) E.g. for a 2 player network game between machines with TCP/IP addresses 192.168.0.1 and 192.168.0.2, use the following parameters: On machine 1: -nodes 2 -net 1 .192.168.0.2 On machine 2: -nodes 2 -net 2 .192.168.0.1 E.g. for a 4 player network game between machines with names m1, m2, m3, m4 in DNS domain doom.org, use the following: On m1: -nodes 4 -net 1 m2.doom.org m3.doom.org m4.doom.org On m2: -nodes 4 -net 2 m1.doom.org m3.doom.org m4.doom.org On m3: -nodes 4 -net 3 m1.doom.org m2.doom.org m4.doom.org On m4: -nodes 4 -net 4 m1.doom.org m2.doom.org m3.doom.org Notes: - playing across a router, or over the Internet, is unlikely to work, just as for the original Doom. - Only 4 players are supported. Wait for Boom Phase ][ for that to change, I suspect. Missing Features ---------------- All too many things still to do... - Music support: Working on it... - Internetworking with other ports: Boom and other DOS based ports use a radically different networking method, so this won't work. - Move code to shared, maybe even dynamic libraries: I was thinking of some big files like d_deh.o, which could be linked dynamically just during loading, then ejected to save RAM. - GGI version - Portability testing - If anyone manages to compile this with any other X-windowing systems, let me know how it goes. - Re-integrating with original Boom sources - I did remove some of the obscurer files, but I might do a test that it would still compile under DOS. If I can be bothered to download DJGPP to find out. Probably not then ;). There should be no problem, I only had to modify a few of the non-system sources to get it all working. Performance ----------- Only rough figures here, but they vary by up to 10fps between runs anyway. All tests are -fastdemo demo2. Obviously all the figures quoted here are from running lxdoom (and other ports) on my own machine; your results will be different. Probably this is a good reflection of how fast lxdoom will be relative to DOS Boom - basically it's about 20% slower. All figures in fps (frames per second) as measured by -timedemo demo2 With sound Without Reference - original Boom under DOS : 275 300 lxdoom with sound server : 200 225 current SVGALib version : 250 280 (under development) Credits ------- iD software, for releasing the Doom sources and for a great game. TeamTNT, for the best Doom port, which not only has the best features but is easily portable too. Everyone who e-mailed me about the previous release of lxdoom, because I wouldn't be releasing this otherwise. Also some individuals I'd perticularly like to thank: Udo Monk - His port xdoom is very portable, and includes a useful collection of tools too, check it out. Frederic Oghdayan - For useful feedback on LxDoom v1.0.1, and repeating his bug reports until I believed them :-). Michael Heasley - Author of musserver, which my music support is designed to use a modified version of. Revision History --------------- * Changes from v1.0.1 to v1.1 - SVGALib version - Fixed timing problem on buggy kernels causing crashes in the wipe screens - Fixed bug in sound server communications which prevented Doom 1 working - Fixed problem with sound code causing accelerated sound on v2.1.125 kernel - Removed need for IPC in sound server communications, used pipe instead - Improved mouse grabbing/ungrabbing code in XFree86 version, now depends on game and window status - Improved TrueColor/DirectColor 16 bpp support - X version is more multitasking friendly - detects when it is hidden or paused or an intermission screen is up, and tries to free some more CPU time. * Changes from v1.0.0 to v1.0.1: - 16 bpp colour modes now supported. If you use a 16 bpp colour mode (65 thousand colours approx.), then you don't have to change your X setup to 256 colours (8 bpp) before using lxdoom anymore. However, it is still a good idea to use 256 colours, because it is faster that way. - fixed a minor bug in routine used for the 8 bpp '-2' option (screen doubling), which caused a couple of lines to be missed at the bottom of the display window. - fixed a Boom bug which caused crashes in multiplayer games. The bug occured when, during a single game session, first the players played one level at which someone died, and then later exited that level, and later still another player died. I.e in a multilevel deathmatch, or a long co-op game. Caused one machine to exit lxdoom with 'Segmentation Violation'. The version of PrBoom I have also exhibits these symptoms, though obviously I can't be sure that this is the cause; Boom probably has the bug too. Legal stuff ----------- In the following, LxDoom refers to this entire package, that is the program, data files, and help files. Doom, Doom ][, Ultimate Doom and Final Doom are all (I believe) trademarks of iD software. LxDoom is not an iD software product, and is not supported by iD software. iD will not provide technical support for LxDoom or any problems that arise through using LxDoom. For full information on the license under which iD released the Doom sources, see doomlic.txt LxDoom is not directly a product of TeamTNT, and is not supported directly by them. However, if you have problems with LxDoom, it is worth trying DOS Boom and seeing if the problem also occurs there. If it doesn't, contact me. If it does, you are more likely to get help from TeamTNT, since they know a lot more about the code than I do. You use LxDoom at your own risk. The author will not be held responsible for any damage resulting from the use of LxDoom, or any damage resulting from installing it or trying to get it to work. So if you scramble your X setup trying to get that 320x200 mode, don't expect me to fix it. The original Doom source code is copyright by iD software - see doomlic.txt for full details of the license under which you can use it. Basically you can use the code and any programs derived from it (such as LxDoom) for non-profit use. Those parts of the code which have been added subsequently are covered by a collection of docs, which I have tried to include. I have included the documents which came with Boom, under txts/boom/. I retain the copyrights on the bits that I have added, which you can do what you like with provided I get a little credit. -- David Jeffers -------------- mailto: jeffers@redrose.net ---------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981124134537.A709>