How will vkDoom affect GZDoom's future?

[Professor Hastig]

Having just discovered the new homepage, I'm a bit confused right now. There has been talk about GZDoom upgrading the renderer to vkDoom's but this homepage suggests it is committed to be a standalone project.
How is this supposed to work out?

Assuming that GZDoom eventually upgrades the renderer what will be the distinction between both ports?

I have to agree with what dpJudas said in another thread:

The writing is on the wall here: GZDoom will switch to a Vulkan-only version, the only question now is when. If GZDoom doesn't then it will become the choice of users that will insist it keeps compatibility with old computers, but the moment they upgrade themselves, they switch to VKDoom for the better performance. What a lovely deal that is, isn't it?

This essentially means that GZDoom is either forced to keep up to date with vkDoom or be relegated to becoming the low end fallback port. But regardless of how I try to twist it - there doesn't seem to be a place for three forks here, only for two.
So in scenario one, GZDoom stays what it is with vkDoom becoming the choice for high end systems and in scenario two, GZDoom splits but keeps its mainline updated with vkDoom, but in that case, what's the distinction? We'd have two ports that aside from a handful of different option presets are identical.

[GreaseMonkey]

It depends on who wants to throw in the towel first. Until then, things are likely to be pretty exciting for both versions. Also, even if VKDoom insists on being a standalone project, there's nothing stopping the GZDoom developers from integrating its improvements, or VKDoom from integrating improvements done in GZDoom.

Consider that DSDA-Doom and Eternity are both still under active development and still innovating - the former being a resurrection of a resurrection of PrBoom, and a lot more conservative with its innovation. And then of course there's always room for Chocolate Doom, which often has people forking from it as a good base to start My Very Own Sourceport (incl. Doom Retro). Lastly, a lot of people are likely playing on Unity Doom. That's more than three forks right there.

[dpJudas]

See it like the difference between Linux distributions. The nature of open source works in such a way that the code is mostly the same, but there are some differences in what the goal of the distro is and what patches got merged in and what the defaults are. You could say all Linux distros are the same, or that they are very different, depending on your viewpoint.

VKDoom is a project that only cares about computers that are also suitable for playing other modern games. The general goal of the source port is to help content creators make cool new UDMF maps with lightmaps and so on. The source port does not really care about Boom maps and such. It supports them, but only thanks to GZDoom heritage.

I can't speak for the GZDoom project, but historically the focus here is a lot more on being able to play as many Doom mods as possible. Dehacked and Boom support is considered important. Supporting a variety of hardware and platforms has been a goal. Keeping the user fully in control has sometimes been a deciding factor for whether a PR was approved or not.

The primary reason for me to create this fork has been that every time I mentioned any feature a non-gaming computer from 1865 couldn't handle there was loud complaints and people actively working to stop me from doing it. I simply got fed up with that. GZDoom will most likely merge in the main VKDoom features at some point and yes at that point they'll be very similar for a while, but if a Geforce 60 series card gets released that unlocks something interesting, then VKDoom will get the feature right away even if it means that the Geforce 20 user at that point now will have to upgrade the hardware. That's the pros and cons of targeting modern hardware: what is modern today is often becoming obsolete in 5 years time.

[Caligari87]

It seems to me that GZDoom should still be the port of choice for players and modders interested in playing the classic games and mods for them. If nothing else, that use case will always receive first-class focus regardless of underlying features and tech.

VKDoom on the other hand seems specifically targeted to be an engine for standalone game development and creator control, backwards compat and player freedom taking a backseat. That's something GZDoom is marginally good at only by coincidence (and in spite of design ethos). It's a pretty huge distinction philosophically even if the implementation is mostly down to a few cherry-picked configuration differences.

I don't really see a conflict personally.

[Graf Zahl]

So far nothing of these things has materialized. Aside from a handful of poor defaults (e.g. disabling autoaim by default in a Doom port is a no go for me) and a few options I prefer to be commented out (disabling the automap on playable maps) I could take the code as-is and brand it GZDoom 5.0. Of course it's still too much WIP right now to switch over.

[Caligari87]

>poor defaults

And that's the difference. A no-go or blocked feature for a Doom port (often rightly so in GZDoom's case, reluctant as I am to say it), is exactly the kind of defaults and level of control a standalone game wants to have available by default without fighting the engine or recompiling.

[Professor Hastig]

There are no new options, just a few altered defaults. It's all in a single commit in the 5.0 branch so it's easy to compare.
In the end for standalone games the defaults of existing options should not be relevant. You'd have to recompile the executable anyway, if only for injecting your own game name ans icon into it. Otherwise it would use GZDoom's global config which is really a bad idea for a standalone game. But since you have to work on the source anyway, this is the right time to default all CVARs to your liking.

So, if that is supposed to be the point of vkDoom, I don't think it has a point, but from some discussions I had this seems to be where some people, mainly those not involved in the project, see it.
dpJudas's answer makes a lot more sense, which essentially boils down to a testbed platform where new features can be developed, tested and tuned until they are ready, at which point they will end up in GZDoom's mainline.
Whether a port that is destined to be in a constant WIP state is good for independent game development remains to be seen, it'll be a constant balance between robustness and being on the bleeding edge.

[dpJudas]

Oh but it has a point - the changes you see in VKDoom would not have existed without it and thus the GZDoom 5.0 branch also would not have existed. Don't get things confused here.

Let's be clear about one thing here: VKDoom is not a testbed platform. It isn't QZDoom. It is also not in a constant WIP state. You can play with VKDoom just fine and we could release it tomorrow if we wanted to. The only thing reason we haven't is that we'd like the lightmap feature to be 100% done before doing so.

I'm trying be cooperative with GZDoom in an attempt to make both projects win. I don't have to do that you know. I also didn't fork GZDoom just because I was unhappy about some defaults. There is more to it than that.