Source Ports personal deal breakers

1 hour ago, Graf Zahl said:

 

There's a very simple reason for this. In the old days the minimum limit was 16 and 32 the default. And it prompted bug reports from people who expected everything to work normally when setting this to the lowest possible value. Well, of course it did not so the values were increased that the fallout of the tinkering does not reach our bugs forum. Simple as that.

 

Maybe make it so that the minimum value only applies in the UI, but the cvar itself can be set to a lower value?

On 11/14/2023 at 4:03 PM, Csonicgo said:

Creating broken play styles for players from whole cloth: I once would get angry about silly things like "terrain effects" enabled by default and "limit lost souls" being off by default, and I will even let "crouching" slide because it's at least useful for modders - but these are nothing compared to a certain source port whose authors decided to change how doom works on a fundamental level - adding vertical spread to hitscans.

 

Who in the world would want to do this? Well, do I have to say it?

 

This neuters the shotgun. In fact, the only reason this change isn't more of a disaster is that the BLOCKMAP collision detection bugs are fixed. This breaks Doom's  game balance, in insane ways that should be obvious to anyone who used the Doom shotgun, and since it's in a spot no one would think to check (Player Setup, where you change skins and colors and other harmless things) you might never find the stupid setting to turn it off if you accidentally turn it on - which I've done, somehow. Twice.

 

Since this is in such a silly spot, and players who use this port may not be as knowledgeable about the game as most other players, they may think this is "how doom works" and wonder why they're getting owned by monsters on high ledges relative to the player, and their shotgun keeps missing, because someone thought it would be cool to add vertical spread to hitscans. We have weapon mods for this kind of stuff, right? Why are we building weapon mods into the port?

Sorry, this was me and is my only contribution to the port so far. It's in player setup because it's not relevant in any other category and fits best with other gameplay changes like autoaim and always run, and it can also be disabled in gameplay options even if it's enabled in player setup.

The super shotgun already has twice the amount of vertical spread than anything I've added and can't be disabled, so the thought was that adding it to other hitscan weapons as an opt-in will make hitscan weapons more visually consistent at the cost of vanilla behavior, while still being able to snipe at long distances with the first shot of the pistol and first two shots of the chaingun, but the main reason the feature is in the game itself rather than a mod is because it's far cleaner to add a small bit of code only once instead of needing to replace every weapon, and is something I thought could enrich casual play for others.

I knew that it was one of those things that isn't for everyone and because it definitely affects gameplay at long distances and extreme height differences, it's not enabled by default. I'm not worried that it will give new players the wrong impression of Doom because the only way it can be enabled is to toggle it on, and new/casual players are usually less likely to enable options they don't understand (except by accident of course).

If someone dislikes its existence so much they want to strip it out, it won't hurt my feelings, just let me know so that I can update the mods I've made that rely on the feature.

On 11/4/2023 at 1:34 AM, Graf Zahl said:

 

You have to be careful with this. Not everybody wants to play mods on the most 'appropriate' complevel, but if these get enforced you will get negative feedback from those who prefer to play with all options on.

Optimally a map should advertise which settings it needs and which it recommends, but experience has shown that modders often tend to conflate these two and enforce everything which then forces ports to implement countermeasures.

 

3 hours ago, Scuba Steve said:

Did I mention ports which enable texture filtering by default?

At the risk of raising the dead by speaking this forbidden incantation: Why is texture filtering enabled by default?

@Graf Zahl I know that you are sick of fielding this question, and unlike some others in this community I can honestly understand why you have made the choices you have and your right to make them as the port maintainer and creator. But if you are concerned about negative feedback from your userbase at all, this particular feature has generated more negative feedback than any other and is unique in its implementation; much if not most of the rich GZDoom cosmetic featureset is disabled by default and available to players who wish to use it.

As we have seen in this thread, there are countless nitpicks and preferences of sourceport performance comprising a near infinite number of perspectives--far too many for any port to ever satisfy (and frankly, to do so would quickly destroy the creative authority that animates anyone insane enough to create software for free)--but in contrast to other entries, GZDoom is likely the most popular sourceport in the world. Does it not have some responsibility or hand in the presentation of these games to a new audience?

