Doom in Linux HOWTO

Doom in Linux HOWTO

[Stian Sletner]

Hi again.

I've been working on a document to help people set up Doom in Linux via
DOSEMU.  Since DOSEMU is such an integral part of it, I'd appreciate any
feedback or criticism from you guys.  I know the subject is a bit
narrow, but hey, you have to write about what you care about, right? :)

Also, Section 4.2 is still unwritten because of my tunnelling problems,
I'm still not quite sure how to go about it.  All input appreciated. :)

Temporary URL: http://home.powertech.no/sletner/doom-in-linux.html

DocBook XML source: http://home.powertech.no/sletner/doom-in-linux.xml
(for those interested.)

-- 
Stian Sletner

Re: Doom in Linux HOWTO

[Bart Oldeman]

On Sun, 8 Dec 2002, Stian Sletner wrote:

> I've been working on a document to help people set up Doom in Linux via
> DOSEMU.  Since DOSEMU is such an integral part of it, I'd appreciate any
> feedback or criticism from you guys.  I know the subject is a bit
> narrow, but hey, you have to write about what you care about, right? :)

The only thing I have to mention is that the setup you're describing in
insecure, so don't do this on a box where you have untrusted accounts.
You don't mention that you can play DOOM in xdosemu (without root
privileges). Of course that's slower than console dosemu DOOM but it is
playable (at least it was for me the last time I tried it ;)

The manual copying problem will be fixed soon. I'm working on it.

Bart

Re: Doom in Linux HOWTO

[Stian Sletner]

* At 2002-12-07T23:47-0500, Bart Oldeman wrote:
: 
| The only thing I have to mention is that the setup you're describing in
| insecure, so don't do this on a box where you have untrusted accounts.
| You don't mention that you can play DOOM in xdosemu (without root
| privileges). Of course that's slower than console dosemu DOOM but it is
| playable (at least it was for me the last time I tried it ;)

Thanks, I'll add a note about it.

| The manual copying problem will be fixed soon. I'm working on it.

Coo'.

-- 
Stian Sletner

Re: Doom in Linux HOWTO

[Peter Jay Salzman]

hi stian,

one comment -- you're walking people through installing bleeding edge
dosemu, but there's a problem with the latest patchset 1.1.3 where the
compiling of a bison file fails.

the fix (in patch form) is here:

http://article.gmane.org/gmane.linux.msdos.general/847

this link also mentions that dosemu users may want to use 2.4.19 or
2.4.20-pre since these kernels contain dosemu related patches.  this
email was written before 2.4.20 came out, so i'm assuming that 2.4.20
also contains the dosemu related patches.

the patch i mentioned is summarized here: in bisonpp.pl, change the
line:

$rule =~ s/[ \t]*;\s*$//s;# remove trailing ';'

to this:

$rule =~ s/[ \t]*;\s*\n//s;# remove trailing ';'

i'm only mentioning this because patch sets come out so infrequently
with dosemu that some of your readers may need to know this for a little
while.

pete

Re: Doom in Linux HOWTO

[Stas Sergeev]

Hello.

Stian Sletner wrote:
> Section 4.2 is still unwritten because of my tunnelling problems,
> I'm still not quite sure how to go about it.
I really think that playing doom on the
same machine the tunnel is running, is
rather rare requirement, so you can
write that section omitting that detail.
I also still think that it is nothing
more than your bridging software limitation.
See what the main page says:
---
For those who wanna play in Windows, *with
more than 2 LANs connected*, try GIT
---
And I also think that tunelling to dsn
will work. I tried 2 dosemu sessions:
first with $_vnet=(on) and the second
with $_vnet=(off) (as acting from outside)
and the dooms see each other.

> if you want sound to work (and who wouldn't), you need to get a third-party patch
Well, I don't agree it is a third-party
patch:) Furthermore it will be a part of
dosemu eventually, so this part of the doc
is nothing more than a "temporary hack".

> Set $_cpu to whatever fits your iron. 
No, this is whatever CPU you want to be
emulated (actually just reported to the
dos prog with some other minor differences).

> Set $_xms to some value you see fitting, I use 8192. 
> Set $_ems to 0, Doom doesn't use it.
Doom might not requre neither XMS nor EMS
but still setting them to 0 is not
recommended as many other progs may start
complaining.

