Different source versions for forking with my own changes

[nova++]

So, I'm having a bit of struggle here. I've got several engine changes I've done that my project makes use of. That's working but it's based off the specific 3.88a LZDoom (lzdoom because I am going to do some work on this on an old laptop that can't smell opengl 3...) release from the website. But today I decided to try and bring my changes over to the most recent version - before I do any of that, I of course want to compile it as it comes and get it running before introducing any of my changes.

But that's where I start to run into trouble. In developing my project, I am using the software truecolor renderer with the intent of creating a palette later on... but for some reason the truecolor SW renderer has dropped in performance by a fair amount between the 3.88a version and the version I grabbed from drfrag's github (https://github.com/drfrag666/gzdoom) - 107 fps at 1600x1200 on mine, vs 83 fps on the new build. (Using SW vs HW is another can of wax, mostly my personal preference in the appearance, sprite clipping etc)

In general this has me feeling very uncertain about the best way to actually execute these changes I want. I am trying to keep them minimal, using ZScript where possible, but some things are not really doable (or would require inordinate amounts of scripting to work around, etc).

Or, heck, maybe I just grabbed the wrong branch from the repo. I just picked the master branch.

I guess I don't really have a firm question here. I have just been overcome by indecision and would like some feedback...

[Enjay]

How many of the changes that you want to make to the engine cannot already be done by other means? The reason I ask is that I used to keep my own fork of the engine for my (admittedly minimal) changes but now all of these can be handled by built-in features so I no longer need to bother with my own fork.

If there are some things that cannot be done using built-in features, perhaps they might be something that you could submit as a feature suggestion with a pull request for your work?

The real beauty of not going with you own engine is that you don't lock your project to that specific version of the engine. Newer versions of GZDoom that may contain bugfixes, compatibility with newer hardware or whatever will automatically work with your project if you are using built-in features. If your game is tied to your engine, then it's up to you to keep it current.

[nova++]

Yeah, I know, I have that conversation with myself a lot. Part of it is just wanting to be able to distribute this as a wholly standalone project without having to worry about engine version compatibility. One iwad and set of assets tied to a specific engine version, that doesn't have to worry about any other games being played on it. From there, it kind of becomes "well, If I'm making it standalone anyway, what other fun can I have?"

The single biggest one is pretty selfish, admittedly - overriding all the 1.2x pixel aspect ratio rendering so I never need to worry about shrinking all my sprites and textures by that factor every time I make something. I know I can modify the pixelratio field in mapinfo, but that only affects the map itself and not things like the player's weapon sprite. The only workaround I have found for the weapon sprite then is to add in a downscale factor in every sprite entry for weapons, which gets old fast. So I just tried to nip that in the bud.

As I mentioned, some things would be quite possible but I either couldn't figure out how, or the only way I could figure out would be incredibly ugly scripting. I wanted to modify resurrection logic to store a reference to the actor being resurrected, for instance, but everything I could think of scripting-side would involve awkward things like checking a radius for any actors in their Raise state, etc...

Other things include some AI changes, such as a RETREAT flag that makes monsters move away from the player, but doesn't change their attack rate in the way FRIGHTENED does, and a (really gross and kludgey) setup for making them avoid damaging floors, even if the damage-taking side is done in zscript. As I dug through both script and source to see what I could do, it really looked like I would have to totally rebuild the A_Chase function in ZScript from scratch to do what I wanted...

And also a system for accelerating/decelerating moving sectors smoothly like can be done in build engine games. Once again kind of kludgey but I'm pretty pleased with it. I can't even think how to do that scripting-side - short of some sort of horrible hairball of ACS that loops through and repeatedly calls multiple sector movements or whatever.

As you say though, if engine features can cover it, I would be happy to utilize them. I already have undone several changes, mainly where I was changing default cvars because I was being a dumb and didn't realize DEFCVAR existed

[drfrag]

The master branch is a fork of modern GZDoom, the source for the 3.8x series is in the g3.3mgw branch as always.

[nova++]

The master branch is a fork of modern GZDoom, the source for the 3.8x series is in the g3.3mgw branch as always.

Thanks, I am still learning my way around the project structure as I go into this. I had a hunch I was in the wrong place.

[Enjay]

Other things include some AI changes, such as a RETREAT flag that makes monsters move away from the player, but doesn't change their attack rate in the way FRIGHTENED does

That's actually something I've wanted for a while too. There's a horrible hacky way to do it (give an enemy a -ve speed and reverse all their movement sprites) but an actual flag for doing it would be even nicer. Perhaps another one that makes them run away, but not attack at all. I guess that both are problably possible via ZScript (I can even think of a way of doing the second one in DECORATE) but an actual simple, built-in, toggleable flag would be even nicer.

[nova++]

Other things include some AI changes, such as a RETREAT flag that makes monsters move away from the player, but doesn't change their attack rate in the way FRIGHTENED does

That's actually something I've wanted for a while too. There's a horrible hacky way to do it (give an enemy a -ve speed and reverse all their movement sprites) but an actual flag for doing it would be even nicer. Perhaps another one that makes them run away, but not attack at all. I guess that both are problably possible via ZScript (I can even think of a way of doing the second one in DECORATE) but an actual simple, built-in, toggleable flag would be even nicer.

It's a mega simple change. I would try and get it submitted but I have never done any sort of contribution to an open source project before, so I wouldn't know where to begin. There's also some interaction with other flags (like nofear/frightened which also invert the movement delta) that probably would occur in my implementation...

Anyway, as for the original topic of this thread, I think I will just stick with my current working version and try to keep the changes as minimal as possible so I can later merge them into a more up to date version more easily