Package Details: gzdoom 2.1.1-2

Git Clone URL: https://aur.archlinux.org/gzdoom.git (read-only)
Package Base: gzdoom
Description: Advanced Doom source port with OpenGL support
Upstream URL: http://www.zdoom.org/
Licenses: BSD, LGPL, custom:dumb, custom:BUILD, custom:doom
Submitter: None
Maintainer: grubber
Last Packager: grubber
Votes: 48
Popularity: 1.175720
First Submitted: 2009-02-22 22:28
Last Updated: 2016-05-27 06:50

Dependencies (29)

Required by (1)

Sources (2)

Latest Comments

allcaps commented on 2016-03-05 08:13

The fmodex version this requires is not available by the standard fmodex AUR entry. There's one named differently here: https://aur.archlinux.org/packages/fmodex4.26.36 that is the exact version needed.

If you replace the fmodex entry at the top of the pkgbuild with that one instead this builds and works fine, sound and all.

zanny commented on 2016-03-04 02:08

Note that kdialog replaces gxmessage (it is the kde xmessage implementation), so only one or the other is required.

grubber commented on 2016-03-03 21:07

Fmodex can't be an optdepend - optdepends are for *runtime* optional dependencies, but fmodex is a *build-time* optional dependency - if you build the package with fmodex, the gzdoom binary will be linked to libfmodex, so uninstalling it would break the binary, which is not correct. You can choose whether to build with or without fmodex using the _fmodex variable at the top of the PKGBUILD, ditto for openal.

There is no harm in defining SHARE_DIR in CFLAGS and it keeps CFLAGS consistent with CXXFLAGS. The SHARE_DIR patch is there to support the IWAD symlinks included in the package, which are there so you can put retail IWADs to your user IWAD directory without hiding IWADs of the same name provided by the freedoom and hexen1-wad packages. I suppose putting the symlinks into the libdir should work equally well, which would obsolete the patch.

Didn't know about kdialog, will fix.

zanny commented on 2016-03-03 15:01

Some observations after having maintained the alternate 2.1 while waiting for the update:

fmod and openal are technically optional, but without either you have no sound. Since openal is in the upstream official repos while fmod is not, I'd advocate making fmod an optdepend.

You don't need to specify SHARE_DIR on cflags, it is only used on cxxflags. I'd also argue the patch to include SHARE_DIR in the iwad search path is unnecessary - you are supposed to install the main game iwads either with pacman in /usr/local?/share/games?/doom - every AUR package for an iwad uses /usr/share/doom. The extra files gzdoom uses are not iwads, they just need to be on the file search path which is what SHARE_DIR is for in the first place.

Also, kdebase-kdialog is an optdepend and gzdoom will use it for its launcher if available over the gtk alternative, which should also probably be an optdepend.

grubber commented on 2016-03-03 07:05

Updated. Sorry for the delay - I rewrote the PKGBUILD, OpenAL is now supported, among other improvements and fixes.

remussatala commented on 2016-02-19 03:59

http://debian.drdteam.org/pool/multiverse/g/
gzdoom
gzdoom1

zanny commented on 2016-02-18 00:17

Wanted to install 2.1 on several computers so I just forked the pkg and dropped the patches here:

https://aur.archlinux.org/packages/gzdoom-2.1/

I have notifications on so I'll delete it whenever grubber updates here.

MadTux commented on 2016-02-08 08:44

Do you think you could update to 2.1.0?

http://forum.drdteam.org/viewtopic.php?f=23&t=6791

ozky commented on 2015-12-04 15:30

Yes it needed i got my own way to do it.......Builded it in seperate system and extracted it to local folder and added it to enyo doom as it can use manually added doom engine,no gtk but brutal doom and lot others get working. :)

grubber commented on 2015-11-30 19:02

gtk2 is required for the IWAD selection dialog and gxmessage is needed for the crash log window. Both are features I want in the build to be on par with the official Windows build, so they won't be removed, sorry.