I've been around long enough to remember how exciting ZDoom and its features were in the early days. I think that Doom was still "alive" in some sense as a game at that time, that these developments were a part of that game and its growth. Things like texture filtering or jumping made Doom feel modern, advanced, and relevant. But in 2023, Doom is less a game and more a cultural artifact or genre upon itself that history has isolated certain identifying features from. Doom's art and visuals are as definitive a feature as its movement or mechanics, and the particular quality of that art has come to signify Doom and games of its era as an important piece of what makes this game what it is. @Scuba Steve is an artist who has dedicated a large portion of his life to this artistic medium and is passionate about its preservation, I can understand why this is important (and infuriating) to him.

Resolutions can be increased, limits removed, and these changes do not detract from the essence of the game--if anything Doom is more like Doom now that these boundaries have been breached. But for the thousands of players whose first experience of this game is through GZDoom; a port that innovated through ease of use and customization, a port that has enabled not only the most popular Doom mods of all time but itself has become a common gateway through which people are introduced to the Doom engine, game modding, and programming, a port that is for all intents and purposes the port of record for the average Doom enjoyer---why must these players be started on (what the majority of the community believes is) the wrong foot? It's such a simple change, it's a change that you @Graf Zahl can choose to make at seemingly no cost. GZDoom is a project defined by choices and is distinctly not a preservationist platform, but this single feature generates such division I have always wondered why it persists. I want to stress that I'm not trying to be antagonizing or diminishing in any way, and that ultimately the decision (rightly) belongs with the port's creator. Too often this community forgets that the people who make things have authority over how they work and that creativity is not a democracy, but I would hope that a dedicated community's opinions are at least considered when making decisions that impact generations of players.

Doom in 2023 is a Ship of Theseus, and unlike @Csonicgo I don't see supporting endless backwards compatibility for a minority of users who wish to use obsolete hardware as a priority (fortunately for those who do, CSG and others will implement such changes!) But the Ship should still embody the thing that its meant to represent, and I think it would be a great service to players and the next generation to embody Doom's visual style in its most popular sourceport.

4 hours ago, Graf Zahl said:

but since 32 bit already requires disabling both the JIT and Vulkan

The vulkan backend doesn't really have anything that prevents 32-bit (unlike JIT, which requires supporting an insane amount of legacy 32-bit calling conventions). The VulkanDrv project for UT99 also uses ZVulkan and works perfectly fine as a 32-bit DLL for UT.

That said, I'm not personally going to verify or even fix any 32-bit issues with the Vulkan backend because I simply don't care. It isn't my hobby or job to provide support for anything unless I choose to, and I don't want to deal with old hardware and OSes and that is why you never seen any 32 bit executable or anything of that sort from me. If someone provided a PR on the other hand I'm not against merging it, assuming it was done properly. Even then, I'd not begin testing 32-bit and if it breaks again then it breaks.

39 minutes ago, Individualised said:

Maybe make it so that the minimum value only applies in the UI, but the cvar itself can be set to a lower value?

If there was a point to it we would have kept the lower limit, but ultimately such a thing doesn't add anything of value at the potential risk of people screwing up their config without knowing. There's really no benefit to it at all

No support for DDF

While we’re on the subject of the texture filtering question being dodged, I’d like to bring up a poll I conducted on twitter a few weeks ago. Ran it for three days to really make sure enough time for every voice to have their chance.

why specifically did I make this poll? Because I caught “whispers” of it being a controversial thing to start turning off by default, which I refused to believe.

I definitely feel like a relative nobody on Twitter and in the Doom community, so the fact I managed >700 votes that show for a fact that we do not like texture filtering is pretty astounding.

On the thread’s subject, if people start making forks of GZDoom and actually taking suggestions from its users a lot more seriously, a source port deal breaker for me will for sure be its devs showing unwillingness to work with said users. I want more tools to play with, and I want more functionality and control to flex with, so if silly little things like texture filtering is what gets devs hung up, despite very obvious out cry to make change happen, I’m moving to greener pastures.

1 hour ago, kevansevans said:

 

On the thread’s subject, if people start making forks of GZDoom and actually taking suggestions from its users a lot more seriously, a source port deal breaker for me will for sure be its devs showing unwillingness to work with said users. I want more tools to play with, and I want more functionality and control to flex with, so if silly little things like texture filtering is what gets devs hung up, despite very obvious out cry to make change happen, I’m moving to greener pastures.

 

I mean making a fork is kinda easy, but keeping your fork updated with the latest features from upstream might be more complex.
When moq author put a spyware-like functionality on his library everyone started to fork to remove that thing, but keeping new features/bug fixing (and squashing) and so on, that's another level.

