Blzut3

This is the what-about-ism thing I mentioned a few times. The light mode question has a lot more developer consensus than the others, so it was the low hanging fruit. Since this thread is in danger of being derailed to Doomworld's favorite topic (there were a couple attempts in this thread already), I don't want to say too much more beyond that no one thinks all of the problems were solved by removing that one option. For what it's worth, I do sometimes wonder myself if GZDoom should just rip the band aid and revert a lot of stuff that was changed just because changing things was cool in 1998. However I've seen enough projects (i.e. Python 2->3) attempt stuff like that to know it would be about 10+ years of people sticking to the old version if all of that done at once without care. I don't think GZDoom needs to be demo compatible, but there's definitely a lot in there that in hindsight probably should have just been mods but of course the interfaces for that didn't exist at the time. (Similar argument I made to have Zandronum divorce itself from the Skulltag stock content to get rid of some random breaks that the Skulltag mods did. Which of course had a lot of resistance despite being fully compatible by just loading the mod.) I edited my post to retract. I apologize for the accusation of malicious intent. I'm glad you see where my concern came from though.

I'm pretty sure I already answered this, but once more: Vanilla maps don't necessarily have MAPINFO (cause you know, vanilla didn't have that) and should just work correctly out of the box. We want to encourage GZDoom mappers to use the MAPINFO option if they're designing maps for a specific light mode. This way users that don't read the directions get the intended experience. (If you think users read, do software development. You'll find out how difficult it is to get users to read anything very quickly.) If the light mode didn't matter that much that setting it in MAPINFO was seen as unnecessary then clearly the new default was deemed an acceptable way to play the mod by definition. Point 3 is why your so called "consequence" doesn't make sense. Yes, it is understood that due to people being unaware of the MAPINFO option being around since forever (I too was unaware, but as a software renderer enthusiast I honestly never had a reason to care), there will be some mods that fall under point 2 but didn't set the option. Where we disagree is on whether this fact is a big deal. You do know I've been a (G)ZDoom, Skulltag, and Zandronum developer right? Just not very active right now. As for the first sentence, users not reading shouldn't be a controversial statement to you, or you haven't interacted with users long enough. Of course there is resistance and that was expected. There's literally no change that can be made without someone complaining, hence the xkcd 1172 reference. The level of resistance seen is about the level that was expected. I engaged in this thread because I thought those championing the dark setting were motivated by different things than the initial wave of people complaining about the lack of the "legacy" setting, but it seems in the end the two camps are more similar than I thought. Even if we did keep a list of specific names, we are not going to facilitate your desire to harass. Edit: Re-read your previous to this post mentioning this. While the part about not having a list stands, I see that you intention was to avoid playing their mods which is less harsh than I assumed. My bad for the accusation.

Which I guarantee you most users didn't read, so oh no they might experience the mod correctly now with the update. Whatever will we do! There was nothing presented here that was unforeseen. That's why you think you're "not being heard."

Little nit picky, but Crispy's resolution is 640x400 not 640x480. I double checked a few things about WinDoom out of curiosity and the 640x400 mode was only in the earlier builds (the third one seems to only render at 320x200). The earlier builds also lack basic functionality so even if someone had a copy at the time (it wasn't widely distributed from what I can tell), they likely wouldn't have used it (and I'm not sure how well 640x400 would have ran on hardware available at the time). So from a practical stand point I guess the Macintosh version was the first? Again, assuming no DeHackEd. I suppose an interesting corollary to this question would be, when was the first version of a source port with DeHackEd support and 640x400. It definitely wasn't long after the source code was released since the linked Legacy 1.11 release advertises it.

From a rendering point of view, I'm not sure the 90 degree wall limitation actually provides a huge performance benefit. After all the SNES and derived ports switched to rendering walls like Doom for additional performance and I can't really imagine that allowing arbitrary segs would make a huge difference there. However the tile based nature of the maps definitely does play a role in simplifying things throughout the code, so arbitrary decorative wall angles would be somewhat limited in use while retaining everything else. To that end, a note about the AI: Notably the path finding function is the same from Catacomb up to at least Doom 3, but it is true that said function's decision is used in Wolf3D to just pick the next open tile to move to which means Wolf3D didn't have to do what one would normally consider collision detection for anything but the player and projectiles.