ozky commented on 2015-11-30 18:44

You may grubber add gtk2 require as optional it's only needed to gui as without it you can use it with enyo-doom.

http://zdoom.org/wiki/Compile_GZDoom_on_Linux
GTK2 (optional)

pacman -S --needed gcc make zlib sdl sdl2 libjpeg-turbo nasm tar bzip2 gtk2 cmake git \
fluidsynth libgme openal timidity++ mesa glu glew

I compiled it with removing gtk2 and gxmessage from pkgbuild and it compiles with no error.

jclaudio commented on 2015-10-09 06:07

I cannot use this because of fmodex4.26.36

Anyone else having this problem?

claymore commented on 2015-03-10 16:43

wrong SDL lib dependency. It should be SDL2. Because of that, it does not compile out of the box.

Fincer commented on 2015-02-06 02:30

Thank you for informing me about the GIT version you already have available here.

Well, let me clarify: The current PKGBUILD script grabs correct gzdoom version from Github. However, the problem is that if pure tar.gz archive is used, gzdoom doesn't recognize version number correctly, leading to <unknown version> issue.

[fincer@fincer-laptop fincer]$ gzdoom
GZDoom <unknown version> - - SDL version
Compiled on Feb 6 2015
Using video driver x11

And this is what I refer to when talking about "messes with version numbering".

I asked GZDoom developer Graf Zahl about this issue and he stated:

"Do you have the git command line utilities installed? The broken version number suggests you have not. With this you can also retrieve the source for any branch or tag, including the release versions."

Doing the installation by suggested git way gets the version number shown correctly in the program, too. Regardless of available tar.gz archives in Github. That's why I think git way is the only correct way to install this package - unless you want <unknown version> to be visible while running the program.

Otherwise, the current compilation script works very fluently and builds gzdoom version 2.0.04 as suggested in the AUR package title. As you already said.

Fincer commented on 2015-02-06 02:12

Yes, and that that "release tarball" doesn't contain version numbering for the program itself. The current compilation method leads to <unknown version> which is not desirable functionality:

[fincer@fincer-laptop fincer]$ gzdoom
GZDoom <unknown version> - - SDL version
Compiled on Feb 6 2015
Using video driver x11

GZDoom developer Graf Zahl stated when asked about <unknown version> (got by compiling with the current tar.gz method):

"Do you have the git command line utilities installed? The broken version number suggests you have not. With this you can also retrieve the source for any branch or tag, including the release versions."

And doing the installation by suggested git way gets the version number shown correctly. Regardless of available tar.gz archives in Github.

[fincer@fincer-laptop gzdoom]$ gzdoom
GZDoom g2.0.04 - 2014-12-21 14:58:11 +0100 - SDL version
Compiled on Feb 4 2015
Using video driver x11

Fincer commented on 2015-02-06 02:06

Yes, and that that "release tarball" doesn't contain version numbering for the program itself. Your current method leads to <unknown version> which is not desirable functionality:

[fincer@fincer-laptop fincer]$ gzdoom
GZDoom <unknown version> - - SDL version
Compiled on Feb 6 2015
Using video driver x11

GZDoom developer stated when asked about <unknown version> (got by compiling with your tar.gz method):

"Do you have the git command line utilities installed? The broken version number suggests you have not. With this you can also retrieve the source for any branch or tag, including the release versions."

And doing the installation by suggested git way gets the version number shown correctly. Regardless of available tar.gz archives in Github.

[fincer@fincer-laptop gzdoom]$ gzdoom
GZDoom g2.0.04 - 2014-12-21 14:58:11 +0100 - SDL version
Compiled on Feb 4 2015
Using video driver x11

grubber commented on 2015-02-04 21:36

The PKGBUILD doesn't mess with anything, it uses only what is provided in the release tarball. If you want to build from git, you should use <https://aur.archlinux.org/packages/gzdoom-git/>.

Fincer commented on 2015-02-04 00:05

