GZDoom 3.0.1 Released

News about ZDoom, its child ports, or any closely related projects.
[ZDoom Home] [Documentation (Wiki)]

GZDoom 3.0.1 Released

Postby Graf Zahl » Mon May 01, 2017 5:34 pm

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:
Last edited by Graf Zahl on Tue May 02, 2017 8:45 am, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.0.1 Released

Postby AFADoomer » Mon May 01, 2017 7:05 pm

Original post spoilered for irrelivancy... Nothing to see here.

Spoiler:
Last edited by AFADoomer on Mon May 01, 2017 7:11 pm, edited 3 times in total.
User avatar
AFADoomer
 
Joined: 15 Jul 2003

Re: GZDoom 3.0.1 Released

Postby Rachael » Mon May 01, 2017 7:08 pm

Done. Thank you for reporting that.
User avatar
Rachael
 
Joined: 13 Jan 2004

Re: GZDoom 3.0.1 Released

Postby Graf Zahl » Tue May 02, 2017 2:58 am

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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.0.1 Released

Postby FishyClockwork » Tue May 02, 2017 3:52 am

So as I understand it, I should not download this?
Nevermind.
User avatar
FishyClockwork
Military-grade bullshit specialist, apparently.
 
Joined: 23 Feb 2011
Location: 43 68 65 72 69 73 68 20 6c 69 66 65

Re: GZDoom 3.0.1 Released

Postby leodoom85 » Tue May 02, 2017 7:43 am

Downloading...let's see if I can find something 8-)
User avatar
leodoom85
Share your energy to the megasphere!!!
 
Joined: 14 Sep 2014
Location: Earth-shaking Chile
Discord: leodoom85#6202

Re: GZDoom 3.0.1 Released

Postby Glaice » Wed May 03, 2017 9:16 pm

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
Glaice
Ask me about Random Deaths & Decoration
 
Joined: 13 Mar 2009
Location: North Babylon, NY
Discord: 8512

Re: GZDoom 3.0.1 Released

Postby Hexereticdoom » Fri May 05, 2017 7:05 pm

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...)
User avatar
Hexereticdoom
Don't make me angry or I'll bite you! Heheheee...
 
Joined: 08 Aug 2013
Location: Spain

Re: GZDoom 3.0.1 Released

Postby _mental_ » Sat May 06, 2017 2:58 pm

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.
_mental_
 
Joined: 07 Aug 2011

Re: GZDoom 3.0.1 Released

Postby Graf Zahl » Sat May 06, 2017 3:06 pm

Have you found out what precisely was causing the performance issues or is it just MSVC vs. GCC?
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.0.1 Released

Postby _mental_ » Sat May 06, 2017 11:58 pm

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.
_mental_
 
Joined: 07 Aug 2011

Re: GZDoom 3.0.1 Released

Postby Graf Zahl » Sun May 07, 2017 3:15 am

_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?)
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.0.1 Released

Postby _mental_ » Sun May 07, 2017 3:55 am

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.
_mental_
 
Joined: 07 Aug 2011

Re: GZDoom 3.0.1 Released

Postby Graf Zahl » Sun May 07, 2017 4:35 am

_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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.0.1 Released

Postby stdh » Mon May 22, 2017 3:04 pm

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 allExpand view
(...)
[ 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.
stdh
 
Joined: 22 May 2017

Next

Return to ZDoom (and related) News

Who is online

Users browsing this forum: No registered users and 2 guests