Doom for the Macintosh also had high resolution support, so I guess that takes you back to June 1995 at least (according to the Doom wiki). The wiki also mentions Doom95's predecessor WinDoom supporting 640x400 rendering in June 1994, although I haven't personally verified that. But that would suggest there's a very narrow window of time where levels were being made and it wasn't possible to run at Crispy's resolution as long as DeHackEd wasn't involved.

What Dark Pulse said, but to expand a bit: sv_forcegldefaults, as the name suggests, locks several settings (both in menu and non-menu). One of the settings that is locked by this is the light mode and given, as you already know, the default at the time is "dark" that's what it forces (unless the mapinfo specifies otherwise). So I'm saying I'm not sure why you think the Zandronum developers would be champions for user light mode choice when they already give server operators the option to disable that choice. In fact, given that this was done before the software emulation shader was added, adopting GZDoom's new restricted light mode setting would probably allow people to use the software emulation even in competitive games. After all the software renderer is allowed so there's no real reason to block that mode, so it would just be gl_maplightmode that needs to be blocked. I guess you never noticed since the current behavior happens to be what you prefer. But I assure you the behavior is "force defaults" and not a meticulously reasoned out choice for all the settings involved. That particular chain of discussion was about Zandronum.

gl_lightmode is covered by sv_forcegldefaults so they actually don't care that much about the user having the choice to customize this as in competitive play it can be considered a cheat. I'm not familiar with the QZandronum folks so can't remotely comment on that. Anyhow I think we're getting to the point where we're asking the same questions since you reject the explanation, so there's not much left to add.

Oh this was a recentish change? Somehow I never noticed so I assumed it was a way back ZDoom change once it was pointed out. I can't say I agree with the logic to retain it just to prove a point. Seems like needless confusion for marginal/debatable benefit.

Honestly wish I knew the exact reason the lighting was changed in ZDoom. Given what the difference between vanilla and software is I assume it was done to make slopes more seamless, but this was all done well before I was involved with ZDoom. In any case as things stand right now whether software or vanilla is more accurate depends and I was not involved with any discussions to know if anything was considered to try to rectify that problem. Either way as long as it is the case that it is desirable to have a non-software shader option for performance, the selection between those two modes is a separate thing (would require a different mapinfo option at least).

Don't forget that you can make console aliases and fancy key binds. If they care enough they will seek out the information that's available. The expectation is that most will just get used to the more accurate mode and over time the number of people even aware of the old modes will diminish. Gee I wonder why a port that hasn't had a major release in years still has the option from the version it's based on still available. I would think it's very likely Zandronum will inherit the change if they ever have the man power to rebase. It's going to be hard to find every instance that we've had to enumerate all the options and explain why they exist/when they should be used, and I certainly have more important things to do with my time. However with some quick searching here's some examples of times where its been indicated that the intentions with the light modes is unclear to some extent. https://forum.zdoom.org/viewtopic.php?t=57613 (What's the difference between Doom and Software?) https://www.doomworld.com/forum/topic/98210-gzdoom-lighting-levels/ (What are all the lighting modes? I noticed the one I was using wasn't accurate.) https://steamcommunity.com/app/2280/discussions/0/1762481957316112742 (Which mode is most correct?) https://forum.drdteam.org/viewtopic.php?t=4242 (What is the intended effect of the light modes?) Maybe also worth noting that the poll you link also has a discussion on how to make the light mode names better. And another more recent poll has it in 5th place:

