GZDoom 4.9.0 released
Moderator: GZDoom Developers
-
-
- Posts: 26571
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: GZDoom 4.9.0 released
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.
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.
-
- 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
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.9.0 released
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.
-
- Posts: 80
- Joined: Mon May 08, 2017 11:44 am
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Hungary
Re: GZDoom 4.9.0 released
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.)
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: GZDoom 4.9.0 released
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.9.0 released
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.
-
- 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
Unpleasantness has been split to Off Topic.
-
- 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
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?
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: GZDoom 4.9.0 released
There's a 4.9.0a tag right at that fix commit.KynikossDragonn wrote: ↑Sun Nov 06, 2022 2:28 pmSo, 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?
-
- 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
Ah, okay thanks for clearing that up for me Nash!
-
- Posts: 168
- Joined: Mon Jul 12, 2021 1:45 pm
- Graphics Processor: nVidia with Vulkan support
Re: GZDoom 4.9.0 released
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?
-
- Posts: 478
- 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
WOW!!! I just stress tested it on my potato rig and am blown away by the results! Very Well done! <3
-
- 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
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:
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!
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"
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!
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.9.0 released
Unlikely It certainly detects all 12 cores in my own Alder Lake CPU.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?
I don't think it is likely that someone can run a Geforce RTX on such old hardware...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?
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.9.0 released
Now that all binaries are available, can someone please update the Downloads page?