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]

[Tap Here for Mobile-Friendly Forums]

Moderator: GZDoom Developers

Re: GZDoom 4.4.0 released

Postby Nash » Mon Jun 08, 2020 9:02 am

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
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GZDoom 4.4.0 released

Postby Barry Burton » Mon Jun 08, 2020 9:29 am

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
Barry Burton
 
Joined: 03 Sep 2019

Re: GZDoom 4.4.0 released

Postby openroadracer » Mon Jun 08, 2020 11:23 am

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
openroadracer
 
Joined: 23 Sep 2019
Discord: Dump The Trump#5789
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom 4.4.0 released

Postby sinisterseed » Mon Jun 08, 2020 11:56 am

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
sinisterseed
GZDoom RO Translator & Raze Tester
 
Joined: 05 Nov 2019
Twitch ID: sixhundredsixteen
Github ID: sinisterseed
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.4.0 released

Postby Enjay » Mon Jun 08, 2020 12:03 pm

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
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom 4.4.0 released

Postby openroadracer » Mon Jun 08, 2020 12:04 pm

Enjay wrote:Very late.
Yeah, I hadn't even known about that thread until yesterday, thanks to this thread.
User avatar
openroadracer
 
Joined: 23 Sep 2019
Discord: Dump The Trump#5789
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom 4.4.0 released

Postby De-M-oN » Mon Jun 08, 2020 1:35 pm

_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
De-M-oN
 
Joined: 26 May 2008

Re: GZDoom 4.4.0 released

Postby Graf Zahl » Mon Jun 08, 2020 1:59 pm

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

Re: GZDoom 4.4.0 released

Postby Kamil » Mon Jun 08, 2020 3:07 pm

Yeah :(
Kamil
 
Joined: 21 Sep 2019
Discord: @Kamil#8122
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.4.0 released

Postby Graf Zahl » Mon Jun 08, 2020 3:36 pm

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

Re: GZDoom 4.4.0 released

Postby Cherno » Mon Jun 08, 2020 5:23 pm

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 allExpand 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.
User avatar
Cherno
 
Joined: 06 Dec 2016

Re: GZDoom 4.4.0 released

Postby Graf Zahl » Tue Jun 09, 2020 12:05 am

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

Re: GZDoom 4.4.0 released

Postby Armaetus » Tue Jun 09, 2020 12:29 am

That's quite a list there! Thanks once again, Graf & team!
User avatar
Armaetus
Maps of Chaos & RDND Author
 
Joined: 13 Mar 2009
Location: New York State
Discord: Armaetus#8512
Github ID: GlaiceOldSchoolRTS
Operating System: Windows Vista/7/2008 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom 4.4.0 released

Postby MartinHowe » Tue Jun 09, 2020 1:17 am

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 allExpand view
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=`pwd`/../build_install ..

This time, I get:
Code: Select allExpand 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 allExpand 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".
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: GZDoom 4.4.0 released

Postby _mental_ » Tue Jun 09, 2020 2:12 am

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

PreviousNext

Return to ZDoom (and related) News

Who is online

Users browsing this forum: No registered users and 1 guest