I suppose it's the same with a source port, especially with new features, and if such changes are other than changing a default cvar value, maybe keeping compatibility with older hardware (and for older I mean +5 years which starts being centuries for the IT world).

vkDoom looks interesting since looks more than a "rolling release" of GZDoom breaking compatibility by design.

and of course: before accepting a suggestion, there should be some controls before to be sure everything doesn't break.

This isn't a dealbreaker, but I would love to see more ports start considering adding ingame ways to turn on command line toggles, such as -fast, as well as ingame WAD selector.

I think by now this is the most outdated part of playing Doom, especially if you are playing on a gamepad or a console-like platform such as Steam Deck.

I know Doom is an old game and so people will always be using the command line for it but still. Many Quake ports have come around on this by now.

Yes there are launchers, but they aren't really gamepad-usable, and not nearly as elegant as having them as menu items under "New Game" or "Options" would be.

I even think the ingame WAD selector should be smart enough to autoselect the IWAD based on what the map lumpnames are and what textures it is trying to load that aren't in the PWAD, as well as automatic complevels. (obviously overridable by commandline if a user wants). I don't think the user should have to need to have to keep track of all of those things themselves to play a WAD. Maybe even automatically starting on the right map on New Game if it's a wad with one map that isn't MAP01.

This is further pipedreaming, but an ingame implementation of something like Doom Launcher's metadata for wad selection would be even nicer. Given how much of Doom's appeal comes from the sheer amount of content out there, a port centered around presenting this content to the user in a modern way would be cool. I think for this I am mainly inspired by N++ and how it has a random demo from any number of its thousands of levels play at startup, and being able to browse and play community levels right from the game itself.
The recent Unity port is a start but I think it can be developed even further considering categories and tags and so forth.

Obviously it would be its own project in and of itself and wouldn't be something I would expect ports to standardize on.

Must have:
* Texture filtering
* Dynamic lights
* DECORATE or DED support
* ACS or XG support
* Mouselook

Nice to have:
* The ability to customize the HUD without needing a WAD
* 3D model support

Not wanted:
* New widescreen graphics enabled by default
* A different default interface font
* Voxels enabled by default

9 hours ago, kevansevans said:

I definitely feel like a relative nobody on Twitter and in the Doom community, so the fact I managed >700 votes that show for a fact that we do not like texture filtering is pretty astounding.

I'd be very careful with polls about things where one side feels very strongly about it while the majority of the other side seems to be mostly indifferent to the issue, as long as it's still accessible. Texture filtering seems to be one such issue where it is very easy to mobilize the opponents but also very likely to get a shrug from its proponents, at least that's the impression I get from the people I know.

9 hours ago, kevansevans said:

On the thread’s subject, if people start making forks of GZDoom and actually taking suggestions from its users a lot more seriously, a source port deal breaker for me will for sure be its devs showing unwillingness to work with said users. I want more tools to play with, and I want more functionality and control to flex with, so if silly little things like texture filtering is what gets devs hung up, despite very obvious out cry to make change happen, I’m moving to greener pastures.

What does "work with the users" even mean? The way I interpret it is to give up one's own vision of the project and just do what the users want. What you get is 100's of people pulling a project in different directions, turning a motivated developer into a tired manager who is busy dealing with customer requests. To me this doesn't sound like a hobby anymore, but like a stressful unpaid job, and the likelihood is high that a developer caught up in this will eventually quit and move on to greener pastures.

3 hours ago, Professor Hastig said:

To me this doesn't sound like a hobby anymore, but like a stressful unpaid job, and the likelihood is high that a developer caught up in this will eventually quit and move on to greener pastures.

 

That's a very mature outlook you have there.

3 hours ago, Professor Hastig said:

Texture filtering seems to be one such issue where it is very easy to mobilize the opponents but also very likely to get a shrug from its proponents, at least that's the impression I get from the people I know. 

If the "other side" is shrugging, then that by definition means they don't care if it's there or not, meanwhile the people who do care are the ones that are voting or saying it shouldn't be there. And if even the artists like Scuba Steve are objecting then you have to take stake in that, as they are the ones that objectively know how they need things to look for their work.

19 hours ago, Scuba Steve said:

Did I mention ports which enable texture filtering by default?

I didn't expect someone telling me to remove texture filter until someone mentioned it on discord

14 minutes ago, Edward850 said:

as they are the ones that objectively know how they need things to look for their work

