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

GZDoom 4.9.0 released

Post by Graf Zahl »

Notice: The survey is currently OPEN. GZDoom 4.9.0 contains survey code. You may OPT IN or OPT OUT when starting this software.

Please do not post bugs or issues in release threads! Click here

Inportant note to Windows users:
GZDoom 4.9.0 changes where gzdoom.ini is stored. Unlike older versions this one will always prefer the system's user folder and place the INI in Documents/My Games/GZDoom if no INI is found. This was done to bring handling in line with current guidelines and to make it easier for commecial games that often get installed into a folder without write access. If you still want to store the INI in your game folder you have to create an empty file called GZDoom_portable.ini there before launching. If you still have an old INI in your folder, GZDoom will ask what to do with it, you can either move it to the user folder or convert to a portable install.
Please note that this code contains a small error when choosing to convert to a portable install. After doing so the current session will not be flagged as portable and as a result may not find the save data and it will save a global copy of the INI. Until a hotfix gets released please quit GZDoom and restart, that will ensure that the portable settings take effect.

Change of savegame storage
This version introduces per-IWAD savegame folders. If you have old savegames you still intend to use, please wait with the update until you can safely delete them.


The survey has been re-enabled for this version so that we can get some information about how the state of systems being used for GZDoom has developed over the last year. We would like to ask as many users as possible to participate, so that we can make the right decisions based on the information we obtain. Like previous surveys this does not collect any private information - all it sends is basic info about the operating system, the number of CPU cores, the name of the graphics card and supported OpenGL/Vulkan versions.


Download (OpenGLES 2.0 and higher) Highlights:
  • IQM bone model support
  • textured particles
  • modern standards compliant configuration storage on Windows

