GZDoom 4.9.0 released

[Enjay]

And I guess the precursor to registry-writing was how win.ini used to get cluttered up with cruft from badly behaved programs too. It's amazing how many programs still write quite extensively to the registry.

I guess that part of the problem is that things evolved and, as machines, operating systems and use cases moved on, the inadequacies of older methods became more apparent and superseded, but the old ones were kept for compatibility. So there ended up being a complicated mish-mash of ways of doing things and mixed levels of constancy even in the way things were handled across different areas of the same generation of standards.

[yum13241]

I'm loving this release. One problem is though, old saves aren't being put in to their new directories (doom.id.wadsmoosh) for example, I still see a bunch of loose save files. Since GZDoom can already detect what game a save is for, it'd be great if GZDoom could just do it for me. because save*.zds is super cryptic and I have no idea what that save would be for. I don't want to sound ungrateful it's just that it is a problem. People who didn't try out the "Browse Save Folder" menu item (cool stuff btw) would think their saves got trashed.

[Graf Zahl]

Hence the warning in the release post. I'll be honest here: The work required to make this work stands in absolutely no relation to the resulting convenience. There's also the problem that the identification is not foolproof - the savegames do not contain enough data to identify the proper IWAD with 100% certainty.

[wolfmanfp]

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.

Why not <user folder>/Saved Games/GZDoom instead? Disdain and HoN already does that, and it's also an OS standard.
(Don't get me wrong, this is not meant to be a complaint.)

[Nash]

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.

Why not <user folder>/Saved Games/GZDoom instead? Disdain and HoN already does that, and it's also an OS standard.
(Don't get me wrong, this is not meant to be a complaint.)

I'm actually going to follow GZDoom's standard and move Disdain's configs to "My Games/Disdain" instead. The config code used in Disdain predates GZDoom's implementation (it was, I believe, Redemption's implementation; a GZDoom fork maintained by Rachael). Now that GZDoom officially supports it, it would be much easier for fork maintenance for me to use GZDoom's implementation.

[Graf Zahl]

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.

Why not <user folder>/Saved Games/GZDoom instead? Disdain and HoN already does that, and it's also an OS standard.
(Don't get me wrong, this is not meant to be a complaint.)

I just used what was there already. Remember: All the Known Folders code had been there for a long time. I merely used the DocumentPath that pointed to this folder. If this is really not correct it can be easily changed and the INI copied to a "better" location.

[wildweasel]

Unpleasantness has been split to Off Topic.

[KynikossDragonn]

https://github.com/ZDoom/gzdoom/pull/1790

So, quick question about this... If I go and pull the g4.9.0 tag right now, am I going to immediately run into this problem? Can I just compile without the survey and it'll still build?

[Nash]

https://github.com/ZDoom/gzdoom/pull/1790

So, quick question about this... If I go and pull the g4.9.0 tag right now, am I going to immediately run into this problem? Can I just compile without the survey and it'll still build?

There's a 4.9.0a tag right at that fix commit.

[KynikossDragonn]

Ah, okay thanks for clearing that up for me Nash!

[Ihavequestions]

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.

Just some wild guessing:
Might that be an Alder Lake CPU with one P-core and several E-cores, and GZDoom not able to detect the single P-core's second logical core as well as any of the E-cores?
Or perhaps someone running one of the earliest HT/SMT CPUs that had one physical core with two logical cores -- but GZDoom is only able to detect that one physical core?

[kalensar]

WOW!!! I just stress tested it on my potato rig and am blown away by the results! Very Well done! <3

[KynikossDragonn]

Since I'm building this without the anon stats, I'd just like to report what my system is currently on:

CPU: Intel Core i7-6770HQ CPU @ 2.60GHz (Quad core & HyperThreading enabled)
GPU: Intel Iris Pro Graphics 580 (SKL GT4)
Linux Kernel: 5.19.17
Mesa: 22.1.7
OpenGL: 4.6
Vulkan: 1.3


I also like to report I can't get it to stop attaching "-m" to the end of the g4.9.0, and it 's the same issue as before coming from the DiscordRPC libraries:

Code: Select all

diff --git a/libraries/discordrpc/src/discord_register_linux.cpp b/libraries/discordrpc/src/discord_register_linux.cpp
index dd92eea0d..dfc5340c1 100644
--- a/libraries/discordrpc/src/discord_register_linux.cpp
+++ b/libraries/discordrpc/src/discord_register_linux.cpp
@@ -42,12 +42,12 @@ extern "C" DISCORD_EXPORT void Discord_Register(const char* applicationId, const
     }
 
     const char* desktopFileFormat = "[Desktop Entry]\n"
-                                   "Name=Game %s\n"
-                                   "Exec=%s %%u\n" // note: it really wants that %u in there
-                                   "Type=Application\n"
-                                   "NoDisplay=true\n"
-                                   "Categories=Discord;Games;\n"
-                                   "MimeType=x-scheme-handler/discord-%s;\n";
+                                    "Name=Game %s\n"
+                                    "Exec=%s %%u\n" // note: it really wants that %u in there
+                                    "Type=Application\n"
+                                    "NoDisplay=true\n"
+                                    "Categories=Discord;Games;\n"
+                                    "MimeType=x-scheme-handler/discord-%s;\n";
     char desktopFile[2048];
     int fileLen = snprintf(
       desktopFile, sizeof(desktopFile), desktopFileFormat, applicationId, command, applicationId);
diff --git a/libraries/discordrpc/src/serialization.h b/libraries/discordrpc/src/serialization.h
index ddea73b25..a7c50c6bf 100644
--- a/libraries/discordrpc/src/serialization.h
+++ b/libraries/discordrpc/src/serialization.h
@@ -10,7 +10,8 @@
 #pragma warning(disable : 4464) // relative include path contains
 #pragma warning(disable : 4668) // is not defined as a preprocessor macro
 #pragma warning(disable : 6313) // Incorrect operator
-#pragma warning(disable : 5045) // Compiler will insert Spectre mitigation for memory load if /Qspectre switch specified
+#pragma warning(disable : 5045) // Compiler will insert Spectre mitigation for memory load if
+                                // /Qspectre switch specified
 #endif                          // __MINGW32__
 
 #include "rapidjson/document.h"

Why is the build process doing this? I'm confused, it does this even with Ninja or Unix Makefiles... it somehow does this even if I remove write permissions to those files, and it somehow is also able to do this if I change ownership of those files to root and disable write permission???

The only change I see is... inexplicable whitespace??? What on earth is even going on here?

This keeps happening each and every single time the process reaches the part it compiles the DiscordRPC stuff. Is there any way to make it not compile this whatsoever? I don't even use Discord and I never will.

Also no, even if I change "UpdateRevision.cmake" to get rid of "--dirty=-m" it still somehow somewhere puts a -m anyways!

[Graf Zahl]

Just some wild guessing:
Might that be an Alder Lake CPU with one P-core and several E-cores, and GZDoom not able to detect the single P-core's second logical core as well as any of the E-cores?

Unlikely It certainly detects all 12 cores in my own Alder Lake CPU.

Or perhaps someone running one of the earliest HT/SMT CPUs that had one physical core with two logical cores -- but GZDoom is only able to detect that one physical core?

I don't think it is likely that someone can run a Geforce RTX on such old hardware...

[Graf Zahl]

Now that all binaries are available, can someone please update the Downloads page?