GZDoom 4.8.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
theleo_ua
Posts: 165
Joined: Sun Feb 07, 2016 11:38 am
Operating System Version (Optional): Windows 10
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Ukraine

Re: GZDoom 4.8.0 released

Post by theleo_ua »

I don't see this https://github.com/coelckers/gzdoom/com ... 7313b6dded in the list. Is it added to 4.8.0?
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.8.0 released

Post by Graf Zahl »

Yes, it is.
User avatar
fakemai
Posts: 349
Joined: Mon Feb 12, 2018 12:26 am
Graphics Processor: Intel (Legacy GZDoom)
Location: Australia

Re: GZDoom 4.8.0 released

Post by fakemai »

The .deb exists in the Github's releases list, and it SAYS it's g4.8.0 in the console while I'm using it.
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.8.0 released

Post by KynikossDragonn »

fakemai wrote:The .deb exists in the Github's releases list, and it SAYS it's g4.8.0 in the console while I'm using it.
Mine has a -m at the end for some reason: "g4.8.0-m" even though when I had compiled 4.7.1 it just says "g4.7.1", I wonder why?
User avatar
Rachael
Posts: 13782
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 4.8.0 released

Post by Rachael »

Means whoever prepared the binary had to make changes before dispatching the build process. "-m" means the build is dirty and altered from its original state, according to git.
User avatar
Abba Zabba
Posts: 2166
Joined: Mon Sep 05, 2011 8:50 pm
Location: a place lol!

Re: GZDoom 4.8.0 released

Post by Abba Zabba »

Will this Raze style HUD scaling be the exclusive going forward, or will the old settings be retained? And in addition to that, is it intentional for the options menu (along with all its submenus) to display at a tiny 1x setting, regardless of the UI scale setting you have selected? Also worth mentioning that the automap keeps adjusting its own scale setting everytime it's opened, making it jitter for a split second. If you think that's enough to warrant a bug post, then let me know.
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.8.0 released

Post by Graf Zahl »

The option menu is not affected by the UI scale. It cannot be because it needs a certain minimum width to display correctly, so enlarging it won't work. No idea about the automap, this does not happen for me.
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.8.0 released

Post by KynikossDragonn »

Rachael wrote:Means whoever prepared the binary had to make changes before dispatching the build process. "-m" means the build is dirty and altered from its original state, according to git.
That... doesn't really make any sense, I'm not modifying any of the files, the build happens in a out of tree folder just like the wiki says.