Details
  • added target check to A_MaulerTorpedoWave.
  • fixed: P_SpawnMapThing may not call playsim code.
  • added PARAM_NULLCHECK to the block iterator creation functions.
  • added [[noreturn]] to several functions that always throw exceptions.
  • Particle Rolling
  • Add Textured Particles
  • Add GFF_NOEXTCHANGE to Phasing Zorcher flash. The Plasma Rifle does not light the player's sprite, so we must assume the Phasing Zorcher also should not.
  • Fix HUD models not drawing if MODELDEF has been changed with A_ChangeModel
  • Fix inconsistent distance and hit position on traces that skip everything.
  • Fix canvas textures getting clipped by wrong scissor box
  • Fix vulkan backend clearing the canvas textures to undefined contents
  • made DMover and subclasses non-abstract so they can be inherited from.
  • added option to show hub and episode names on the alt HUD.
  • reworked CVARs to not use a linked list and to be initialized manually.
  • marked a few Printf calls in critical error paths as PRINT_NONOTIFY.
  • fixed: R_LoadVoxelDef did not fully initialize the voxel descriptor it creates.
  • don't crash on null pointers in V_GetFont.
  • zero the velocity of crunched sprites. Since their size is zeroed, they are no longer subject to collision detection and may slide out of the level otherwise.
  • don't crash when destroying incomplete textures. This can happen during TEXTURES parsing in case of an error.
  • try to keep the engine stable for as long as possible if a VM exception occurs in OnDestroy while running a cleanup. This will still crash, but run long enough for the exception message to be visible.
  • fixed F2DDrawer::SetClipRect.
  • added vanilla donut handling to compat_floormove.
  • Fixed: voxel models pitch/roll properties weren't initialized correctly
  • Added QF_SHAKEONLY. The QF_SHAKEONLY flag changes the behavior of earthquakes with a damage radius, so that they only shake actors around, without also harming them.
  • Added QF_AFFECTACTORS. The QF_AFFECTACTORS flag makes the thrusting and harming of damaging earthquakes also affect monsters. Monsters with DONTTHRUST will not be flung around by earthquakes.
  • Added the QF_GROUNDONLY flag. The QF_GROUNDONLY flag makes earthquakes only shake the player while they are standing on the ground.
  • fixed DrawLine commands by giving them a consistent floating point interface.
  • heretic: e2m7
  • missing texture
  • fixed direct native interface for Draw(Thick)Line.
  • fixed: The main loop never checked the cutscene flag for disabling wipes.
  • Sync movie video playback to the audio, when possible
  • Fix washed out colors in Vulkan HDR mode
  • normalize the timer with the app start, not the epoch. This ensures smaller values and less wraparounds with integer values in scripts.
  • un-deprecated the integer MSTime variant. Due to undefined downconversion rules from double to int, there is no way to safely downcast the return from MSTimef, meaning the function is completely useless for retrieving integral time stamps.
  • added Harmony ENDOOM screen.
  • added a config getter to the interface.
  • moved language CVAR to backend.
  • handle menu customization via callbacks.
  • move hud scale CVARs to the backend.
  • handle autoload flags in startup through function parameters instead of directly accessing the CVARs.
  • handle Build tiles via explicit callback to the init function.
  • add a system interface for CheckCheatmode and moved some sound code to the backend.
  • Exported GetDisplayTopOffset for font characters to ZScript
  • added missing obituary for Strife's turret.
  • Added support for BLOCKLANDMONSTERS in Line_SetBlocking.
  • Added APROP_FriendlySeeBlocks to Set/GetActorProperty
  • Fix planeval; add direct sector slope manipulation
  • Modify to have one GetVertexZ rather than IsVertexZSet / GetVertexZ
  • Add vertex height manipulation functions to LevelPostProcessor
  • Add sv_noextraammo. When set to true, disables that weird hardcoded behavior from original Doom that gives extra ammo when picking up weapons in deathmatch
  • fixed: all script methods adding an object to a dynamic array must perform a write barrier.
  • add freezetics actor property
  • allow notification of actor goal is reached inside of a SECF_NOATTACK sector
  • GLES2: Fix anistropic filtering
  • disabled discord-rpc debug info for configurations without it
  • fixed sky cap color handling
  • fix arti teleport and arti teleother not respecting useplayerstartz mapflag
  • UE1 models now handle frame index -1 properly.
  • Add support for the GOG releases of the Unity versions of Doom and Doom II.
  • carry over the tiling flag from the finished to the entering screen
  • Prevent Keyconf from adding duplicate playerclass
  • Add detection for the Final Doom WADs that were recently added to the Steam version of Doom II.
  • new method to define obituaries without modifying actors.
  • remove latch flag from sv_cheats
  • add `openscreenshots` `opensaves` and `openconfig` console commands on Windows and Linux and Mac
  • use consistent index types for array function return values.
  • pass clip rect as pointer to F2DDrawer::AddLine.
  • Export FindLumpFullName to ZScript.
  • Add support for nested user types
  • made adjustments for proper int type promotion to allow internal ZScript to compile with it on.
  • ZScript: fixed integer type promotion for shift operator
  • version-restrict int to uint promotion. Some mods depend on this not happening.
  • fixed: The compile context for constant evaluation did not initialize its Version member.
  • Don't throw away unsignedness when passing unsigned constants to the codegen
  • Add signed->unsigned promotion for binary operators
  • fix menu commands with semicolon separated commands
  • get rid of M_Malloc call in WriteSavePic
  • Fix definition order of ZScript structs. Do a first pass over the Structs array in CompileAllFields() to reorder them such that if a struct uses other structs, those structs will be resolved first.
  • Fix viewpoint buffer not getting cleared when in the menus
  • backported KDE detection from Raze.
  • removed the Softpoly backend.
  • Add a 2d drawer to canvas textures
  • Fix incorrect mapping of texture indices for UE1 models.
  • Added PitchFromMomentum, UseActorPitch and UseActorRoll to VOXELDEF. Behaves exactly like their 3D model counterparts. Hardware renderer only.
  • removed some redundant chaaracters from the Doom SmallFont.
  • Added IQM bone model support
  • Added A_ChangeModelDef
  • fixed return values of FTextureAnimator::AddAnim
  • add longsavemessages to simple menu. set longsavemessages default to false.
  • DirectInput cleanup. Removing ancient code that's only useful on pre-XP OSs.
  • also allocate FDoorAnimation's frame table from the texture manager's memory arena.
  • optimized storage for animation definitions.
  • Fixed vulkan crash when multisampling is enabled
  • add a method for filling a shape2d instead of using a texture (#1661)
  • add stencil buffer support for 2d drawing (#1660)
  • add a system for setting all of 2D drawing's transform, not just shapes
  • Expose ConsoleState to scripts
  • rewrote Windows console code for Windows 10's new terminal.
  • fixed and consolidated artifact check in cheat code.
  • removed volatile type punning for clipping against line portals.
  • fixed handling of *dive and *surface sounds.
  • let A_FireProjectile pass through the second return value of SpawnPlayerMissile.
  • fixed PoisonCloud's looping animation count.
  • weapons are not artifacts.
  • rename PrintString to PrintfEx and make it a vararg function
  • Expose Print Flags to ZScript
  • fixed names for A_PlaySoundEx
  • ENDOOM is not Windows only anymore.
  • fixed background tiling for summary screen. Since the background object gets recycled it must clear this flag before loading a new background.
  • let the "abort" button on the network pane of the startup screen do a hard exit on Windows.
  • make sure ticdup is initialized.
  • Add +ONLYVISIBLEINMIRRORS and +INVISIBLEINMIRRORS actor flags. The former makes the actor only visible in reflections, while the latter makes the actor not cast reflections in mirrors.
  • cleanup and refactoring of Vulkan backend
  • Improve vk_debug output a lot by throwing away the useless parts of the message and limit the callstack to the first 5 gzdoom calls
  • validate fountaincolor before using it.
  • added detection of macOS Ventura
  • ZScript: don't allow multiple assignment syntax with only one element.
  • fixed type of third argument of MBF21's MonsterMeleeAttack function. This is a sound, not an int.
  • added an override for NOTAUTOAIMED flag when using P_AimLineAttack for informative CCMDs.
  • allow taking screenshots in cutscenes.
  • fixed JIT target function for GetTimeFrac.
  • fixed: For cutscenes the alternative clean scaling factors need to be activated.
  • fixed setup of ready state with Dehacked. This needs to emulate the hard coded chainsaw sound when weapon states get reassigned.
  • Fix the discolored sky bug
  • check point pushers/pullers by inheritance, not absiolute match
  • added FailSound property to PuzzleItem
  • add `i_pauseinbackground` to the menu. note: please pull the language file for this
  • set `i_pauseinbackground` to match `!(i_soundinbackground)` for all configs before this commit.
  • fixed division by zero with unvalidated ticdup values.
  • reinstated con_scale.
Last edited by Graf Zahl on Sun Nov 06, 2022 3:53 am, edited 2 times in total.
User avatar
Hirogen2
Posts: 2033
Joined: Sat Jul 19, 2003 6:15 am
Graphics Processor: Intel with Vulkan/Metal Support
Location: Central Germany

Re: GZDoom 4.9.0 released

Post by Hirogen2 »

Code: Select all

gzdoom/src/d_anonstats.cpp:14:10: fatal error: i_mainwindow.h: No such file or directory
   14 | #include "i_mainwindow.h"
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [src/CMakeFiles/zdoom.dir/build.make:1441: src/CMakeFiles/zdoom.dir/d_anonstats.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:959: src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
$ find . -name "i_mainw*"
./src/common/platform/win32/i_mainwindow.h
./src/common/platform/win32/i_mainwindow.cpp
https://github.com/ZDoom/gzdoom/pull/1790
User avatar
Ihavequestions
Posts: 126
Joined: Mon Jul 12, 2021 1:45 pm
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.9.0 released

Post by Ihavequestions »

Graf Zahl wrote: Sat Nov 05, 2022 12:52 pmThe survey has been re-enabled for this version so that we can get some information about how the state of systems being used for GZDoom has developed over the last year. We would like to ask as many users as possible to participate, so that we can make the right decisions based on the information we obtain. Like previous surveys this does not collect any private information - all it sends is basic info about the operating system, the number of CPU cores, the name of the graphics card and supported OpenGL/Vulkan versions.
Regarding this survey, do you evaluate deviations from the default HyperThreading / SMT settings?

For example, I have my 8-core Intel running with HT off, so my CPU would report as 8C/8T but, by default, this would be an 8C/16T CPU.
Eight threads is way enough for me at the moment, and I see more advantages than disadvantages to that in my daily tasks including gaming. (It's also more secure.)

For a game developer, this might be an important insight because learning about the CPU model in question alone would not give them any actual config information.
User avatar
axredneck
Posts: 289
Joined: Mon Dec 11, 2017 2:09 pm
Graphics Processor: nVidia with Vulkan support
Location: Russia

Re: GZDoom 4.9.0 released

Post by axredneck »

textured particles
Finally it would be possible to make Brutal Doom less demanding?
User avatar
Rachael
Admin
Posts: 13110
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 4.9.0 released

Post by Rachael »

axredneck wrote: Sat Nov 05, 2022 6:20 pm Finally it would be possible to make Brutal Doom less demanding?
Yes - but this is something that must be changed within the mod itself.

But the mod can indeed make this change and use particles instead of actors, for a *MASSIVE* performance boost.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.9.0 released

Post by Graf Zahl »

Ihavequestions wrote: Sat Nov 05, 2022 6:15 pm
Graf Zahl wrote: Sat Nov 05, 2022 12:52 pmThe survey has been re-enabled for this version so that we can get some information about how the state of systems being used for GZDoom has developed over the last year. We would like to ask as many users as possible to participate, so that we can make the right decisions based on the information we obtain. Like previous surveys this does not collect any private information - all it sends is basic info about the operating system, the number of CPU cores, the name of the graphics card and supported OpenGL/Vulkan versions.
Regarding this survey, do you evaluate deviations from the default HyperThreading / SMT settings?

For example, I have my 8-core Intel running with HT off, so my CPU would report as 8C/8T but, by default, this would be an 8C/16T CPU.
Eight threads is way enough for me at the moment, and I see more advantages than disadvantages to that in my daily tasks including gaming. (It's also more secure.)

For a game developer, this might be an important insight because learning about the CPU model in question alone would not give them any actual config information.
On Windows I can detect the number of physical cores and report that. On Linux and macOS I am stuck because they do not have an API for that piece of info I can easily use.
I find the number of virtual cores rather uninteresting here.

Right now, after 127 users reporting, more than half are still on 4 core systems or less. We even got 2 users reporting a single core, I wonder what kind of system they run - their GPU suggests they should have something better.
User avatar
Hirogen2
Posts: 2033
Joined: Sat Jul 19, 2003 6:15 am
Graphics Processor: Intel with Vulkan/Metal Support
Location: Central Germany

Re: GZDoom 4.9.0 released

Post by Hirogen2 »

Graf Zahl wrote: Sun Nov 06, 2022 12:36 am On Windows I can detect the number of physical cores and report that. On Linux and macOS I am stuck because they do not have an API for that piece of info I can easily use.
Surely this should be easy (using popen(3) on Linux).

Code: Select all

$ lscpu --parse=cpu,node,socket,core,maxmhz
# The following is the parsable format, which can be fed to other
# programs. Each different item in every column has an unique ID
# starting usually from zero.
# CPU,Node,Socket,Core,Maxmhz
0,0,0,0,4200.0000
1,0,0,1,4200.0000
2,0,0,2,4200.0000
3,0,0,3,4200.0000
4,0,0,0,4200.0000
5,0,0,1,4200.0000
6,0,0,2,4200.0000
7,0,0,3,4200.0000
User avatar
Chris
Posts: 2879
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: GZDoom 4.9.0 released

Post by Chris »

Hirogen2 wrote: Sun Nov 06, 2022 4:48 am Surely this should be easy (using popen(3) on Linux).
fopen on /proc/cpuinfo would probably be better. Though he didn't say it couldn't be done, just that there was no API for it that was easy to use, and parsing the output of a program or reading a proc file aren't really nice ways to get that kind of data. I'd be surprised if there aren't Linux-specific ioctls or syscalls to get the info in a nicer way, but this isn't something I know much about.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.9.0 released

Post by Graf Zahl »

There surely is an API, otherwise /proc/cpuinfo would not be possible, but my knowledge here is virtually non-existent and it's not really that important, as Linux just made up less than 10% of the reporting user base in previous surveys.
User avatar
Rachael
Admin
Posts: 13110
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 4.9.0 released

Post by Rachael »

Actually, /proc/cpuinfo is a pseudo-file provided by the kernel, itself. And yes it is quite well expected that on Linux you use /proc information - virtually all Linux tools that matter do so, anyhow.

/proc follows the "everything is a file" Unix ideology. The downside is it is a mountable filesystem in of itself and naturally can be remounted to a different mount point, or even not at all. (That is, if you are fine with breaking half the tools on your system!)

Anyway, its contents are provided exclusively by the kernel and its modules at the time of access - none of the files in /proc actually exist. Meaning, every time you open a /proc file its information changes based on the current state of the system.

And yes - you are perfectly fine to create a fatal error condition if the information you are looking for does not exist in /proc - the tools that depend on it will do that, as well.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.9.0 released

Post by Graf Zahl »

Urgh.

Yeah, it somehow fits that they rather provide a text file that needs to be parsed instead of an API that can be used directly by the calling code.
User avatar
Enjay
 
 
Posts: 26430
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: GZDoom 4.9.0 released

Post by Enjay »

That's a huge list of changes. Thanks to all involved. I haven't managed to be around as much as I would like recently (thanks to real-life nonsense) but I have been trying to keep tabs on things. However, I didn't realise that quite so much had been added/fixed/changed. So, once again, thank you.

Personally, I'm not a fan of the user settings ini-file location change. As a point of principle, I really can't stand "special" folders and auto-putting stuff in locations that I didn't choose. I have really hated such shenaningans since they first appeared in, what, Windows 95?. I also actually liked having several differently named ini files in my GZDoom directory. However, I understand the need for what, from my perspective, is a necessary evil. At least it was handled very gracefully by GZDoom - much more so than many other programs and games. I tried both options but, ultimately, decided to go with a "portable" installation because that suits my preferences more closely.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.9.0 released

Post by Graf Zahl »

You may not like them, I may not like them, but the old system seriously inconvenienced independent game makers so something had to be done. On Mac and Linux it was done like that all the time already and both systems are quite anal about not storing data in the application folder.

I also prefer portable. But in the end the old system tried to be both at once and failed - if you go portable you do not need to encode the user name into the INI's filename.
User avatar
Enjay
 
 
Posts: 26430
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: GZDoom 4.9.0 released

Post by Enjay »

Graf Zahl wrote: Sun Nov 06, 2022 6:46 am You may not like them, I may not like them, but the old system seriously inconvenienced independent game makers so something had to be done. On Mac and Linux it was done like that all the time already and both systems are quite anal about not storing data in the application folder.

I also prefer portable. But in the end the old system tried to be both at once and failed - if you go portable you do not need to encode the user name into the INI's filename.

Yup, I'm fully on board with the decision and understand why it was made (and, as I said, done very gracefully).

I just wish that things had gone a (to me) better route in the first place (i.e. from the OS/standard perspective, not GZDoom), though I don't know exactly what I would have wanted to see in its place as the "better route".
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.9.0 released

Post by Graf Zahl »

The better route would be if more applications allowed portable installs. But I can also see how hard both Linux and macOS make it for people who want to go this route.

In general writing to the program directory is bad, and what Windows did before the current system was set up was even worse (like writing INIs to the Windows directory in 16 bit versions, or, god forbid, writing this stuff into the registry (which at one point also was the recommended way to do stuff...)

Return to “ZDoom (and related) News”