GZDoom 3.0.1 Released

[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

[AFADoomer]

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

---

I think the 64-bit build has the wrong gzdoom.pk3 included.

I get lots of ZScript parsing errors and fatal error halt:

Code: Select all

gzdoom.pk3:zscript/base.txt, line 45: The member variable '.LocalViewPitch' has not been exported from the executable.
gzdoom.pk3:zscript/base.txt, line 517: The member variable 'LevelLocals.allowrespawn' has not been exported from the executable.
gzdoom.pk3:zscript/shared/player.txt, line 4: The member variable 'UserCmd.buttons' has not been exported from the executable.
gzdoom.pk3:zscript/shared/player.txt, line 5: The member variable 'UserCmd.Pitch' has not been exported from the executable.
gzdoom.pk3:zscript/shared/player.txt, line 6: The member variable 'UserCmd.yaw' has not been exported from the executable.
gzdoom.pk3:zscript/shared/player.txt, line 7: The member variable 'UserCmd.Roll' has not been exported from the executable.
gzdoom.pk3:zscript/shared/player.txt, line 8: The member variable 'UserCmd.forwardmove' has not been exported from the executable.
gzdoom.pk3:zscript/shared/player.txt, line 9: The member variable 'UserCmd.sidemove' has not been exported from the executable.
gzdoom.pk3:zscript/shared/player.txt, line 10: The member variable 'UserCmd.upmove' has not been exported from the executable.
gzdoom.pk3:zscript/base.txt, line 535: The function 'LevelLocals.IsJumpingAllowed' has not been exported from the executable
gzdoom.pk3:zscript/base.txt, line 536: The function 'LevelLocals.IsCrouchingAllowed' has not been exported from the executable
gzdoom.pk3:zscript/base.txt, line 537: The function 'LevelLocals.IsFreelookAllowed' has not been exported from the executable
gzdoom.pk3:zscript/actor.txt, line 545: The function 'Actor.CheckFakeFloorTriggers' has not been exported from the executable
gzdoom.pk3:zscript/shared/player.txt, line 1271: The function 'PlayerPawn.CheckMusicChange' has not been exported from the executable
gzdoom.pk3:zscript/shared/player.txt, line 1272: The function 'PlayerPawn.CalcHeight' has not been exported from the executable
gzdoom.pk3:zscript/shared/player.txt, line 1273: The function 'PlayerPawn.CheckEnvironment' has not been exported from the executable
gzdoom.pk3:zscript/shared/player.txt, line 1274: The function 'PlayerPawn.CheckUse' has not been exported from the executable
gzdoom.pk3:zscript/shared/player.txt, line 1275: The function 'PlayerPawn.CheckWeaponButtons' has not been exported from the executable
gzdoom.pk3:zscript/shared/player.txt, line 1276: The function 'PlayerPawn.BestWeapon' has not been exported from the executable

Replacing the pk3 with the one from the 32-bit build resolves the issue.

[Rachael]

Done. Thank you for reporting that.

[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.

[Fishytza]

So as I understand it, I should not download this?
Nevermind.

[leodoom85]

Downloading...let's see if I can find something

[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.

[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_]

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.

[Graf Zahl]

Have you found out what precisely was causing the performance issues or is it just MSVC vs. GCC?

[_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.

[Graf Zahl]

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_]

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.

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.

[Graf Zahl]

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...?
Of the major compilers it has nearly always been GCC which was having code generation issues.

[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.