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.
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.
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.
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.
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.
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).
$ 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
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.
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.
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.
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.
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.
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".
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...)
Google This Site]
