A novice GZDoom fork [Default Settings Overhaul]

[Lippeth]

I'm not a programmer, developer or coder by any means, am ignorant to any etiquette or unspoken rules about forking programs if there are any, and I'm almost afraid to post this at all for fear of being yelled at by people who actually know what they're doing, but this has been the most fun I've had in a long time and want to share my "work" and invite all the necessary scolding in order to improve and learn. I'm probably learning the wrong way by trial and error and using error messages as a guide, but I did finally order a copy of C++ Primer Fifth Edition which will hopefully fix some of my bad habits.

 

After watching a very helpful video by @DuckReconMajor about building dsda-doom and PrBoom+, I had a field day building anything I could get my hands on that uses a similar method, and after poking around in GZDoom's source code for a while I decided to attempt a complete overhaul of its default settings, and to try and add every feature I always wanted but was too afraid to ask for. GZDoom's default settings have always been controversial, and this fork will change nothing because I catered only to my own tastes and don't plan to deviate that much from where it currently is.

 

Here are some of the new things I added:

• Simple compatibility option at the top of the main menu
• Added Raven compatibility modes (still a work in progress)
• New menu slider for amount of message lines in HUD Options->Message Options
• Vertical bullet spread for hitscan weapons relative to ssg (can be disabled in player setup and gameplay options)
• Bulletchip fade effects
• Reduced dynamic light radius for all Doom sprites in lights.pk3
• New secret message and unique sounds for Doom, Heretic and Hexen.
• Added pixel ratio toggle to video options (must use custom resolution to toggle)
• Lowered minimum sound channels to 8
• Plasmagun death sound interrupts firing sound
• Included Nashgore as optional file (selectable on welcome screen)
• Included Nash Cursor

And here are some of the default settings:

• libADL with GENMIDI.GS as MIDI playback
• Autorun on
• Classic* automap colors (found secrets in magenta, unexplored in cyan)
• No texture filtering
• Vanilla style mouse strafing
• Scaled statusbar
• Capped FPS
• No monster interpolation
• No mouselook
• No vertical movement
• Classic night vision
• Classic transparency
• Pitched sound effects
• No colored dim screen in menus
• Simple options menu disabled

Windows 64 bit

Windows 32 bit

 

https://github.com/Lippeth/gzdoom

Edited April 11, 2022 by Lippeth

[Graf Zahl]

If you got useful stuff, don't hesitate to make a pull request from it.

 

As for the defaults, it'd be much easier to just distribute an INI file with them - no need to edit the source for that.

 

[CoolerDoomeR]

It's better you choose a name for this.

[ketmar]

@Lippeth be very, very careful, my friend! it may look innocent at first, like "oh, i won't do anything big, just modify some small things here and there", but after some time you may suddenly found yourself developing a full-featured source port!

[Lippeth]

12 hours ago, Graf Zahl said:

If you got useful stuff, don't hesitate to make a pull request from it.

  

As for the defaults, it'd be much easier to just distribute an INI file with them - no need to edit the source for that.

  

Thank you Graf, I'm still learning how Git and Github work but I do hope to help contribute features and ideas to the main repository, even in my own capacity. As far as the defaults, in hindsight I agree that changing the source code was probably overkill but hunting for every option did help me learn where a lot of things are. I'm still not sure exactly how branching within my own fork works but now I'm wondering if that would've been the way to go for some of the more trivial changes while learning, and then later omitting them. I'm also a bit hesitant about doing a pull request with some things because after pushing them to master I would rework some of it and do another commit, so it might look ugly and be annoying to read unless I can somehow consolidate it just to show the overall differences to the parent instead of every step I took. I probably sound very naive with all this but I'm working very hard to change that.

 

12 hours ago, CoolerDoomeR said:

It's better you choose a name for this.

I did consider that, but don't consider this fork different enough from the original to warrant a whole new name. Also I couldn't think of anything :/

 

3 hours ago, ketmar said:

@Lippeth be very, very careful, my friend! it may look innocent at first, like "oh, i won't do anything big, just modify some small things here and there", but after some time you may suddenly found yourself developing a full-featured source port!

The magic you devs put into your source ports and programs is nothing short of inspiring to me, and though I don't anticipate ever going further than being an enthusiastic part-time hobbyist to make things more fun for myself, getting close to your level would be something to be proud of. Thank you for the encouragement!