This thread is on the ZDoom forums and it was recently bumped by NeoWorm as well. It likewise a pretty short thread suggesting not many people there care either. https://forum.zdoom.org/viewtopic.php?t=78326 However if you search the Internet at large you won't find anything. On the other hand I know over the years we've had to explain the purpose of the light modes multiple times, so it's not imaginary that the purpose of the setting is non-obvious which leads to people setting the wrong thing. Now one might want an explanation on how something being non-obvious can be known to lead to people setting the wrong thing. For example, in the Steam version of Super 3D Noah's Ark I had to restrict the screen size option to remove the ability to remove the status bar in the options menu. What I observed is while a lot of people never open the options menu, there's also the set of people that do go through them and they'll see something like "screen size" and think "well surely I want the biggest setting" adjust it and then wonder why the status bar is missing. I capped it in the menu and no more complaints, but if one really wants to run the game without a status bar they can by knowing the button to press in game. Lets focus on this because I truly can not follow your argument here. So based on what you said you'd be OK if we tucked it 10 menus deep and required you to jump through a hoop to enable said menu. But it being accessible by console only is too far? What is it that's so important about it being in the menu to you? The menu is supposed to be for options that casuals are expected to change. You'll probably be tempted to answer with a what-about-ism, but as I've addressed earlier in this thread the argument that this is a drop in the bucket UX improvement is basically just arguing "no progress should be made since you didn't solve every problem at the same time." Also with NeoWorm's arguments against autoexec being dispelled, given that you said: "either force it via mapinfo or i will play it with dark. because thats what i like." I fail to see why you are not happy with the autoexec solution. Since it sounds like you can have exactly what you want today, you just refuse to edit a file for some reason to get your unpopular option. A setting being unpopular is definitely a reason to consider its removal. My desktop environment of choice, KDE, runs into this problem with some frequency. They were known as being infinitely configurable but routinely they get feedback that the options are confusing, hard to locate, and even cause stability problems due to too many possible code paths. There have been efforts to choose better defaults and remove unpopular options, and similarly met with a lot of hot air with similar "I thought KDE was about choice" arguments from the handful of people who are affected by the changes. To be clear I'm not arguing the light modes cause stability issues in GZDoom, I'm merely pointing out that being unpopular is indeed an important metric and GZDoom isn't alone in doing this. If it hasn't been so already, this actually isn't a terrible idea to pitch to the active GZDoom devs. I'm not sure it presents a meaningful improvement to the status quo, but I would say there's some substance here. Similarly for Xaser's suggestion of auto-compat entries. Although the idea of auto-compat doing cosmetic changes pains me (mostly since the bloat of the auto-compat definitions leads people to point at it as some evidence that GZDoom's backwards compat is terrible despite a lot of it being not strictly necessary), it's not like GZDoom doesn't already have a bunch of those so it's not a new concept.

I would consider the ephemeral nature a feature since if I come across an old mod that needs a certain light mode I can set it temporarily without having to remember to reset it to software for the next mod. As I suggested in my last post I'd set it via the command line along with the mod files so it would effectively persist across play sessions of that mod (in my case in my bash history, but could easily be a short cut or launcher profile etc). I strongly believe all the tools needed are there and this is just an xkcd 1172 moment. I did look in more places than Doomworld. While there happens to be three in this thread, I'm not convinced from what I've seen elsewhere that the number is that much higher to change the point.

I'm pretty sure there's around three of you that consider this option "essential." Most of the people that made complaints were complaining about not being able to use it as a hack to increase brightness (and are more or less satisfied with the autoexec option because they aren't changing between modes for any reason). At the very least searching the forums don't turn up anyone complaining since a few weeks after 4.11 was released except for the recent bumps. For you power users that play with the light modes there are many tools as your disposal to continue to play with them (make separate GZDoom short cuts for each light mode for example). They may not be quite the same workflow as before, but for everyone else by encouraging the use of the mapinfo field the experience is meaningfully improved for everyone else in the long run.

While it's definitely true that it depends on the scene (hence why I assumed it would be a wash originally), I would argue that Rum & Raisins data suggests that the column major frame buffer wins more than it loses even with the flats still being rendered row major. Of course that data was for one demo, so really to draw a conclusion it would probably make sense to run a large number of demos. I believe I heard a couple of ports did switch to a column major buffer after that, so not sure if anyone has collected more data. Either way though for FastDoom or similar DOS ports it's still irrelevant since as I said those are limited by the layout of the hardware frame buffer (at least when talking about standard 320x200@8bpp modes).