What "changes" do you mean? Changes to the in-tree files? Or changes to the generated CMake build? Because the only thing happening to the tree is checking out the g4.8.0 tag. The only thing happening to the CMake files is me going through with the CMake GUI and setting everything needed for a Release build and making sure it knows where to find ZMusic. (I don't install ZMusic system wide)

If it's because I change my CMake options around, I have been doing the same thing for g4.7.0 and g4.7.1 and it never put a "-m" at the end.

I'm using Git 2.36.1 if that has anything to do with it.
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.8.0 released

Post by Graf Zahl »

"-m" means you have uncommitted changes to at least one file in the repo.
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.8.0 released

Post by KynikossDragonn »

Graf Zahl wrote:"-m" means you have uncommitted changes to at least one file in the repo.
But then wouldn't '$ git reset --hard' undo whatever supposed uncommitted changes?

It says "HEAD is now at 08e46766a - this is 4.8.0" after I do the detatch checkout and the reset hard. I really don't understand what's going on here... Nothing should be being modified anywhere except in the place where the compile actually happens inside of.
User avatar
Rachael
Posts: 13782
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 4.8.0 released

Post by Rachael »

You can try git reset --hard and then git clean -f -d -x to get your checkout into pristine condition. The second command will remove any loose files, including the build folder. (note that these changes are done permanently without confirmation!)
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.8.0 released

Post by KynikossDragonn »

Rachael wrote:You can try git reset --hard and then git clean -f -d -x to get your checkout into pristine condition. The second command will remove any loose files, including the build folder. (note that these changes are done permanently without confirmation!)
Just tried that it's still wanting to say "-m" at the end, even though git status reports nothing to commit source tree clean.

I just now noticed this during the build process:

Code: Select all

[155/684] cd /tmp/gzdoom && /usr/bin/c...ion/UpdateRevision.cmake src/gitinfo.h src/gitinfo.h updated to commit g4.8.0-m.
contents of said file:

Code: Select all

// 08e46766ad442037a0129362b0e7ae7bcd1e8080
//
// This file was automatically generated by the
// updaterevision tool. Do not edit by hand.

#define GIT_DESCRIPTION "g4.8.0-m"
#define GIT_HASH "08e46766ad442037a0129362b0e7ae7bcd1e8080"
#define GIT_TIME "2022-06-06 17:14:47 +0200"
This is even when I made the build directory outside of the directory the git clone is. Just so that there's nothing out of tree and absolutely nothing should be changed whatsoever.

So I'm just going to list off every single step I took as of right now:
  • $ cd /tmp
  • $ git clone 'https://github.com/coelckers/gzdoom.git'
  • $ cd ./gzdoom
  • $ git config --local --add remote.origin.fetch +refs/tags/*:refs/tags/*
  • $ git pull
  • $ git checkout --detach refs/tags/g4.8.0
  • $ git reset --hard
  • $ git clean -f -d -x
  • $ cd ..
  • $ git clone 'https://github.com/coelckers/ZMusic.git'
  • $ cp -p ~/gzdoom/libzmusic.so.1 ./
  • $ mkdir gzdoom_build
  • $ mkdir gzdoom_install
  • Run CMakeGUI and configure accordingly (pointing it to libzmusic, setting Release, install prefix to /tmp/gzdoom_install, CMAKE_INSTALL_RPATH $ORIGIN etc)
  • $ cd ./gzdoom
  • $ git reset --hard
  • $ git clean -f -d -x
  • $ cd ../gzdoom_build
  • $ cmake --build . --target install
EDIT:
So I did a git status after building and noticed this just now:

Code: Select all

$ git status
HEAD detached at g4.8.0
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   libraries/discordrpc/src/discord_register_linux.cpp
	modified:   libraries/discordrpc/src/serialization.h

no changes added to commit (use "git add" and/or "git commit -a")
... would THAT be why I'm getting a "-m"? Nothing in the CMakeGUI mentions discordrpc.
User avatar
Rachael
Posts: 13782
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 4.8.0 released

Post by Rachael »

No - something's wigging out and detecting a change in your file system.

If you're on a non-standard file system format for your OS, try mounting an ext4 partition (for Linux), HFS+ for Mac, NTFS for Windows, or ZFS for the BSD's, and see if the problem still persists after moving the source tree to that partition.
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.8.0 released

Post by KynikossDragonn »

Rachael wrote:No - something's wigging out and detecting a change in your file system.

If you're on a non-standard file system format for your OS, try mounting an ext4 partition (for Linux), HFS+ for Mac, NTFS for Windows, or ZFS for the BSD's, and see if the problem still persists after moving the source tree to that partition.
My main filesystem is ext4, /tmp is tmpfs. I'm on a SSD that I'm very conscious about excessive writes so I try to build things from source entirely within RAM. This was never a problem in the past, only with g4.8.0 and only with those discordrpc files.

I just moved everything over to my main filesystem, already started the build process, already noticed it putting g4.8.0-m in the terminal output so, moving everything to my filesystem made no change.

I even just did a git status while the build is underway and it's reporting the same exact thing. discord_register_linux.cpp and serialization.h reported being modified.

EDIT: I changed to using Unix Makefiles and,

Code: Select all

$ strings ./gzdoom | grep g4.8
g4.8.0
but git status still complains about those two files after the build. So the build process IS modifying stuff in the source tree, but apparently if you try to use Ninja it ends up running whatever to get the git info to return that the tree is modified rather than running it before the tree is modified... either way the tree is clearly being modified regardless!
User avatar
Rachael
Posts: 13782
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 4.8.0 released

Post by Rachael »

The problem might be ninja then. The only file that should ever get changed outside of the build folder is src/gitinfo.h - which is autogenerated by running the "updaterevision" during compile. That is not tracked by git, so it shouldn't be affecting things whatsoever, unless ninja is forcing the file to be added to the tree.

Return to “ZDoom (and related) News”