The official "ZDoom on Linux" thread.

Mon Jun 05, 2006 9:29 am

Well now that I have switched over to Linux, I'm missing ZDoom. I lost track of all the little threads that have popped up over the years since '04 about compiling and stuff. so because I said so (:)), here is an official FAQ.

I happen to be using Gentoo so my commands will differ a bit from most of the debian people so do whatever conversion you must.

My system:
  • Linux 2.6.16-r10 (gentoo-sources)
  • Xorg 6.something (not the modular one (xorg-x11)
  • nVidia drivers (nvidia-glx, nvidia-kernel)
  • GNOME whatever.the.latest.stable.is (gnome-light)
  • Other various weird libraries from installing other games and crap. (sdl, lds, sld, dsl, lsd, AIDS, that kind of stuff)


So here's what I'm going to do when I get home later:
I know all this probably won't work, but after enough tries/updates I'm sure it will begin to make sense. ;)

How to install ZDoom on Gentoo Linux
(note: This almost definately won't work (in fact, I know it won't work), I'm just writing a thingy to start from so others "in the know" can correct me and then I'll update this HOWTO.)

I assume since ZDoom uses SubVersion, I should emerge subversion first.
Code:
# emerge subversion

Of course you su to root first, but you already knew that. ;)

I have no clue how to get ZDoom out of there so I'm just going to skip ahead to the compiling part. :)
Code:
# cd /usr/src/zdoom
# configure

Oh, there's no configure script? I'll just make it then.
Code:
# make

It will probably output a billion skillion errors but I'll just pretend it worked.
Code:
# make install

Now it should be buried into your system so deep you'll need a hundred ferrets to get it out, but why would you ever want to get rid of ZDoom? ZDoom is yoru friend, your own, your prescious...

Anyway, now you should be able to type zdoom from anywhere to start killing crap.
Code:
$ zdoom

If it comes up, great, it probably won't. It's never that simple. You might have to go:
Code:
$ /sbin/zdoom

I dunno. I'll figure it out, I'll look long and hard all by myself...
Code:
# find / -name zdoom

Yeah, if it spits out zdoom, run it from wherever it is and proceed with the voilence.

Well, this should probably be in the WIKI, but nobody would ever find it. I'll move it there once it gets into a workable state.
(/me waits for a zdoom ebuild...)
Last edited by Bio Hazard on Sun Jun 18, 2006 2:58 am, edited 1 time in total.

Mon Jun 05, 2006 10:12 am

This seems somewhat sticky worthy? (when it develops of course)

Mon Jun 05, 2006 11:06 am

Installing ZDoom on Fedora Core 5
1. Before compiling
1.1. Development tools
In order to compile ZDoom you need usual tools such as gcc, make, binutils etc.

The only needed tool that is not so common is NASM, you can install it by using yum from command line:
Code:
yum install nasm

1.2. Libraries which ZDoom use
ZDoom depends on several libraries:
  • FMod
  • SDL (+development package)
  • FLAC (+development package)
  • Timidity++ (optional)
To install FMod, you have to do the following (this must be run as root):
Code:
cd /opt

#download fmod
wget http://www.fmod.org/files/fmodapi375linux.tar.gz

#extract files from the archive
tar -xzf fmodapi375linux.tar.gz

#we don't need the archive anymore
rm fmodapi375linux.tar.gz

#create links so that the system know about fmod
ln -s fmodapi375linux/api/libfmod-3.75.so /usr/lib/libfmod.so
ln -s fmodapi375linux/api/inc /usr/include/fmod

#create <fmod.h>
echo '#include <fmod/fmod.h>' > /usr/include/fmod.h

You can install the others by using yum, again:
Code:
yum install sdl
yum install sdl-devel
yum install flac
yum install flac-devel

If you want to hear in-game midi music, you have to install Timidity++:
Code:
yum install timidity++

2. Building ZDoom
2.1. Getting the source code
You can get the latest source code from the subversion repository. In order to do that, you need the subversion client. If you don't have it, install it:
Code:
yum install subversion

Now you can get the source code. Change directory to the one where you want the source code to be downloaded (e.g. your home directory), and run the subversion client to get it:
Code:
svn co http://mancubus.net/svn/hosted/zdoom/zdoom/trunk zdoom

This will create new directory, called zdoom, which contains the source code.

2.2. Making the executable & wad
Now you can finally build ZDoom:
Code:
make

3. Running ZDoom
3.1. Running it for first time
You can run it from the source code directory:
Code:
./zdoom

3.2. Configuring
You can configure ZDoom in-game, but if you want to configure it manually, you can find zdoom.ini in directory .zdoom in your home directory.
Code:
cd ~/.zdoom



