The official "ZDoom on Linux" thread.

[Matt]

.....I just copypasted the stuff under "Debian/Ubuntu" here. :S

[Rachael]

Just fixed compilation on Raspberry Pi.


Enjoy - all 2 people who use it! (As a note - dpJudas ported a lot of these drawers to non-SSE2 variants - so real credit goes to him )

[Marisa the Magician]

Hey, it's 3 people!

Edit: It doesn't compile, I still get dozens of errors mentioning all the SSE stuff (all of it is from the poly renderer files).

[Rachael]

Ugh - those probably came from the recent round of poly renderer fixes. Well - it WAS working...

[Rachael]

ARM compile should be fixed, now.

If you use a Raspberry Pi 3, do note that passing -DUSE_ARMV8 to CMake should make it generate (slightly, maybe?) faster code, since it will tune Clang/GCC to compile for the ARMv8 processor. Don't do that on the RPi2 or you'll probably crash.

[Marisa the Magician]

Oh that doesn't matter. Apart from being the third Pi user, I'm also the one who somehow still has a RPi1.

Update: GL doesn't work and software is a 0.5 FPS slideshow. I guess I'll have to keep using chocolate doom instead...

[Rachael]

So for the 3 total people who use ZDoom on Raspberry Pi...

dpJudas recently got the OpenGL ES profile working. I managed to get it to run on Mesa, but haven't tried with actual hardware accelerated drivers, yet, since they are in such an experimental stage.

Some things you need to know:

In order to enjoy full hardware acceleration, the proper settings must be used, you must use OpenGL libraries when compiling, and you must have the proper accelerated drivers installed. (Some Raspberry Pi distributions do not have a hardware accelerated driver, or at the very least have it turned off by default for stability purposes - read your documentation on how to get it working) - there may be additional requirements that I do not know about. This is all brave new territory to me, so whoever tests this first will probably be the actual first to get this working.

This is a list of CVars you should know about when running hardware acceleration on the Pi:

vid_renderer 0/1: Software/OpenGL (It might go to Software on the Pi, just so you know)
gl_es 0/1: Requests the OpenGL ES context when starting. This defaults to 1 on Pi.
vid_glswfb 0/1: Only relevant with vid_renderer 0 - this requests an OpenGL hardware accelerated framebuffer in Software mode, similar to how Direct3D9 worked in ZDoom. Defaults to 0 - but we're changing it to default to 1 soon.

[vanhofen]

After a long time i built gzdoom again by myself on Debian. I followed the instructions from https://zdoom.org/wiki/Compile_GZDoom_on_Linux.
Compilation was fine (apart from a few -Wsign-compare and -Wmaybe-uninitialized warnings). But it won't start. What's wrong?

Code: Select all • Expand view

...
[ 99%] Built target lights_pk3
[100%] Building C object output_sdl/CMakeFiles/output_sdl.dir/output_sdl.c.o
Linking C shared module liboutput_sdl.so
[100%] Built target output_sdl
vanhofen@jessie:~/gzdoom_build/gzdoom/build$ ./gzdoom
GZDoom 2.5pre-369-g4f67dc4 - 2017-04-15 19:07:13 +0200 - SDL version
Compiled on Apr 15 2017

M_LoadDefaults: Load system defaults.
Can't find '/home/vanhofen/.config/gzdoom/nerve.wad'
W_Init: Init WADfiles.
 adding /home/vanhofen/gzdoom_build/gzdoom/build/gzdoom.pk3, 711 lumps
 adding /home/vanhofen/.config/gzdoom/DOOM2.WAD, 2935 lumps
I_Init: Setting up machine state.
CPU Vendor ID: GenuineIntel
  Name: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
  Family 6, Model 94, Stepping 3
  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.44.64
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.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 160.18 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Using video driver x11
GL_VENDOR: VMware, Inc.
GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits)
GL_VERSION: 3.0 Mesa 10.3.2 (Compatibility profile)
GL_SHADING_LANGUAGE_VERSION: 1.30