At the moment PKGBUILD messes with GZDoom version numbering, resulting to a <unknown version>. Instead of using tar.gz package (which is presented in the current PKGBUILD file), the package must be built with git method. I corrected the PKGBUILD file for those who want the correct GZDoom version number shown when launching the program.

See fixed PKGBUILD file for GZDoom 2.0.04 + all versions 1.8.5 and above here:

http://forum.drdteam.org/viewtopic.php?f=22&t=6524&p=56382#p56382

Fincer commented on 2015-02-03 23:54

At the moment PKGBUILD messes with GZDoom version numbering, resulting to a <unknown version>. Instead of using tar.gz package (which is presented in the current PKGBUILD file), the package must be built with git method. I corrected the PKGBUILD file for those who want the correct GZDoom version number shown when launching the program.

Also, the current PKGBUILD script lacks of FMOD Library compilation which should be included. I added compilation of the FMOD library to the PKGBUILD.

See fixed PKGBUILD file for GZDoom 2.0.04 + all versions 1.8.5 and above here:

http://forum.drdteam.org/viewtopic.php?f=22&t=6524&p=56382#p56382

Fincer commented on 2015-02-02 21:17

At the moment PKGBUILD messes with GZDoom version numbering, resulting to a <unknown version>. Instead of using tar.gz package (which is presented in the current PKGBUILD file), the package must be built with git method. I corrected the PKGBUILD file for those who want the correct GZDoom version number shown when launching the program. See fixed PKGBUILD file for GZDoom 2.0.04 here:

http://forum.drdteam.org/viewtopic.php?f=22&t=6524&p=56382#p56382

remussatala commented on 2014-09-25 08:22

If the first link for gm.sf2 is not work, use this link:
https://app.box.com/s/ewa6p5d21rf9uly6ator

grubber commented on 2014-09-24 21:11

Updated to 2.0.03. See also <https://aur.archlinux.org/packages/gzdoom1/> for 1.8.7.

zanny: You can report bugs at <http://forum.drdteam.org/viewforum.php?f=24>.

zanny commented on 2014-09-22 01:14

So yeah, a lot of breakage in gz 2.0 with the Mesa drivers:

By default, it is using a compatibility profile and does not recognize core profiles supporting 3.3, so it just says "get GL 3.3".

If you override the Mesa version string with 3.3, it tries to use GLSL 4.0 shaders.

If you use the arg -gl3 to force 3.3, it fails to compile some fragment shader.

And I can't even find the gzdoom bug tracker. It isn't off their github repo and my google-fu is failing me.

remussatala commented on 2014-09-21 18:44

http://forum.drdteam.org/viewtopic.php?f=23&t=6398&sid=7693a043a7d4b804ef99fe932a76c6e1
http://forum.drdteam.org/viewtopic.php?f=23&t=6397&sid=7693a043a7d4b804ef99fe932a76c6e1

remussatala commented on 2014-09-11 17:26

If you want the original midi windows you can use this soundfont:
https://docs.google.com/file/d/0BypDM7HzdnkjcW5mRllVRS12eWc/edit

remussatala commented on 2014-09-11 09:40

Now I use GZdoom 1.8.6. Is ok. I created only for myself gzdoom-aur and chose version 1.8.6.

chungy commented on 2014-09-11 02:13

Instead of cloning the git repository, I suggest instead using https://github.com/coelckers/gzdoom/archive/g${pkgver}.tar.gz in the source array, and doing "cd gzdoom-g${pkgver}" in the build() function. Should be much faster to download, and puts less strain on GitHub's servers.

remussatala commented on 2014-09-10 22:53

:)
Unsupported OpenGL version.
At least OpenGL 3.3 is required to run GZDoom.

*** Fatal Error ***
!!! Failed to exec debug process
Segmentation fault (core dumped)

I have OpenGL 3.1 :D Intel® HD Graphics 2000

remussatala commented on 2014-09-09 23:54

