GZDoom 4.4.0 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
Nash
 
 
Posts: 17468
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: GZDoom 4.4.0 released

Post by 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)
User avatar
Barry Burton
Posts: 87
Joined: Tue Sep 03, 2019 2:20 pm

Re: GZDoom 4.4.0 released

Post by 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. :)
User avatar
openroadracer
Posts: 496
Joined: Mon Sep 23, 2019 1:03 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 7 Professional 64-bit SP1
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Doomworld Forums

Re: GZDoom 4.4.0 released

Post by 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.
User avatar
sinisterseed
Posts: 1349
Joined: Tue Nov 05, 2019 6:48 am
Preferred Pronouns: He/Him
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.4.0 released

Post by sinisterseed »

Nash wrote:(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.
User avatar
Enjay
 
 
Posts: 26697
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: GZDoom 4.4.0 released

Post by Enjay »

openroadracer wrote: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.
User avatar
openroadracer
Posts: 496
Joined: Mon Sep 23, 2019 1:03 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 7 Professional 64-bit SP1
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Doomworld Forums

Re: GZDoom 4.4.0 released

Post by openroadracer »

Enjay wrote:Very late.
Yeah, I hadn't even known about that thread until yesterday, thanks to this thread.
User avatar
De-M-oN
Posts: 206
Joined: Mon May 26, 2008 3:24 pm
Preferred Pronouns: He/Him
Location: Germany

Re: GZDoom 4.4.0 released

Post by De-M-oN »

_mental_ wrote:
Kamil wrote: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? :(
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49193
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.4.0 released

Post by 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
Last edited by Graf Zahl on Mon Jun 08, 2020 3:18 pm, edited 1 time in total.
Kamil
Posts: 163
Joined: Sat Sep 21, 2019 12:42 pm
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.4.0 released

Post by Kamil »

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

Re: GZDoom 4.4.0 released

Post by Graf Zahl »

Graf Zahl wrote: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. :)
User avatar
Cherno
Posts: 1325
Joined: Tue Dec 06, 2016 11:25 am

Re: GZDoom 4.4.0 released

Post by 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

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49193
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.4.0 released

Post by 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.
User avatar
Armaetus
Posts: 1256
Joined: Fri Mar 13, 2009 3:55 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 10 Home
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: New York State

Re: GZDoom 4.4.0 released

Post by Armaetus »

That's quite a list there! Thanks once again, Graf & team!
User avatar
MartinHowe
Posts: 2052
Joined: Mon Aug 11, 2003 1:50 pm
Location: Waveney, United Kingdom

Re: GZDoom 4.4.0 released

Post by 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

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=`pwd`/../build_install ..
This time, I get:

Code: Select all

 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

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_
 
 
Posts: 3819
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom 4.4.0 released

Post by _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

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.[/s]

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.

Return to “ZDoom (and related) News”