DRD Team

Spoiler: The sad story ;-;

---

mallo sat quietly in his room. He tried to play Deus Vult II with his friend. He didn't knew what happened. Whenever he pressed the big ENTER button, the GZDoom loaded, and immediately crashed. The error said clearly:

Code: C0000005 - Access violation: tried to read access 00000000

He tried again. It happened again. So he tried one more time. And again. And again, and again, and again, again, again. Eventually he gave up. "But... it worked for me! Just few minutes ago!"
He decided to think of all things he done. The only thing that he did is add +vid_renderer 1 to his command line. He thought "it's ridiclous, but worth a try"... He changed the "1" to "0". And then... yes! It worked! He and his friend happily played, uh, 5 maps? However, mallo was left with the sad thought of "how good would that look in OpenGL renderer..."

Okay, so with vid_renderer 1 GZDoom (newest dev build, g8169991) crashes at startup. I included crash report.

(much?) Older version of GZDoom I still have on my hard drive (gfd76723) works perfectly fine (hehe, not really, but that's case for an another report :3: ). No crashes. Is it related to that modern-gl thingie I heard about?

The graphic card is "ATI RADEON XPRESS 200 Series". I know it sucks (it was built in, duh) but hey, older versions didn't crash.

It seems that your problem is the graphics card/ATI driver

GL_VENDOR: ATI Technologies Inc.\par
GL_RENDERER: RADEON XPRESS Series x86/SSE2\par
GL_VERSION: 2.0.6119 WinXP Release\par
GL_SHADING_LANGUAGE_VERSION: 1.10\par

As you know, Graf Zahl endeavours to constantly improve the GZDoom OpenGL render engine.

If I remember correctly, newer versions of GZDoom need support for OpenGL 3.0 or better.
GZDoom 2.0.02 betas need support for OpenGL 4.0.

The moral of the story is, you are stuck with older versions of GZDoom or you have to aquire
a new videocard which is capable to support the appropriate version of OpenGL.

Damn. Anyways, thanks for the help.

I still wonder why it crashes. That driver seems to lack a feature that's essential for the init code to determine that it can't start up at all.
But anyway, no point supporting GL 2.x any further as it'd mean too many compromises with the shader stuff.

GZDoom 2.x will require OpenGL version 3.3 at least. I probably can get it down to GL 3.2 with a few extensions required. But as all supported AMD/ATI and Nvidia GPUs have GL 3.3 driver support this seems kind of pointless as all drivers supporting the 3.3 extensions also support full GL 3.3.

I'm having a similar problem, so I figured I'd reply here. Sorry if I'm hijacking the topic, but I figure it didn't quite warrant a new one. My problem is a little different, though.

Spoiler: GZdoom output

---

Code: Select all

GZDoom g2.0.02 - 2014-08-19 18:06:45 +0200 - SDL version
Compiled on Sep 19 2014
Using video driver x11

M_LoadDefaults: Load system defaults.
Gameinfo scan took 0 ms

(gzdoom:18278): Gtk-WARNING **: Theme directory 128/128/apps of theme Numix-Bevel has no size field

W_Init: Init WADfiles.
 adding /usr/share/games/gzdoom/gzdoom.pk3, 586 lumps
 adding /home/paul/wad/iwad/DOOM2.WAD, 2919 lumps
I_Init: Setting up machine state.
CPU Vendor ID: AuthenticAMD
  Name: AMD E2-1800 APU with Radeon(tm) HD Graphics
  Family 20 (20), Model 2, Stepping 0
  Features: MMX MMX+ SSE SSE2 SSE3 SSSE3
I_InitSound: Initializing FMOD
FMOD Sound System, copyright � Firelight Technologies Pty, Ltd., 1994-2009.
Loaded FMOD version 4.26.36
OSS 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.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading default status bar definition.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Unsupported OpenGL version.
At least OpenGL 3.3 is required to run GZDoom.



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

Apparently it thinks my OpenGL is old. However! If you take a look at the output of my glxinfo:

Spoiler: glxinfo output

---

Code: Select all

$ glxinfo | grep -i opengl
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PALM
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.7
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.7
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:

I have exactly the version required, but GZDoom doesn't think so. I'm using the open-source Radeon drivers on Arch Linux, everything up to date. Pre-2.0 versions of GZDoom worked fine, and all of my hardware/software should be new enough (as far as I can tell). And yes, direct rendering is also enabled; other OpenGL apps/games work fine, and I have a compositor running.

deltaphc wrote: I have exactly the version required, but GZDoom doesn't think so. I'm using the open-source Radeon drivers on Arch Linux, everything up to date. Pre-2.0 versions of GZDoom worked fine, and all of my hardware/software should be new enough (as far as I can tell). And yes, direct rendering is also enabled; other OpenGL apps/games work fine, and I have a compositor running.

No, you did not.

The GZDoom version you used said it requires GL 3.3, your driver reports 3.0. Please retry with something newer, the requirement has been lowered to 3.0 in the mean time.
The problem with the Mesa driver is that it suports only the core profile for 3.3, which is of no use to GZDoom.

I know it works with the open source radeon drivers on Arch, at least as of Mesa 10.2. It won't work with GZDoom 2.0.2 though, but WILL work with GZDoom 2.0.3. It works with the new Mesa 10.3 in testing as well. In fact, I'm actually pretty happy with how well it does work.

I think I found the cause of this crash but since I don't have such an old graphics card I can't test it.