GZdoom just been updated.
https://github.com/coelckers/gzdoom/releases
The stable version is 2.0.02.

grubber commented on 2014-05-25 18:50

Yes, but see the note about base-devel at https://wiki.archlinux.org/index.php/PKGBUILD#makedepends

zanny commented on 2014-05-24 10:45

patch is one of the dependencies of this package, since you are.. providing patches. I didn't have it until I was building gzdoom, surprisingly.

grubber commented on 2013-08-23 16:11

Hmm, I must have been looking at a different PKGBUILD. Mae culpa. Fixed.

miffe commented on 2013-08-14 16:24

@grubber: No git in makedepends, only subversion...

grubber commented on 2013-08-14 14:54

miffe: git already is in makedepends.

larsoyvind: thanks for the heads up! Fixed.

larsoyvind commented on 2013-08-10 22:17

The fmod source url has changed, please update to:
http://www.fmod.org/download/fmodex/api/Linux/fmodapi${_fmodver}${_fmodarch}.tar.gz

larsoyvind commented on 2013-08-10 22:15

The fmod source url has changed, please update to:
http://www.fmod.org/download/fmodex/api/Linux/fmodapi${_fmodver}${_fmodarch}.tar.gz

As the package takes some time building I'd suggest inserting something like:
read -p "Build complete, press [Enter] key to install package..."
...at the end of building, as pacman has a tendency to time out before I realize building is complete.

miffe commented on 2013-07-17 17:06

/usr/bin/makepkg: line 583: git: command not found

Please add git to makedepends

z33ky commented on 2013-03-31 16:57

I have not had gzdoom installed before. I tried rebuilding, but that didn't fix it.

I will try the zdoom forums, as I get the same problem there it seems likely that gzdoom inherits whatever is wrong from it.
http://forum.zdoom.org/viewtopic.php?f=2&t=35866

grubber commented on 2013-03-31 09:02

I was not able to reproduce that. But it seems like if you were using gzdoom.pk3 from a different version of gzdoom.

z33ky commented on 2013-03-30 15:37

That fixes the paths, but the Script errors remain.
Tested with The Ultimate Doom, Doom 2 and the Doom demo (doom1-wad in AUR).

grubber commented on 2013-03-30 14:31

It was a bug in the package(s), which caused initial config file to point at a wrong path to look for gzdoom.pk3. Remove the bad config file in ~/.config/gzdoom and gzdoom will generate a new one for you.

z33ky commented on 2013-03-28 00:19

$ gzdoom
GZDoom v1.7.1 - SVN revision 0 - SDL version
Compiled on Mar 28 2013
Using video driver x11

M_LoadDefaults: Load system defaults.
Cannot find gzdoom.pk3
$ cd /usr/share/games/gzdoom
$ gzdoom
GZDoom v1.7.1 - SVN revision 0 - SDL version
Compiled on Mar 28 2013
Using video driver x11

M_LoadDefaults: Load system defaults.
Gameinfo scan took 0 ms
Cannot find a game IWAD (doom.wad, doom2.wad, heretic.wad, etc.).
Did you install ZDoom properly? You can do either of the following:

1. Place one or more of these wads in the same directory as ZDoom.
2. Edit your zdoom-username.ini and add the directories of your iwads
to the list beneath [IWADSearch.Directories]
$ DOOMWADDIR=~/.gzdoom gzdoom
GZDoom v1.7.1 - SVN revision 0 - SDL version
Compiled on Mar 28 2013
Using video driver x11

M_LoadDefaults: Load system defaults.
Gameinfo scan took 0 ms
W_Init: Init WADfiles.
adding ./gzdoom.pk3, 583 lumps
adding /home/z33ky/.gzdoom/doom.wad, 2306 lumps
I_Init: Setting up machine state.
CPU Vendor ID: GenuineIntel
Name: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz
Family 6, Model 37, Stepping 2
Features: MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
I_InitSound: Initializing FMOD
FMOD Sound System, copyright � Firelight Technologies Pty, Ltd., 1994-2009.
Loaded FMOD version 4.26.36
HOSS could not be initialized. Trying ALSA.
V_Init: allocate screen.
S_Init: Setting up sound.
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
GScript error, "gzdoom.pk3:mapinfo/doom1.txt" line 54:
GUnknown property 'sucktime' found in map definition

