GZDoom 4.4.0 released

[Nash]

It should probably go without saying that all files within a GZDoom release package must work together - you shouldn't mix files from different versions. :) This is why I usually just overwrite everything when extracting the GZDoom package over my current installation.

(sometimes I just wipe everything and do a fresh install anyway, heh)

[Barry Burton]

Thanks so much for the tips, folks. It turns out that (surprise, surprise!) it was user error on my behalf. I had a very minor mod running on explosive barrels. I renamed the GLDef I'd created for the new sprite and all's well now.

Thanks again. I'm now a happy chappy.

[openroadracer]

I know I'm late on this; but yeah, V4.4.0 has broken a texture pack that I'd taken quite a liking to: https://www.dropbox.com/s/jotsqndtshe0v ... k.pk3?dl=0 It's kind of a shame, really.

[sinisterseed]

(sometimes I just wipe everything and do a fresh install anyway, heh)

This is what I do with all ports I'm running, actually, be that Raze, NBlood, GDX, vkQuake, and so and so on, because overwriting files while keeping the same config can lead to all sorts of oddities sometimes, especially when upgrading from ancient versions - I know performance regressions are one.

So I always clean install when upgrading. Always.

[Enjay]

I know I'm late on this; but yeah, V4.4.0 has broken a texture pack that I'd taken quite a liking to: https://www.dropbox.com/s/jotsqndtshe0v ... k.pk3?dl=0 It's kind of a shame, really.

Very late. Here's the two month old thread where Doomsday style texture packs were discussed and the decision was taken to drop support for them.

viewtopic.php?f=4&t=68077

Of course, high-res textures are still supported but the pack would need to be converted to the GZDoom format to work.

[openroadracer]

Very late.

Yeah, I hadn't even known about that thread until yesterday, thanks to this thread.

[De-M-oN]

My PC - Intel G3220 and NVIDIA GTX 750 TI 2GB + 8 GB RAM

It’s not enough then. Vulkan backend cannot use regular RAM when video memory is exhausted. If you really need this behavior, switch to OpenGL.

Is that really true?
I cant imagine that a modern game on Vulkan will crash when the VRAM is full.
With Project Brutality the VRAM raised and raised until it was full and the game crashes. I reported that in the past. So it is still happening that the Vulkan Renderer crashes as soon as VRAM is full?

[Graf Zahl]

Vulkan requires the application to take care of that. But if the VRAM just fills up with uncontrolled garbage until nothing is left there is little choice but to abort with a fatal error

[Kamil]

Yeah

[Graf Zahl]

It's not planned. First, only a small subset of CVARS - those which had corresponding ones with descriptions in EDuke32 are covered right now and generally it was once decided that the console doesn't need translation.
.

As a follow up I just realized that we can use the menu's labels as CVAR description for those cases where none is explicitly provided, I just implemented that, including the needed localization support. This should already take care of a massive number of CVARs without investing any real work.

[Cherno]

I am not sure if I should post this since it concerns broken compatibility with the outdated GZDoomBuilder-Bugfix, but maybe it has other implications, too:

The new version of gzdoom.pk3 causes GZDB-BF to throw an error:

ZSCRIPT error in "gzdoom.pk3\zscript\actors\actor.zs", line 334. Expected modifier or name, got <Token.Opencurly ({)>.

this is the "offending" line in gzdoom.pk3:

Code: Select all • Expand view

property FriendlySeeBlocks: FriendlySeeBlocks;

Disclaimer: I don't use Ultimate Doombuilder (yet) because it doesn't allow editing pk3s in SLADE alongside it (which GZDB-BF did), and using folders exclusively is not an option with the amount of older mods I have accumulated.

So anyway, I don't neccessarily expect the devs to take this issue into consideration for fixing, (although I would be glad), I just wanted to make this public in case anyone else has the same problem.

[Graf Zahl]

Are you sure it's that line? It looks precisely like the ones that come before it. My guess would be that the real culprit comes a little bit later, i.e. the deprecation syntax with a helpful explanation about the deprecation.

But whatever, this is surely something we will not change. Use a more modern version of the editor or keep an old gzdoom.pk3 around if you are unwilling to.

[Armaetus]

That's quite a list there! Thanks once again, Graf & team!

[MartinHowe]

Agreed, good work

Posting this here first, as I suspect it's not a bug but just some new boilerplate I have to put in my build script. Admins, please feel free to move it to bugs if Graf Zahl says it is one!

I downloaded the latest ZMusic source using the same settings as last time when it worked:

Code: Select all • Expand view

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=`pwd`/../build_install ..

This time, I get:

Code: Select all • Expand view

 CMake Error at source/CMakeLists.txt:182 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "zmusic".

If this is not a bug, please can any announcements of new versions of code list any new settings or config that must be specified that weren't required before?

Full log, in case needed by the devs:

Code: Select all • Expand view

Cloning into 'zmusic'...
remote: Enumerating objects: 158, done.
remote: Counting objects: 100% (158/158), done.
remote: Compressing objects: 100% (107/107), done.
remote: Total 914 (delta 84), reused 89 (delta 47), pack-reused 756
Receiving objects: 100% (914/914), 1.73 MiB | 2.94 MiB/s, done.
Resolving deltas: 100% (342/342), done.
Already up-to-date.
-- The C compiler identification is GNU 7.5.0
-- The CXX compiler identification is GNU 7.5.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Looking for fts_set
-- Looking for fts_set - found
-- Using system zlib, includes found at /usr/include
-- Using internal gme library
-- Performing Test HAVE_NO_ARRAY_BOUNDS
-- Performing Test HAVE_NO_ARRAY_BOUNDS - Success
-- Performing Test __LIBGME_SWITCH_FALLTHROUGH_WARNINGS
-- Performing Test __LIBGME_SWITCH_FALLTHROUGH_WARNINGS - Success
VGM/GYM: Nuked OPN2 emulator will be used
 ** ZLib library located, compressed file formats will be supported
-- Looking for itoa
-- Looking for itoa - not found
-- Performing Test DUMB_CAN_USE_SSE
-- Performing Test DUMB_CAN_USE_SSE - Success
-- Looking for stricmp
-- Looking for stricmp - not found
-- Looking for strnicmp
-- Looking for strnicmp - not found
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE 
-- Found ALSA: /usr/lib/x86_64-linux-gnu/libasound.so (found version "1.1.3")
CMake Error at source/CMakeLists.txt:182 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "zmusic".

[_mental_]

I guess, this is possible only if CMAKE_INSTALL_LIBDIR is empty or undefined. Have no idea how this could happen.
The following command inside ZMusic tree should fix the problem.

Code: Select all • Expand view

git revert --no-edit 823d9f5d7f7f2aacf8fe1754a60b2a7964a81083

As it works fine for continuous integration builds, GZDoom and ZMusic itself, you should try to figure out why that commit failed to generate with your setup.

EDIT: Disregard this, I re-read CMake documentation, and it seems to work by occasion. Apparently, the result depends on the version of CMake. Should be fixed with ZMusic commit c1bf2f8.