[Graf Zahl]

6 hours ago, ketmar said:

@Lippeth be very, very careful, my friend! it may look innocent at first, like "oh, i won't do anything big, just modify some small things here and there", but after some time you may suddenly found yourself developing a full-featured source port!

 

He doesn't need to. I welcome any motivated contributor to GZDoom itself. ;)

 

[Gibbon]

Great stuff!  I’d definitely say it’s better to contribute back to upstream, since your changes would be used much more in GZ than in your own port.

 

Im considering doing the same.

Edited April 2, 2022 by Gibbon

[ketmar]

3 hours ago, Lippeth said:

getting close to your level would be something to be proud of

i could trade that for vocals like yours (and a small bit of your soul). exclusive offering, no strings attached!

[PKr]

As a fellow non-programmer myself I totally understand why you "didn't want" to contribute to GZDoom directly and decided to create "your own source port" instead.

 

A few notes:

1. At first I thought it was an april fools joke, and that you really got me there. :D 

https://github.com/Lippeth/gzdoom/archive/refs/tags/g4.8pre.zip

https://github.com/Lippeth/gzdoom/archive/refs/tags/g4.8pre.tar.gz

I think you accidentally packaged a source code of GZDoom instead of... GZDoom. Yeah, you probably really should change the name of your project no matter how insignificant the changes are.

 

2. Given that you're trying to make it look as close to vanilla as possible, I think you missed a gl_tonemap setting (or was it intentional?). Set gl_tonemap to 5 (palette)?

On a side note there is https://github.com/AJMJ2012/XPaletteTonemap which is a really good alternative to a default GZDoom palette implementation.

 

3. GZDoom doesn't have a pistol start after death option. So I use this:

doommenu.cpp>

+CVAR(Bool, pistolstartafterdeath, false, CVAR_ARCHIVE|CVAR_GLOBALCONFIG)

g_game.cpp>