... and lots more of those Script errors, Unknown property. In the end it won't start.
The selection window does show and I selected the doom.wad, then these errors spew and that's it.

Same with gzdoom-svn and zdoom.
Should I take this upstream? If so, to GZDoom or ZDoom?

grubber commented on 2012-12-30 10:07

Fixed. I wish there was a better way of handling per-arch source files.

miffe commented on 2012-12-30 03:42

Fails to build since the PKGBUILD has the same md5sum for both the i686 and x86_64 version of fmod.

OrdinaryMagician commented on 2012-11-19 14:08

Could you please also add this fix to the svn version of the package?

grubber commented on 2012-11-07 21:38

Fixed. Sorry for the delay.

DullOnion commented on 2012-11-05 02:04

Changing the checksum from '9b1af4ae3352fbe147c72c8430df74cd' to 'b83251d0f6e06b360711b152f299ef23' in the PKGBUILD will fix that error. However, it stops compiling at 36% due to this error:

[ 36%] Building CXX object src/CMakeFiles/zdoom.dir/sdl/hardware.o
In file included from /tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/gl/system/gl_system.h:94:0,
from /tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/sdl/sdlglvideo.h:7,
from /tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/sdl/hardware.cpp:48:
/tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/gl/system/gl_interface.h:206:2: error: ‘PFNGLMULTITEXCOORD2FPROC’ does not name a type
/tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/gl/system/gl_interface.h:207:2: error: ‘PFNGLMULTITEXCOORD2FVPROC’ does not name a type
make[2]: *** [src/CMakeFiles/zdoom.dir/sdl/hardware.o] Error 1
make[1]: *** [src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [all] Error 2

Anonymous comment on 2012-11-04 06:42

I get the same error as ZeroKnight unfortunately.

ZeroKnight commented on 2012-10-17 21:36

==> Validating source files with md5sums...
fmodapi43818linux64.tar.gz ... FAILED
gzdoom-1.6.00-sharedir.patch ... Passed
gzdoom.desktop ... Passed
==> ERROR: One or more files did not pass the validity check!

grubber commented on 2010-07-31 13:30

It might be a driver problem, or the feature simply isn't implemented for Linux. Better ask at the GZDoom forum. (http://forum.drdteam.org/viewforum.php?f=22)

jackoneill commented on 2010-07-31 11:00

Does the F11 key (gamma correction) have any effect for you guys? It doesn't do anything on my system. I see the messages at the top of the screen with the increasing value (between 1 and 3), but it has no effect on the image.

What could be the problem?

grubber commented on 2010-07-29 08:41

Sorry. Fixed.

miffe commented on 2010-07-29 01:57

fmodapi42816linux.tar.gz fails the md5sum check.

grubber commented on 2010-07-27 17:49

Updated. Included fmodex lib in the package, as it's not API compatible between versions and updates to the fmodex package (which is now in the community repo) break compilation/sound in gzdoom. Also cleaned up the PKGBUILD and fixed all errors reported by namcap.

jackoneill commented on 2010-05-22 16:19

The build fails at around 88% with this error:
"/tmp/clyde-asdf/gzdoom/gzdoom/src/gzdoom-1.4.08-build/src/sound/fmodsound.cpp:170:23: error: ‘FMOD_OUTPUTTYPE_SOUNDMANAGER’ was not declared in this scope"

Downgrading fmodex from 4.30.02 to 4.28.13 fixed it for me.

grubber commented on 2010-04-24 09:13

Updated.

Ulukai commented on 2010-04-23 12:31

Will this package be updated to the latest version please?