I hope this helps you in any way, if you find any errors or have any additions, tell me (and I think there is a lot of errors, because I've writen this post very quickly :P).
Last edited by Grubber on Tue Jun 06, 2006 6:36 am, edited 2 times in total.

Mon Jun 05, 2006 11:11 am

All of this is weird and I don't understand what's going on!

Mon Jun 05, 2006 11:20 am

I think 99% of all computer users will see this command line madness as a good reason to never to switch to Linux. With such installation procedures it will never go mainstream.

Mon Jun 05, 2006 11:56 am

Well, this is just if you have to do something from CVS/SV source. With proper ebuilds it is quite simple:
Code:
# emerge mozilla-firefox
Wait 15 minutes and it will be in your application menu. Not difficult at all.
Code:
# emerge quake3
# emerge doomlegacy
# emerge dosbox
# emerge openoffice
All very simple.

Mon Jun 05, 2006 1:38 pm

Graf Zahl wrote:I think 99% of all computer users will see this command line madness as a good reason to never to switch to Linux. With such installation procedures it will never go mainstream.

You aren't normally forced to use the command line. Besides, look at what we are talking about here: compiling ZDoom. The fact is that compiling things yourself in Linux is much easier and more natural than on Windows. It's also much easier to accurately tell someone what to do at the command line than say click here, then here, select that, etc. Besides pandering to the lowest common denominator isn't so great either.

On the other hand though, it should be easier for people who don't want to compile ZDoom themselves. Unfortunately, due to the lack of backward C++ ABI compatability and flaws in ELF (the executable format for linux and most other x86 unix-likes), the only real way to create a binary that will work for (just about) everyone is for someone to compile with old versions of libraries (including libc and libstdc++). Part of this problem will gradually recede as people stop using libstdc++.so.5. Of course, it will also reappear when libstdc++.so.7 is eventually released, unless the GCC developers fix this bug.

[edit] Nevermind, it looks like it was fixed by versioning namespaces, in addition to functions. These are still library and application-side solutions, though. (That is, every C++ library needs to make a small source-code change and recompile with a version of GCC that supports it). If they would just make one tiny break with the ELF standard, these problems would just go away. I'm looking forward to updating my distribution when I get a chance.[/edit]

In the meantime, someone could build an autopackage, which is basically an integrated series of hacks to make things as backward compatable as possible.

Grubber wrote:
Code:
make NOGC=true < Makefile.linux

The NOGC is no longer necessary; as of r166, I inverted the logic to instead enable it with GC. Also, notice that Makefile calls Makefile.linux when you aren't using Windows, so just "make" should work fine. Sorry, no, I didn't add an install target so "make install" doesn't work.

Mon Jun 05, 2006 3:13 pm

What about GZDoom? ^_~.

Mon Jun 05, 2006 4:29 pm

KingofFlames wrote:What about GZDoom? ^_~.

Compiling off the SVN gets you everything GZDoom has except OpenGL stuffs.

Mon Jun 05, 2006 5:03 pm

KingofFlames wrote:What about GZDoom? ^_~.


Well, judging by Graf's earlier comment, I seriously doubt there will ever be a GZDoom for Linux. Too bad...

Mon Jun 05, 2006 5:48 pm

Someone else has to do the GL system initialization code. I can't do it for obvious reasons.

Mon Jun 05, 2006 6:23 pm

Porting it really shouldn't be too hard. Mostly, you just rewrite very similar code to what is already there, substituting in the GLX equivalents of the WGL functions or do a similar thing through SDL. I'm not sure which is better and I haven't done this because I haven't ever actually used OpenGL for anything.

I certainly do want to gain this familiarity at some point. Therefore, I will probably undertake the task at some point, but that could well be months or years away (or maybe never). I certainly wouldn't be sad to see someone else do it first.

Mon Jun 05, 2006 8:26 pm

Jim wrote:
Grubber wrote:
Code:
make NOGC=true < Makefile.linux

The NOGC is no longer necessary; as of r166, I inverted the logic to instead enable it with GC. Also, notice that Makefile calls Makefile.linux when you aren't using Windows, so just "make" should work fine. Sorry, no, I didn't add an install target so "make install" doesn't work.

So, you've made it so that just a simple "make" will do for the people that can't use the GC code? So you have to use something like "make GC=true" or some-such?

May I ask your reasons for inverting it like this? :)

-M.

Mon Jun 05, 2006 8:28 pm

Linux is great, if you know what you're doing. Managing a project that works on linux and windows is difficult. Don't expect SVN to work on an operating system other than what's being developed. I expect a linux version come out of a stable release not long after a windows release has been made.

Mon Jun 05, 2006 9:03 pm

Jim wrote:The fact is that compiling things yourself in Linux is much easier and more natural than on Windows. It's also much easier to accurately tell someone what to do at the command line than say click here, then here, select that, etc. Besides pandering to the lowest common denominator isn't so great either.

Heh, I always found it much easier to compile things in windows.