> $_novell_hack to on. 
Is it really necessary to do that packets
conversion? I was playing network doom
only on dsn and it works also without a
novell_hack, so I am not sure what problems
does it solve exactly. So why is this important?

> $_netdev to "eth0", if that is your LAN device. 
OK, I think you have to also describe a
$_vnet possibility. Btw, if $_vnet is enabled,
$_netdev is ignored, which must be noted.

> DOSEMU and Doom do not use very much CPU
How does this feet with your suggestion of
setting $_hogthreshold to 0? It must eat
100% of your cpu if $_hogthreshold is not
enabled.
Even with $_hogthreshold set to 1 doom eats
75% of CPU under X and 60% under console on
my Athlon700. Two instances of doom (connected
via vnet) are not playable:(
So I would say doom is extremely CPU-hungry
under dosemu, at least on my system.

Re: Doom in Linux HOWTO

[Stian Sletner]

* At 2002-12-08T17:35+0300, Stas Sergeev wrote:
: 
| I really think that playing doom on the same machine the tunnel is
| running, is rather rare requirement, so you can write that section
| omitting that detail.

I find this to be a very strange opinion.  Most people wanting to play
Doom on the 'net won't have an extra machine on which to run a tunnel.

| I also still think that it is nothing more than your bridging software
| limitation.  See what the main page says:
| ---
| For those who wanna play in Windows, *with more than 2 LANs
| connected*, try GIT
| ---
| And I also think that tunelling to dsn will work. I tried 2 dosemu
| sessions: first with $_vnet=(on) and the second with $_vnet=(off) (as
| acting from outside) and the dooms see each other.

Mm, I still have some testing to do...

| Well, I don't agree it is a third-party patch:) Furthermore it will be
| a part of dosemu eventually, so this part of the doc is nothing more
| than a "temporary hack".

I'm aware.  On the other hand, it's been supplied as a patch for quite
some time now. :)

| No, this is whatever CPU you want to be emulated (actually just
| reported to the dos prog with some other minor differences).

Ok, I guess it's rather irrelevant in Doom's case, then?

| Doom might not requre neither XMS nor EMS but still setting them to 0
| is not recommended as many other progs may start complaining.

That's sort of outside scope of the HOWTO, however I believe there was
some particular reason for setting 0 EMS, but I don't remember what it
was, now.

| Is it really necessary to do that packets conversion? I was playing
| network doom only on dsn and it works also without a novell_hack, so I
| am not sure what problems does it solve exactly. So why is this
| important?

Hm.  Looks like it does convert them to 802.3 regardless of whether it's
on or off?

| OK, I think you have to also describe a $_vnet possibility. Btw, if
| $_vnet is enabled, $_netdev is ignored, which must be noted.

Yes, I will expand this part when Section 4.2 is written.

| How does this feet with your suggestion of setting $_hogthreshold to
| 0? It must eat 100% of your cpu if $_hogthreshold is not enabled.

You're right.  This was an error.  It DOES eat alot of CPU. :)

Thanks for your feedback.

-- 
Stian Sletner

Re: Doom in Linux HOWTO

[phrostie]

sorry i'm late getting into this but why can't you run either:

lxdoom-svga 1.4.4-7
Svgalib binary for lxdoom 
or
lxdoom-x11 1.4.4-7
X binary for LxDoom

do they not have needed features?

-- 
Oh, I have slipped the surly bonds of DOS,
and danced the skies on Linux silvered wings.
http://pfrostie.freeservers.com/cad-tastrafy/
http://www.freelists.org/list/cad-linux

Re: Doom in Linux HOWTO

[Peter Jay Salzman]

because he wanted to detail doom under dosemu.  :)  sometimes this kind
of reason is simply enough when you're talking about linux.

btw, lxdoom is totally outdated.  that project has merged with 2 other
doom port projects and has formed prboom.

i think doom legacy is the best; you have mouse look up and down (like
quake) and can jump.

pete

begin phrostie <pfrostie@yahoo.com> 
> sorry i'm late getting into this but why can't you run either:
> 
> lxdoom-svga 1.4.4-7
> Svgalib binary for lxdoom 
> or
> lxdoom-x11 1.4.4-7
> X binary for LxDoom
> 
> do they not have needed features?

-- 
Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D

Re: Doom in Linux HOWTO

[Stas Sergeev]

Hello.