//
// G_DoReborn
//
EXTERN_CVAR(Bool, sv_singleplayerrespawn)
+EXTERN_CVAR(Bool, pistolstartafterdeath)
void FLevelLocals::DoReborn (int playernum, bool freshbot)
{
    if (!multiplayer && !(flags2 & LEVEL2_ALLOWRESPAWN) && !sv_singleplayerrespawn &&
        !G_SkillProperty(SKILLP_PlayerRespawn))
    {
        if (BackupSaveName.Len() > 0 && FileExists (BackupSaveName.GetChars()) && !pistolstartafterdeath)
        { // Load game from the last point it was saved

 

Given the scope of your project, I guess this is a reasonable "feature requrest"? :D You can make a fancy menu entry or something.

[Lippeth]

18 minutes ago, PKr said:

1. At first I thought it was an april fools joke, and that you really got me there. :D

I didn't notice the date until this morning and thought "well this may have been unfortunate timing, or confuse people at the very least". But I assure you it's in earnest. The main reason I didn't post it earlier is because I was mulling over whether I should at all because there are already so many talented people contributing without releasing their own versions, and am I so conceited that I think my ideas and changes stand out in any way? Turns out that I guess I am and I do, but mainly I wanted to feel out different possibilities and get advice from the people who actually know what they're doing without calling them out directly. I was halfway through writing a pm to Gibbon several times to ask for advice and ended up not going through with it because I wasn't even sure what I was asking.

 

31 minutes ago, PKr said:

I think you accidentally packaged a source code of GZDoom instead of... GZDoom. Yeah, you probably really should change the name of your project no matter how insignificant the changes are.

As far as I know the source code is automatically included on a release page beneath the binaries I added. But this is all new to me and I don't really know what I'm doing. I spent all morning trying to retroactively squash a few disjointed commits together in order to make a pull request and haven't yet succeeded. I also failed to separate anything I do into different branches and think I may have made things harder on myself. Honestly I'm half tempted to delete my entire fork and start over to make it easier to contribute. It sounds drastic but It's also fun and I'm confident that I can make all the same changes all over again, but with more clarity. If I were to have given it a unique name, it would have been something like "All My [de]Fault" alluding to the changes in default settings, but as Graf has pointed out, it would make more sense to just include an ini file which throws my naming scheme out the window. Either way I feel in over my head in a lot of ways, but am not overly worried about certain details while I learn.

 

30 minutes ago, PKr said:

2. Given that you're trying to make it look as close to vanilla as possible, I think you missed a gl_tonemap setting (or was it intentional?). Set gl_tonemap to 5 (palette)?

On a side note there is https://github.com/AJMJ2012/XPaletteTonemap which is a really good alternative to a default GZDoom palette implementation.

I intentionally left the tonemap setting off because I like to use Troo Cullers by Pixel Eater which adds the colormap effect of several IWADS while retaining the smoothness of 24 bit rendering and doesn't annihilate the look of dynamic lights. Plus I always considered the main selling point of GZDoom to be the true color hardware rendering so I left it. The funny thing is that I'm not explicitly going for a "Vanilla" aesthetic but rather a hyped retro one.

 

45 minutes ago, PKr said:

3. GZDoom doesn't have a pistol start after death option. So I use this:

<code>

I would say that I'll look into it and see how it works for sure, because more options is always better in my eye, but at the same time pistol start after death can already be achieved by disabling autosaves. Though I don't want to discount it before trying it out!

[drfrag]

I added a pistol start option to LZDoom and it was not possible just disabling autosaves, besides it would break hubs. I think it was even in the menu.

[Lippeth]

16 minutes ago, drfrag said:

I added a pistol start option to LZDoom and it was not possible just disabling autosaves, besides it would break hubs. I think it was even in the menu.

Just checked out the latest LZDoom and yeah that feature works great! I had no idea disabling autosave would break hubs, but it makes sense and is good to know. Makes me wonder how vanilla Hexen did it unless it's just a built-in autosave.

 

As far as being able to submit pull requests, I think I might actually need to either delete the whole fork and start again with that intention, or create a second account to hack away like a maniac, because it doesn't look like there's a way to do pull requests without including every commit ever (and there are over 30 of them at this point), so I don't know what I was on about earlier. And I don't think I'm able to fork the original again, even if I give one a unique name? Either way, it feels like I finally broke through a door that has been locked out of my reach for a long time, and I'm ecstatic to have opened up so many new possibilities.

[Gez]

There are ways to squash commits but Git doesn't make that very easy. There's a whole philosophical aspect about preserving commit history and stuff... but while that can make sense for massive features or overhauls that contain thousands of code changes to hundreds of files, is it really important to preserve commits like "oops, typo" or "forgot to commit this file" and similar alterations that don't change the effective complexity of the changes and just dilute the revision history with trivial points?

 

Anyways, random page I found that purports to explain how to squash commits: https://www.git-tower.com/learn/git/faq/git-squash/

[Gibbon]

21 minutes ago, Lippeth said:

Just checked out the latest LZDoom and yeah that feature works great! I had no idea disabling autosave would break hubs, but it makes sense and is good to know. Makes me wonder how vanilla Hexen did it unless it's just a built-in autosave.

 

As far as being able to submit pull requests, I think I might actually need to either delete the whole fork and start again with that intention, or create a second account to hack away like a maniac, because it doesn't look like there's a way to do pull requests without including every commit ever (and there are over 30 of them at this point), so I don't know what I was on about earlier. And I don't think I'm able to fork the original again, even if I give one a unique name? Either way, it feels like I finally broke through a door that has been locked out of my reach for a long time, and I'm ecstatic to have opened up so many new possibilities.

What I find to be easiest is to fork the repo and add in the feature you think is most useful or most interesting etc..  and do single Pull Requests with just that feature. Since it gives the most flexibility over which ones would be wanted vs which ones are not.  Rather than squashing it.  That’s just my style though.

[Lippeth]

Thank you all for so much great advice and help, you were the exact people I was hoping to get input from! That link helped Gez, thank you! But I ended up not being able to squash the commits I wanted to anyway because they directly conflicted each other, and I wasn't aware then that I couldn't submit a pull request using only specific commits. I wonder if by deleting the fork, forking again and keeping all the changes I don't want to submit pull requests with in separate branches while moving the ones I do to master, it would be easier to have my cake and eat it too. But then if I want to submit another one, wouldn't it also show the older commit(s) or is linking to specific commits in the comments acceptable? Or perhaps If I were to submit a pull request from a specific branch, would that help to keep things clearer?

 

18 hours ago, Gibbon said:

What I find to be easiest is to fork the repo and add in the feature you think is most useful or most interesting etc..  and do single Pull Requests with just that feature. Since it gives the most flexibility over which ones would be wanted vs which ones are not.  Rather than squashing it.  That’s just my style though.

If you were then to do another pull request later on, would it still show the older commit that you submitted previously or is that sort of thing fine? I think what I should really do is read through as many existing pull requests as I can and find the best practice by seeing how others have been doing it.

 

Apologies for the barrage of questions, I've also been researching like crazy it's just that every solution I find opens up new questions and options. I'm sure I'll mellow out with the more I learn, it's just all so new and exciting to me.

[Gibbon]

It may be very unorthodox but after any PR is merged, I delete the fork and then fork it again.  I’ve experimented with rebasing master and heads but GitHub still is stupid and shows previous commits from the fork.  So I just start with a clean slate each time.  I mean, it takes like 15 seconds to fork it so it’s not a big deal.

[dpJudas]

It is much easier to start any work by first creating a branch in git. Then PR the branch instead. When it is merged upstream you can simply delete the branch. That way you don't have to fork again and again.

[Gibbon]

46 minutes ago, dpJudas said:

It is much easier to start any work by first creating a branch in git. Then PR the branch instead. When it is merged upstream you can simply delete the branch. That way you don't have to fork again and again.

Definitely, if you're doing a lot of PR's for a project (~5 a day etc..), that is the way to go.

[Shepardus]

You could create a new branch, cherry-pick the commits you want to it, and create a PR from that. Squashing might also be easier after you've cherry-picked just the commits you want.

Edited April 3, 2022 by Shepardus

[dpJudas]

52 minutes ago, Shepardus said:

You could create a new branch, cherry-pick the commits you want to it, and create a PR from that. Squashing might also be easier after you've cherry-picked just the commits you want.

The whole point of always starting with a new branch is that you don't need to do any cherry picking, and you don't need to reset the master branch either. If you like your PR to be a single commit then squashing too becomes trivial. Even if upstream squashes your PR it all just works. It is literally achieving what Gibbon seeks without having to delete the fork and start over every time.

 

Oh and just for the record - it isn't like it is actually hard to create a branch: git checkout -B <branchnamehere>. So it is actually even faster than Gibbon's approach because you don't have to clone all over again. That said, if I don't continuously work on a repository I tend to delete my forks as well, but that's just because I don't like to look at a long list of forks on my github page. :)

[Shepardus]

1 minute ago, dpJudas said:

The whole point of always starting with a new branch is that you don't need to do any cherry picking, and you don't need to reset the master branch either.

Well yes, but I was speaking in regards to Lippeth who's got a bunch of commits mixed together on the master branch.

[Lippeth]

Definitely going to start working in branches moving forward, only because trying to cherry pick and squash certain commits after the fact aren't working due to some of them replacing the same lines of code with something new, and even trying to move them into a new branch won't work because they conflict. I was thinking of moving on to playing around with Eternity and/or PrBoom+ next as well, so I can try to start off on the right foot with those while I figure out if it's easier to delete the GZDoom fork and start over in a more organized manner or replace each thing with what was originally there only to redo them in a new branch and have an even longer list of commits. I suppose I can just keep my local directory and move it so I can keep all the changes so far for my own entertainment, and just add what I think might benefit the official version with a new fork.

[Gibbon]

1 hour ago, dpJudas said:

The whole point of always starting with a new branch is that you don't need to do any cherry picking, and you don't need to reset the master branch either. If you like your PR to be a single commit then squashing too becomes trivial. Even if upstream squashes your PR it all just works. It is literally achieving what Gibbon seeks without having to delete the fork and start over every time.

 

Oh and just for the record - it isn't like it is actually hard to create a branch: git checkout -B <branchnamehere>. So it is actually even faster than Gibbon's approach because you don't have to clone all over again. That said, if I don't continuously work on a repository I tend to delete my forks as well, but that's just because I don't like to look at a long list of forks on my github page. :)

You don’t need a capital B though.  git checkout -b <name> is fine :)

[ketmar]

8 hours ago, Lippeth said:

suppose I can just keep my local directory and move it so I can keep all the changes so far for my own entertainment, and just add what I think might benefit the official version with a new fork.

you can always create a branch from what you have now, then switch back to master, do "git reset --hard some-old-commit", and then do "git pull".

 

this way, you will basically move all your current work to a new branch, then "rewind" master back in time before you started, and sync it again. so you can have you cake and eat it too.