This is always an uphill battle with anything Doom though, regardless of how you intend for something, someone may very well just handle your work differently anyway, and that's something I feel you've gotta come to terms with.

I had an ambush in a map which I thought was nice and mean, one where you'd have to think quick, and I'm overall pretty proud of that map.

Then I see a recording of someone playing that .wad with a mod called Guncaster, where he gets to that ambush and then promptly freezes time, selects a spell, and then melts all of those monsters with a rainbow beam in a second, like they were nothing.

"Oh." Kind of disappointing to see that encounter apparently not mattering at all, but I also realize quickly that he might as well have played with IDDQD, and I kinda can't lament these things much, he ruined/"ruined" the experience for himself and that just isn't my problem.

So regardless of if I think that it would be better if GzDoom had no filters on by default, and how I think my sprites and textures look far less good when smudged out like that, there's precious little sense in letting that bother me. Fucking with things is the nature of Doom's beast, after all.

John Romero explicitly said it should be off by default. That should be the end of the discussion.

3 minutes ago, Scuba Steve said:

That should be the end of the discussion. 

It is if you're the kind of person who regards developer intentions as absolutely sacred gospel which should never be strayed from, and I say that as someone who agrees with his opinion.

John Carmack also published the source code and told people to do whatever with it. He never said "... Just not these things which John Romero wouldn't particularly care for, mm."

12 minutes ago, Scuba Steve said:

John Romero explicitly said it should be off by default. That should be the end of the discussion.

John Romero plays with it on, see any of his streams.

I find things at different times that make me want to play in any number of ports.  That said, I will not play in any port that has any of the following:

• Is Doom95

Beyond the above things there's not much in the way of deal-breakers.  I like freelook and don't like infinitely tall monsters and generally find that Crispy meets my preferred balance of primitivism and QoL improvements, but there are times that I want (or need) to play in GZDoom, Eternity, or even PRBoom+ for a different feel and compatibility.  Still lots of ports I haven't tried that I may love.

Sorry for the interruption we may now continue with yet another noble but completely futile attempt to engage Graf on the texture filtering issue

56 minutes ago, Scuba Steve said:

John Romero explicitly said it should be off by default. That should be the end of the discussion.

Wouldn't Adrian Carmack's opinion be more important in this case, since he is the one who drew the sprites and textures?

I still how the "texture filtering" is a deal breaker, because it's just an option you can change in less time than make a thread to complain 😅

This is gonna be kind of a nitpicky one and I don't know how well I'm gonna be able to explain it, but here's mine: if the player movement feels "off".

The reason I put the word "off" in quotes is that I know few source ports go out of their way to modify the player behavior extensively, but the movement can still feel drastically different between them for reasons unknown to me. Well, in most cases - GZDoom knowingly sacrifices vanilla accuracy in exchange for its extensive feature set. Ever since I migrated from GZDoom to DSDA-Doom as my primary source port, the movement in GZDoom has felt so weird to me that I don't find myself launching it all too often anymore. (There are other reasons too, but I'm going to refrain from stating them here, lest this thread turn into yet another drama central.)

Then again, I've grown to favor more vanilla-accurate source ports in general, and a lot of my complaints about player movement have to do with what I've gotten used to. And if I were to change from DSDA-Doom to another source port as my primary (which is fairly unlikely), chances are DSDA-Doom's movement would start feeling weird to me after a while. All that being said, though, I rarely draw lines when it comes to features or settings a source port can and can't have - if it plays Doom, I'm happy. It's solely the feel of the movement that determines whether it ends up in my "usual rotation" or not.

My deal-breaker: the source port is not either DSDA-Doom or GZDoom.

8 hours ago, Professor Hastig said:

 

I'd be very careful with polls about things where one side feels very strongly about it while the majority of the other side seems to be mostly indifferent to the issue, as long as it's still accessible. Texture filtering seems to be one such issue where it is very easy to mobilize the opponents but also very likely to get a shrug from its proponents, at least that's the impression I get from the people I know.

 

 

 

 

What does "work with the users" even mean? The way I interpret it is to give up one's own vision of the project and just do what the users want. What you get is 100's of people pulling a project in different directions, turning a motivated developer into a tired manager who is busy dealing with customer requests. To me this doesn't sound like a hobby anymore, but like a stressful unpaid job, and the likelihood is high that a developer caught up in this will eventually quit and move on to greener pastures.

 

