GZDoom 3.0.1 Released

News about ZDoom, its child ports, or any closely related projects.
[ZDoom Home] [Documentation (Wiki)] [Official News] [Downloads] [Discord]
[🔎 Google This Site]

Moderator: GZDoom Developers

User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48334
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

GZDoom 3.0.1 Released

Post by Graf Zahl »

This is a bugfix release which addresses the following:

- potential crash when changing the render output in-game and continue playing
- crash in the software renderer with camera textures
- for 32 bit Windows libsndfile.dll is reverted to the old version due to some incompatibility with the newer one
- cleanup of dynamic light options

Downloads:
  • removed
Last edited by Graf Zahl on Tue May 02, 2017 7:45 am, edited 1 time in total.
User avatar
AFADoomer
Posts: 1272
Joined: Tue Jul 15, 2003 4:18 pm

Re: GZDoom 3.0.1 Released

Post by AFADoomer »

Original post spoilered for irrelivancy... Nothing to see here.
Spoiler:
Last edited by AFADoomer on Mon May 01, 2017 6:11 pm, edited 3 times in total.
User avatar
Rachael
Admin
Posts: 13089
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 3.0.1 Released

Post by Rachael »

Done. Thank you for reporting that.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48334
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 3.0.1 Released

Post by Graf Zahl »

Damnit, looks like it got write-blocked by some crash again. I have no idea why this constantly happens. That .pk3 was from the master branch and apparently not rebuilt when compiling the maint branch.
User avatar
FishyClockwork
Posts: 731
Joined: Wed Feb 23, 2011 11:04 am
Preferred Pronouns: No Preference

Re: GZDoom 3.0.1 Released

Post by FishyClockwork »

So as I understand it, I should not download this?
Nevermind.
User avatar
leodoom85
Posts: 684
Joined: Sun Sep 14, 2014 6:40 pm
Location: Earth-shaking Chile

Re: GZDoom 3.0.1 Released

Post by leodoom85 »

Downloading...let's see if I can find something 8-)
User avatar
Armaetus
Posts: 1252
Joined: Fri Mar 13, 2009 3:55 pm
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: New York State

Re: GZDoom 3.0.1 Released

Post by Armaetus »

Things are all up to spec with the mods used, and no need for WIDESTBAR.WAD now. :) That and the Blinkmod was recently updated to work with 3.x now.
User avatar
Hexereticdoom
Posts: 613
Joined: Thu Aug 08, 2013 1:30 pm
Graphics Processor: nVidia with Vulkan support
Location: Spain

Re: GZDoom 3.0.1 Released

Post by Hexereticdoom »

Hello, will be available soon a GZDoom 3.0.2 update? :?:

Just asking because I have had to turn back to previous 2.4.0 which feels more stable and bug-free than the most recent 3.0.x releases... (And yes, I still miss FMOD EX a little...)
_mental_
 
 
Posts: 3784
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 3.0.1 Released

Post by _mental_ »

For those who still blames OpenAL for greatly decreased sound loading speed and stuttering while in-game because of that:
I built drop-in replacement for libsndfile-1.dll file from GZDoom distribution.
And please stop thinking that OpenAL is causing you such problems, this is not true.

You can grab DLLs here: 32-bit and 64-bit.

Installation is simple:
Rename original libsndfile-1.dll file to anything you want and unpack DLL with corresponding bit-ness instead of it.

My tests with D4D shown that these 1.0.29pre DLLs (compiled with MSVC2015) are from two to 2.5 times faster than 1.0.28 from developer's site (built with MinGW).
Original DLLs apparently have some performance issues and it seems like used toolchain is causing them.
FMOD backend was from 10 to 30 percent faster in loading of Ogg/Vorbis files than OpenAL now, i.e. no more two or three times slower .ogg loading in GZDoom 3.0.
There is still a room to improve of course but let's do it step by step.

So, I need volunteers to test these unofficial DLLs in order to verify their suitability.
We definitely need to do something with the mentioned performance issues and this is the first step in that direction.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48334
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 3.0.1 Released

Post by Graf Zahl »

Have you found out what precisely was causing the performance issues or is it just MSVC vs. GCC?
_mental_
 
 
Posts: 3784
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 3.0.1 Released

Post by _mental_ »

This call is much slower in released DLLs than in mine.
I found nothing in commits history that can explain such difference.

At the same time searching for performance bottlenecks in 1.5 MB library without debug information is out of scope for me.
In conjunction with alignment issue in 32-bit DLL I suggest to do not use binary files from developer at all.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48334
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 3.0.1 Released

Post by Graf Zahl »