Max. texture size: 8192
Max. texture units: 16
Max. varying: 128
Max. uniform block size: 65536
Uniform block alignment: 16
Resolution: 640 x 480
Starting MIDI playback failed
*** Error in `./gzdoom': free(): invalid pointer: 0x0000000006e9e330 ***
Aborted
vanhofen@jessie:~/gzdoom_build/gzdoom/build$


[_mental_]

GL_VENDOR: VMware, Inc.
GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits)
GL_VERSION: 3.0 Mesa 10.3.2 (Compatibility profile)
GL_SHADING_LANGUAGE_VERSION: 1.30

Do you have graphics drivers installed? Or is it a virtual machine?

Using this commit it works fine on Ubuntu 16.04 but fails with the same error on Debian Jessie.
Although I'm running both under Virtual Box so it's not a real life test.

Callstack isn't quite informative because the failure point is located deeply inside DRI libraries.
Maybe it's a bug in old version of Mesa3D. This is the last line from our codebase.

[vanhofen]

Or is it a virtual machine?

Yes, it's a virtual machine using VMWare Player 12.5.4.

[_mental_]

You can try to enable hardware acceleration for VM. Or use -glversion 2 command line switch. Or use other distro in VM. Or install Debian on the real hardware.
In any case there is no much sense to spend more time on finding a workaround for so niche issue.
Even if it fails without VM the most feasible scenario would be to blacklist this driver and fallback to the legacy renderer.

[vanhofen]

Or use -glversion 2 command line switch

That works for me. Thank you.

[Marisa the Magician]

I'm going to be waiting on stuff like tinydrm and the xorg driver for the Pi's gpu to show up. I just want to see how things will turn out once I can get gpu-accelerated rendering with display on a touchscreen.

[Rachael]

I compiled a Raspberry Pi build of GZDoom 3.0 and Blzut3 stuck it into a .deb package for me: http://maniacsvault.net/loosefiles/gzdo ... _armhf.deb

This needs testing, mostly to see if it's feasible to distribute this as an official archive.

A few notes:

• It's compiled with Ubuntu Mate 16.04. The libraries "should" be reasonably dated enough that it will work with most other Debian-based distributions.
• It probably won't work with Raspbian unless you install Mesa OpenGL libraries.
• It's been tested to work on my system. I don't know if it will work on everyone else's. That's the point of asking for others to test it. In the end you all might be stuck compiling from source - but since that's a bit of a tedious process hopefully having some official binaries might be nice.
• This is 32-bit. Ubuntu Mate does not come with pre-imaged 64-bit distributions for the Pi. You mostly will have to assemble that yourself. (Have fun!) I figure if you're going to go that far, you're probably going to compile from source anyway - so there's no need, for now, for 64-bit builds until the system starts becoming officially supported.

[Caligari87]

In case anyone missed it in the code submission forum, I hacked together a simple autocomplete script for GZDoom on Linux.

Code: Select all • Expand view

_gzdoom()
{
    local cur prev opts
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    opts="-2 -4 -bits -width -height -blockmap -cdrom -config -iwad -nocdaudio -nomusic -nosfx -nosound -nostartup -oldsprites -savedir -avg -fast -nomonsters -respawn -timer -turbo -deh -bex -file -noautoload -loadgame -playdemo -record +playerclass -skill -timedemo -warp -warpwipe -xlat -0 -debugfile -devparm -hashfiles -noblit -nodraw -norun -stdout -altdeath -deathmatch -dup -extratic -host -join -net -netmode -port +set"

    if [[ ${cur} == -* ]] ; then
        COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
        return 0
    else
        _filedir
    fi
}
complete -o filenames -F _gzdoom gzdoom

Just put it in your .bashrc or in a file named "gzdoom" in /etc/bash_completion.d/. Isn't very fancy, but it works.