I disagree, if the developer such as yourself as an example (even though you arent, but lets pretend you are for the sanity of this world), that you enjoy builidng that engine very much, where you are open for feedback, you should have an open mind of what else would people like to see of making a popular engine then having principle getting in the way of how you think or simple dont care what people think. If you aren't open mind about this of sharing this project, but would like the world to know it exist, you can just set it to private while announcing you are no longer acceptting feedback or suggestion for your engine, then people will just leave you alone  so you can work in peace so people can move on their lives with or without you.

Either way, its a win for the community both sides where they can use the engine or look for other engines that accept feedback else where to support it as popular engine if that particular engine be left for dust collecting in the feature, so no one here will lose sleep over it but for sure that developer will.

Its for the best they move on or be left behind, their move, now.

19 hours ago, Graf Zahl said:

 

If there was a point to it we would have kept the lower limit, but ultimately such a thing doesn't add anything of value at the potential risk of people screwing up their config without knowing. There's really no benefit to it at all

1 minute ago, Incognitonightraven said:

 

 

I disagree, if the developer such as yourself as an example (even though you arent, but lets pretend you are for the sanity of this world), that you enjoy builidng that engine very much, where you are open for feedback, you should have an open mind of what else would people like to see of making a popular engine then having principle getting in the way of how you think or simple dont care what people think. If you aren't open mind about this of sharing this project, but would like the world to know it exist, you can just set it to private while announcing you are no longer acceptting feedback or suggestion for your engine, then people will just leave you alone  so you can work in peace so people can move on their lives with or without you.

 

Either way, its a win for the community both sides where they can use the engine or look for other engines that accept feedback else where to support it as popular engine if that particular engine be left for dust collecting in the feature, so no one here will lose sleep over it but for sure that developer will.

 

Its for the best they move on or be left behind, their move, now.

This comment applies to you, dont take it from heart but this is what comes down to so you can just give up and move on. Time to turn a new leaf from this, and god bless you in your holy journey of peace of mind.

Just curious, for those of you for which default texture filtering is a dealbreaker, how many have ceased using or creating content for GZDoom completely?

1 hour ago, dasho said:

Just curious, for those of you for which default texture filtering is a dealbreaker, how many have ceased using or creating content for GZDoom completely?

It’s more of the principle of it that’s a turn off for me. Yes, it takes ten seconds to turn off, and I’m a happy camper, no big deal.

However: Not all GZDoom users know that this is a setting. This became painfully obvious when I started getting my content out into the world and watching other people play, and as far as I know, I can’t distribute a mod that can turn this off locally. This means that, whatever artistic vision I might have for anything I make, it’s going to get undermined.

This is why it’s such a stupid issue for them to be this stubbornly hung up on, and why it’s reflective of a poor relationship between the devs and users. The majority of players hate this feature. The original game was not designed with filtering. Very few people are making high res assets that justify filtering. Those that do like it will go through the same ten seconds to turn it on. It’s a waste of time to fork the engine just to make an executable that has it off.

It’s petty, and not the sole petty thing that’s been pulled out of spite in GZDoom’s development history.

Edit: Forgot to mention if it’s a deal breaker. With VKDoom hot in development, yeah it’s going to no longer be my engine of choice with how things are going, and it’s not just because texture filtering is off.

It's hard for me to call anything a "dealbreaker" because in some cases, one's options are limited. But certainly I have favorite features.

- Drop-down Console
- Keybind system (ideally to console commands)
- Autosave or rewind/fast-forward system
- Show secrets on automap
- Differentiate found vs. unfound secrets on automap
- Organize save files by loaded WAD(s)
- Tag finder (shameless I know but I use it constantly, it has to be on my personal list)

- Warp to automap location

- Boom/MBF support

On 11/4/2023 at 6:34 PM, Graf Zahl said:

 

You have to be careful with this. Not everybody wants to play mods on the most 'appropriate' complevel, but if these get enforced you will get negative feedback from those who prefer to play with all options on.

Optimally a map should advertise which settings it needs and which it recommends, but experience has shown that modders often tend to conflate these two and enforce everything which then forces ports to implement countermeasures.

 

This is why I love that GZDoom has the option to forcibly override the strange community obsession with disabling crouching and jumping as if EVERYONE is going to bunnyhop all over every map, and why I do not add that stuff to my patches, as I believe in letting people play how they want. Sometimes I do wish that in my personal copies I had a mapinfo command to automatically set compatibility though, im forgetful and often end up on a Boom wad with Doom Strict and things break.