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
Enjay
 
 
Posts: 26562
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: GZDoom 4.9.0 released

Post by 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
Posts: 853
Joined: Mon May 10, 2021 8:08 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): EndeavorOS (basically Arch)
Graphics Processor: Intel with Vulkan/Metal Support

Re: GZDoom 4.9.0 released

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

Re: GZDoom 4.9.0 released

Post by 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.
User avatar
wolfmanfp
Posts: 80
Joined: Mon May 08, 2017 11:44 am
Graphics Processor: nVidia (Modern GZDoom)
Location: Hungary

Re: GZDoom 4.9.0 released

Post by wolfmanfp »

Graf Zahl wrote: Sat Nov 05, 2022 12:52 pm 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.)
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: GZDoom 4.9.0 released

Post by Nash »

wolfmanfp wrote: Sun Nov 06, 2022 10:41 am
Graf Zahl wrote: Sat Nov 05, 2022 12:52 pm 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49179
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.9.0 released

Post by Graf Zahl »

wolfmanfp wrote: Sun Nov 06, 2022 10:41 am
Graf Zahl wrote: Sat Nov 05, 2022 12:52 pm 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.
User avatar
wildweasel
Posts: 21706
Joined: Tue Jul 15, 2003 7:33 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): A lot of them
Graphics Processor: Not Listed

Re: GZDoom 4.9.0 released

Post by wildweasel »

Unpleasantness has been split to Off Topic.
User avatar
KynikossDragonn
Posts: 272
Joined: Sat Dec 12, 2020 10:59 am
Preferred Pronouns: He/Him
Operating System Version (Optional): Void Linux
Graphics Processor: Intel (Modern GZDoom)
Location: Independence, KS, USA

Re: GZDoom 4.9.0 released

Post by KynikossDragonn »

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?
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: GZDoom 4.9.0 released

Post by Nash »

KynikossDragonn wrote: Sun Nov 06, 2022 2:28 pm
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.
User avatar
KynikossDragonn
Posts: 272
Joined: Sat Dec 12, 2020 10:59 am
Preferred Pronouns: He/Him
Operating System Version (Optional): Void Linux
Graphics Processor: Intel (Modern GZDoom)
Location: Independence, KS, USA

Re: GZDoom 4.9.0 released

Post by KynikossDragonn »

Ah, okay thanks for clearing that up for me Nash!
User avatar
Ihavequestions
Posts: 168
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: Sun Nov 06, 2022 12:36 amRight 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?
User avatar
kalensar
Posts: 476
Joined: Sun Mar 21, 2021 9:40 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): linux mint 21
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: GZDoom 4.9.0 released

Post by kalensar »

WOW!!! I just stress tested it on my potato rig and am blown away by the results! Very Well done! <3
User avatar
KynikossDragonn
Posts: 272
Joined: Sat Dec 12, 2020 10:59 am
Preferred Pronouns: He/Him
Operating System Version (Optional): Void Linux
Graphics Processor: Intel (Modern GZDoom)
Location: Independence, KS, USA

Re: GZDoom 4.9.0 released

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

Re: GZDoom 4.9.0 released

Post by Graf Zahl »

Ihavequestions wrote: Sun Nov 06, 2022 9:34 pmJust 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.
Ihavequestions wrote: Sun Nov 06, 2022 9:34 pm 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...
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49179
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 4.9.0 released

Post by Graf Zahl »

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

Return to “ZDoom (and related) News”