phrostie wrote:
> sorry i'm late getting into this but why can't you run either:
That was a generic instructions.
You change the word "Doom" there
to Duke3D, Hexen, Heretic, whatever
you want, and it is still valid.

> lxdoom-svga 1.4.4-7
OK, but when I want
"lxduke3d-svga-1.4.4-7", this
doesn't work (non-existant).

Re: Doom in Linux HOWTO

[Stas Sergeev]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

Hello.

Stian Sletner wrote:
> | And I also think that tunelling to dsn will work. I tried 2 dosemu
> | sessions: first with $_vnet=(on) and the second with $_vnet=(off) (as
> | acting from outside) and the dooms see each other.
> Mm, I still have some testing to do...
OK, given that SIB doesn't support more
than 2 interfaces and that dosnet doesn't
support a kernel bridging (bridging to it
from user-space is OK however), the things
are difficult...
But I've found a solution for you:)

At first, compile and start the simple
bridge I've just made by copy/pasting some
examples supplied with TUN/TAP driver.
The code is attached.
If it printed something like:
Allocated devices: tap0 and tap1
then everything goes fine.

The second, as dosnet doesn't support the
kernel bridging, apply the TUN/TAP patch
from my page, do the necessary change in
dosemu.conf and start dosemu. It will
allocate tap2 (now as the tap0 and tap1
are busy already).

Now do this:
ifconfig tap0 up
ifconfig tap1 up
ifconfig tap2 up
brctl addbr br0
brctl addif br0 tap1
brctl addif br0 tap2
brctl addif br0 eth0
ifconfig br0 up

If there were no errors, you are doing good:)
Now configure your SIB to communicate to tap0
(note that tap0 was not added to br0 bridge as
it is intended to be used by SIB).

That should do it. If I haven't forgot something,
now you have 3 dosemu sessions working together:
on the other end of SIB; on tap2 on the same
machine; somewhere on the net to which the eth0
is connected.

Well, this may be too complicated at a first
glance (3 different bridging software working
between different virtual interfaces etc), but
that would definitely be a lot of fun for you
to play with:)

[-- Attachment #2: sbr.c --]
[-- Type: text/plain, Size: 1771 bytes --]

#include <stdio.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>

#include <netinet/if_ether.h>
#include <linux/if.h>
#include <linux/if_tun.h>

#define max(a,b) ((a)>(b) ? (a):(b))

int tun_alloc(char *dev)
{
      struct ifreq ifr;
      int fd, err;

      if( (fd = open("/dev/net/tun", O_RDWR)) < 0 )
         return -1;

      memset(&ifr, 0, sizeof(ifr));

      /* Flags: IFF_TUN   - TUN device (no Ethernet headers)
       *        IFF_TAP   - TAP device
       *
       *        IFF_NO_PI - Do not provide packet information
       */
      ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
      if( *dev )
         strncpy(ifr.ifr_name, dev, IFNAMSIZ);

      if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
         close(fd);
         return err;
      }
      strcpy(dev, ifr.ifr_name);

      return fd;
}

int main(int argc, char *argv[])
{
   char dev1[7], dev2[7], buf[1600];
   int f1,f2,l,fm;
   fd_set fds;
 
   strcpy(dev1,"tap%d");
   strcpy(dev2,"tap%d");
   if (((f1 = tun_alloc(dev1)) < 0) || ((f2 = tun_alloc(dev2)) < 0)) {
     printf("Cannot allocate TAP device\n");
     exit(1);
   }
   printf("Allocated devices: %s and %s\n", dev1, dev2);

   fm = max(f1, f2) + 1;
/*
   ioctl(f1, TUNSETNOCSUM, 1); 
   ioctl(f2, TUNSETNOCSUM, 1); 
*/
   while(1){
	FD_ZERO(&fds);
        FD_SET(f1, &fds);
        FD_SET(f2, &fds);

	select(fm, &fds, NULL, NULL, NULL);

	if( FD_ISSET(f1, &fds) ) {
	   l = read(f1,buf,sizeof(buf));
	   printf("Got %i bytes from %s\n", l, dev1);
           write(f2,buf,l);
	}
	if( FD_ISSET(f2, &fds) ) {
	   l = read(f2,buf,sizeof(buf));
	   printf("Got %i bytes from %s\n", l, dev2);
           write(f1,buf,l);
	}
   }
}