_mental_ wrote: In conjunction with alignment issue in 32-bit DLL I suggest to do not use binary files from developer at all.
Yes, I have concluded as much. It seems that GCC is not the best compiler to compile libraries for Windows anymore, if they did not even bother to ensure that their ABI is compatible with the Windows system.

About the slowdown, hard to tell, because it appears to be in both 1.0.27 and 1.0.28 so it cannot be SSE. Maybe the toolchain is set up to compile some stuff unoptimized? It's really the only thing I can imagine.

About the 10-30% advantage of FMOD, maybe that's because GZDoom's loaders perform an added conversion from float to 16 bit? If I understand the comments correctly, that was done to circumvent some problem with libsndfile (sounds somewhat familiar, doesn't it?)
_mental_
 
 
Posts: 3784
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 3.0.1 Released

Post by _mental_ »

Graf Zahl wrote:About the slowdown, hard to tell, because it appears to be in both 1.0.27 and 1.0.28 so it cannot be SSE. Maybe the toolchain is set up to compile some stuff unoptimized? It's really the only thing I can imagine.
I didn't say that the performance issue is related to SSE. 1.0.27 doesn't use these instructions while 1.0.28 has the same performance with them.
I meant that we already experienced two independent problems with DLLs built by MinGW. And we are using only a relatively small subset of library's functions.

By the way GCC produces ABI-compatible binaries.
Crash in 32-bit DLL was caused by improper alignment inside stack which is a code generation bug.
Graf Zahl wrote:About the 10-30% advantage of FMOD, maybe that's because GZDoom's loaders perform an added conversion from float to 16 bit? If I understand the comments correctly, that was done to circumvent some problem with libsndfile (sounds somewhat familiar, doesn't it?)
The first culprit of FMOD's performance advantage is down-mixing to mono in OpenAL backend.
This especially important for 5+ seconds 44.1 kHz/16bit stereo sounds as they are loaded in OpenAL buffers twice.
I hope Chris will handle this with a special OpenAL extension soon.

I'm not an expert in Vorbis library but it seems samples are handled as floats internally. So I guess this doesn't cause a slowdown.
Conversion of floats to shorts can be optimized too. At the moment I cannot say about its cost in overall processing time though.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48334
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 3.0.1 Released

Post by Graf Zahl »

_mental_ wrote: Crash in 32-bit DLL was caused by improper alignment inside stack which is a code generation bug.
Wanna bet that the GCC people will heavily deny this and blame other compilers not being compatible with their own code...? :mrgreen:
Of the major compilers it has nearly always been GCC which was having code generation issues.
stdh
Posts: 4
Joined: Mon May 22, 2017 1:47 pm

Re: GZDoom 3.0.1 Released

Post by stdh »

Hello all. Not sure if this is the right place to put this, but anyway:
I gathered that GZDoom is now GPL'ed, so I thought to give it a spin. However, upon compiling on my near-ancient i386 box (Debian testing) I get this error:

Code: Select all

(...)
[ 67%] Building CXX object src/CMakeFiles/zdoom.dir/g_statusbar/shared_sbar.cpp.o
In file included from /home/steven/archief/gamen/Doom/gzdoom/gzdoom-g3.0.1/src/./m_bbox.h:32:0,
                 from /home/steven/archief/gamen/Doom/gzdoom/gzdoom-g3.0.1/src/./r_defs.h:35,
                 from /home/steven/archief/gamen/Doom/gzdoom/gzdoom-g3.0.1/src/./v_collection.h:38,
                 from /home/steven/archief/gamen/Doom/gzdoom/gzdoom-g3.0.1/src/g_statusbar/sbar.h:39,
                 from /home/steven/archief/gamen/Doom/gzdoom/gzdoom-g3.0.1/src/g_statusbar/shared_sbar.cpp:39:
/home/steven/archief/gamen/Doom/gzdoom/gzdoom-g3.0.1/src/./m_fixed.h: In function ‘void DBaseStatusBar::DrawCrosshair()’:
/home/steven/archief/gamen/Doom/gzdoom/gzdoom-g3.0.1/src/./m_fixed.h:29:5: error: ‘asm’ operand has impossible constraints
    );
     ^
src/CMakeFiles/zdoom.dir/build.make:5268: recipe for target 'src/CMakeFiles/zdoom.dir/g_statusbar/shared_sbar.cpp.o' failed
make[2]: *** [src/CMakeFiles/zdoom.dir/g_statusbar/shared_sbar.cpp.o] Error 1
CMakeFiles/Makefile2:788: recipe for target 'src/CMakeFiles/zdoom.dir/all' failed
make[1]: *** [src/CMakeFiles/zdoom.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
That was with the standard Release profile. I read someplace that such asm errors may be related to optimization, so I tried a Debug build and that just works. All else is looking good.

Return to “ZDoom (and related) News”