Source Ports personal deal breakers (Jan 9, 2024)

I think I tried Cherry a while ago but completely forgot about it, looks like he’s actually using it as a tester for new Nugget features which is awesome. So many cool ports and “stuff”, Doom is truly eternal.

2 hours ago, CacoKnight said:

I think I tried Cherry a while ago but completely forgot about it, looks like he’s actually using it as a tester for new Nugget features which is awesome.

I'm not using it as a "tester", actually. It did give me some ideas (last weapon key, explosion shake, customizable darkening effects) and somewhat "pushed" me to implement the Tag Finder, but some other of its features happen to be ones that were requested to me at some point or another. In any case, I have taken no code from Cherry at all, and I don't partake in its development apart from the obvious fact that I'm the developer of its parent port.

Just now, Alaux said:

I'm not using it as a "tester", actually. It did give me some ideas (last weapon key, explosion shake, customizable darkening effects) and somewhat "pushed" me to implement the Tag Finder, but some other of its features happen to be ones that were requested to me at some point or another. In any case, I have taken no code from Cherry at all, and I don't partake in its development apart from the obvious fact that I'm the developer of its parent port.

That's more what I meant yeah, for ideas, to see what people like and ask etc.

I fully agree with OP. I just want my 1080p res in Crispy\Woof\Interdoom source ports. Its 2023 and ppl use big\4K monitors. With all due respect for purists.

5 minutes ago, Zaratul said:

Interdoom

This one does already (So Doom as well, that's why I keep those two' settings backed up)! Also wish I could test Nugget's 1600p on a 4k monitor but mine only goes up to 1440p :)

Jokes apart, I think 800p is a damn great sweet spot for any modern monitor.

Thats not true, Interdoom supports quad res=1280x800. Its not having 1080p.

9 minutes ago, Zaratul said:

Thats not true, Interdoom supports quad res=1280x800. Its not having 1080p.

Ohh my bad, I thought you meant quad/800p in fact. I don't think 800p to 1080p would change much because of how the resolution and pixels work in Doom? I think you have to double 200/400/800/1600 to see a real difference? Someone more expert will reply I'm sure.

20 minutes ago, CacoKnight said:

I don't think 800p to 1080p would change much because of how the resolution and pixels work in Doom? I think you have to double 200/400/800/1600 to see a real difference?

If you think that's why we only offer 200p, 400p and so on, I think that's not the case. I think it's done like that because it's easier to implement: for stuff like the HUD, each pixel in 200p becomes 4 pixels in 400p, 16 pixels in 800p and so on, whereas if we had other arbitrary resolutions (including 1080p) the scaling wouldn't be as trivial.

In short, supporting resolutions like PrBoom+ and its derivatives do isn't as easy.

5 minutes ago, Alaux said:

I think it's done like that because it's easier to implement

This too, agree 100%, you just double it and that's it and in addition you see some real difference of course. Sorry English is my 3rd language, sometimes I just try to add all I think in one sentence.

Talking about resolution, colors, etc, why the hell is DSDA so different from vanilla? If you see in the three pics here (Chocolate, DSDA and Nugget), Nugget is 100% accurate with Chocolate but DSDA has different colors, gamma, sprites, even the walls are different and the objects look like they are floating.

This may be a little off topic but is there an easy fix for DSDA for all this?

Maybe I'll just keep GZDoom and Nugget and that's it, I don't care about demos and speedruns anyway.

7 minutes ago, CacoKnight said:

Talking about resolution, colors, etc, why the hell DSDA is so different from vanilla? If you see in the three pics here (Chocolate, DSDA and Nugget), Nugget is 100% accurate with Chocolate but DSDA has different colors, gamma, sprites, even the walls are different and the objects look like they are floating.

 

This may be a little off topic but is there an easy fix for DSDA for all this?

Judging by things like "floating objects", are you using OpenGL renderer in DSDA? It's a recreation of the classic Software renderer but it's not 100% accurate.

On 11/4/2023 at 5:39 PM, tomas7777 said:

Judging by things like "floating objects", are you using OpenGL renderer in DSDA? It's a recreation of the classic Software renderer but it's not 100% accurate.

I do yeah, I think I tried Software renderer a few times but it was too slow, checking again now. Thank you.

edit:

Yep, it was that. Software at 2560x1440 res is too sluggish but if I change it to 1920x1080 it works much better, I still have to test if it's as fast as Nugget.

edit2:

I think at 1600x900 it's just as fast as Nugget, nothing visual changes and it's still 16:9.

edit3:

Changed all my ports to default 1600x900. I can even play NUTS almost as fast as Nugget with GZDoom at that res.

20 hours ago, 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.

 

Lol, you are the last person who gets to cite "what people want" as a rationale for justifying port features.

21 hours ago, Shepardus said:

dsda-doom, Woof, and prboomX support a COMPLVL lump that specifies vanilla/boom/mbf/mbf21 complevel if none is specified through the command line. The -complevel parameter takes precedence over it so players can still force a particular complevel if they wish.

I think this functionality is the ideal and doesn’t really conflict with @Graf Zahl‘s concerns. Of course people should be able to play the way they want, but I also think mappers should be able to make their preferred configuration easily playable.

Quite interesting topic, have to admit. I'll add my two cents not from player's, but from technician/programmer's POV:

• "Quad" or "any" resolution: neat feature to have, but trust me, despite of giving nice view, it's... Voracious in the meaning of CPU resource usage. Technically, it is absolutely same to mid-res (2x), except with higher resolution multiplier and larger screen buffers for player view and status bar background. We have suffered absolutely same performance issue between Inter-Doom and friendly Nugget Doom port, and the best we can do in this case is to explain: "If your CPU handle this mode well, please use it. If not, please consider using middle resolution", and as @Alaux said before, support any possible resolutions, especially without performance penalties is not that easy. The cause of the problem lies not in mid/quad res code, it is in slightly different plane: we still have a single-thread process, which is using GPU just to scale picture and put it to the screen. Switching to hardware accelerated render could resolve performance issue entirely, but this is not that easy as well.
• Demo support. Demos are friends, not foes. While demos are fun to watch and record, they also helping a lot with automated tests. Funny enough, but the longer demo is, the more helpful it is for testing (notable example is six hours demo of Alien Vendetta by blue cultist). Another useful thing is "-timedemo" which is helping for performance benchmarking and engine stress-testing. Needles to say that demo support require untouched game mechanics, so...
• Game mechanics. As we are all know, there are a lot of small oversights in vanilla Doom, and nearly all of them are documented in DoomWiki. Fixing memory/visual/render oversights is okay, but touching anything related to play state is a direct way to possible demo desync. Yes, it is possible to guard such fixes with conditions like "not while demo recording, not while demo playing, not while multiplayer", but this will lead to another confusion: what if player expects to meet this bug in casual single player game? But uh-oh, it's unconditionally fixed. Having a dozens unclear micro-switches for any possible fix doesn't sound like a good idea at all.
• Boom/MBF/MBF21 support. A lot of modern projects using this specs, which are offering amazing things for gameplay, and it's really great. But porting this specs into engine from scratch is a huge challenge, which will require a lot of attention and patience, because even pure Boom is not just a couple of extra line specs, it is also changes in render code, support for custom COLORMAPs and so on.
• Command prompt hell. On Windows OS especially. Probably, this problem can't be solved entirely, but most of today's source ports are allowing to drag-n-drop files onto the executable.
• Programmer's coding experience. Especially if programming is time-to-time a hobby. That's the real problem of everything, speaking for myself. 

Oh boy, This will be fun! I swear we've had this thread before.

There are many technical but stupid things that are/were/should be/should have been deal breakers for me when it comes to source ports (not just Doom ones!) so, uh, here we go, the ones that ticked me off enough:

Dropping 32-bit support: One popular source port (which I don't have to name because you and I both know which one it is) has done this, and I've re-written parts of said source port to get it running on 32-bit hardware, with little issue other than some routines breaking now and then, which I also track down and fix. I don't mean "not supplying 32-bit binaries to download", for that would stop 100% of the idiots on ancient machines wondering why they can't run Brutal Doom, but going as far to actively code in checks for word lengths and halt compiles, or any other related arch checks - what purpose does that serve? Is there someone out there who can set up a build environment for a source port and the required libraries for it but can't understand VM memory access violations on a toaster? At the risk of being hyperbolic for comedic effect - I shouldn't need a quantum computer from space to run MAP01 of Doom 2, and neither should you, but don't force me to make a fork out of spite, just let me "do the thing", and I'll deal with the problems.

Requiring specific hardware acceleration: This is mostly an SDL2 port thing - not only does this make no sense for a source port that still runs the "software renderer", it also breaks the source port when running on new or niche hardware that can take advantage of the "surface" fallback SDL2 offers, and accelerate it. Eternity Engine still has a "vanilla" SDL surface fallback, which is so much faster on machines like the Raspberry Pi which substitutes its own accelerated routines, compared to the OpenGL routines, likely made for x86 PCs specifically.

DISCLAIMER: Yes, I know some source ports might let you do crazy things with the screen elements and rotate the viewport and add plastic wrap but requiring users to be able to render that stuff because a mod might use it, is going beyond the scope of a "Doom Source Port" and into a different territory entirely. No one is seriously going to think worse of you if you can't provide 100% accurate experiences across all rendering modes.

Requiring specific esoteric processor extensions: Don't. Also, Don't inline ASM anymore it's awful compilers still do NOT know how to handle it and you WILL cause more problems than you solve, write the code correctly the first time and let the compiler do the work AAAAGH

Raising lower limits of options: I guess we ain't playing Doom properly if we can't mix 64 sounds simultaneously? Thankfully I can change the code and reduce the minimum to a saner 8, but 64 is a seriously HIGH minimum as is, why even let us set it in the first place? Who's mixing 128 sounds?

Hijacking environment variables: Don't. You don't know what you're running on, don't assume you know. Even if you think you know what you're running on, you really don't. 

Adding Complex Features With No Options: I appreciate that ports are adding cool things like Fluidsynth, but please give us a way to control these features on a more granular level. Some ports don't even let you set Fluidsynth polyphony in its config files, which should be really easy to add. GZDoom is a great example of doing this part right. Everything can be tweaked in game menus, even if you would never need to!

Unoptimized, Unmaintained Fallbacks: I love speed too, but make sure your fallbacks work. If you wouldn't play with your fallback, that's not a good position to be. Not asking for 9000fps on a sunder map, just something acceptable. Or just use a JIT solution that doesn't suck that could work I guess.

Code that straight up breaks on anything that isn't a certain release of msvc: Thankfully this isn't a problem... any more. But it's here for completeness.

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?

Removing Y movement on the mouse: Am I the only one left who uses the mouse to move as well as turn? This has kept me from enjoying FastDoom and I really want to use that port but the mouse drives me crazy!

Source Port Author Calls the community multiple slurs: Actually, this is the only true deal breaker in this list. Sorry you read this far.

As someone certainly guilty of calling the community slurs when I rage, I think it is only fair that if they can slur at me that I can then also slur back. :)

I think a lot of the things listed (except the deliberate sabotage of 32-bit builds) are really just about source ports not meant for your type of hardware. Every source port author is ultimately only doing this as a hobby and therefore it should be fun for them to do. For me, targeting the raspberry pi is the opposite of fun. I know this thread is personal deal breakers, but your way of wording it makes it sound like you think its the source ports authors fault/responsibility to support your use case. It really isn't.

Back on topic: My personal deal breaker for a source port is when it expects me to edit config files in order to set it up. This is in particular important when it comes to making it work on my monitors. Ultra widescreen, 4K or even 8K - all that kind of stuff. This doesn't mean a source port must support a higher resolution, but if I can't get it properly letterboxed and upscaled to my monitor without stretching then I can't really use it.

Not deal breakers per se (as plenty of source ports I use tend to lack in one or more of these areas), but definitely things that would make me less likely to try out a port are the following:

• Lack of high resolution options. I use a 1080p monitor and I like to see full use of it.
• Lack of hardware accelerated renderer. Mainly for the performance reasons.
• Lack of Demo compatibility.
• Can't turn off mouse acceleration.
• Lack of uncapped framerate option. Unless the source port is Chocolate Doom, I expect this to be there in a modern day source port.
• Lack of in-game config options. I recall trying out Doom Retro a couple of years ago and I was turned off from it because I had to go edit the config files for whenever I wanted to change certain settings. Maybe this is not the case anymore, as I haven't tried the port since then.
• Lack of Boom/MBF/MBF21 support.

15 hours ago, Csonicgo said:

Dropping 32-bit support: One popular source port (which I don't have to name because you and I both know which one it is) has done this, and I've re-written parts of said source port to get it running on 32-bit hardware, with little issue other than some routines breaking now and then, which I also track down and fix. I don't mean "not supplying 32-bit binaries to download", for that would stop 100% of the idiots on ancient machines wondering why they can't run Brutal Doom, but going as far to actively code in checks for word lengths and halt compiles, or any other related arch checks - what purpose does that serve? Is there someone out there who can set up a build environment for a source port and the required libraries for it but can't understand VM memory access violations on a toaster? At the risk of being hyperbolic for comedic effect - I shouldn't need a quantum computer from space to run MAP01 of Doom 2, and neither should you, but don't force me to make a fork out of spite, just let me "do the thing", and I'll deal with the problems.

This is no different than dropping Windows 95, Windows XP or whatever else gets old. The old stuff causes work, as you yourself admitted (see the underlined part) and at some point that work yields no benefit anymore to warrant the investment

If other developers are willing to invest the work that is fine but since 32 bit already requires disabling both the JIT and Vulkan and the user base is tiny already and further shrinking, it doesn't make sense for a port like GZDoom.

15 hours ago, Csonicgo said:

Raising lower limits of options: I guess we ain't playing Doom properly if we can't mix 64 sounds simultaneously? Thankfully I can change the code and reduce the minimum to a saner 8, but 64 is a seriously HIGH minimum as is, why even let us set it in the first place? Who's mixing 128 sounds?

Actually, modern mods need that many channels if they contain ambient sounds and the lower limit is set this high so that a certain kind of user cannot reduce it to values low enough that the sound does not play correctly anymore. It seems you have no idea how high the number of simultaneously playing sounds can get in an active environment.

15 hours ago, 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 actually pre-dates ZDoom - the first source port to add vertical spread to all hitscan weapons was none other than DOSDoom , which I don't think even gives you an option to restore the original behaviour at all.

Did I mention ports which enable texture filtering by default?

My requirement is going to be very different from what's been brought up already --

* Robust command line control

I'm making PortaDOOM, a bundled collection of WADs and launcher and I can tell you that wrangling many different engines to behave the same way as regards config files, where save files go, where files are read from and setting WAD compatibility is tough work that I've spent hundreds of hours on.

Not only did I write a 2'000+ line batch file to achieve this -- since converted into a launcher with UI -- I've had to produce other bits of tooling to wrest control of different engines, such as being able to set the same, equivalent, settings across multiple engine's config files (another 800-line batch file).

GZDoom is both excellent, in its support of almost total control of the engine through the command line (being able to auto-quit via `+quit`is fantastic for automating config file changes), and also a terrible pain in that it is neither backwards nor forwards compatible with itself. Some mods only work on some ranges of versions. I have over 30 versions of GZDoom on disk and my build system uses meta-data I've provided for each WAD to bundle just the versions of GZDoom that are required.

So for me, if an engine doesn't allow me to load a config file from an arbitrary location, set a directory for saves (or force same by setting the CWD) and control basic properties of loading WADs (complevel) then it's just not an option. The closer the an engine follows the same general behaviour of other ports, the better.

Nice man, I checked PortaDOOM a few times, nice stuff thanks for your hard work!

1 hour ago, Graf Zahl said:

Actually, modern mods need that many channels if they contain ambient sounds and the lower limit is set this high so that a certain kind of user cannot reduce it to values low enough that the sound does not play correctly anymore. It seems you have no idea how high the number of simultaneously playing sounds can get in an active environment.

wouldn't that "certain kind of user" (i.e. csg and maybe two other people) likely not play mods that are that intensive in the first place? i feel like if they're gonna reduce the values to be low enough to cause that, then surely they'd be aware that, gee, maybe if you play things that wouldn't run on a 486 with settings designed to run on a 486, then they won't work properly

49 minutes ago, Scuba Steve said:

Did I mention ports which enable texture filtering by default?

yeah, get em steve! FUCK EM UP!!!

3 minutes ago, CacoKnight said:

Nice man, I checked PortaDOOM a few times, nice stuff thanks for your hard work!

Oh, thanks! Feedback has always been incredibly rare! A major update is coming before the Cacowards; an all new PSX/DOOM64 package courtesy of DOOM CE and the Cacowards 2019 package is ready. I don’t know if any newer ones will be ready by then, they take a couple of weeks to put together, but the entire launcher has been massively improved to make running the WADs a zero-effort affair

8 minutes ago, roadworx said:

wouldn't that "certain kind of user" (i.e. csg and maybe two other people) likely not play mods that are that intensive in the first place? i feel like if they're gonna reduce the values to be low enough to cause that, then surely they'd be aware that, gee, maybe if you play things that wouldn't run on a 486 with settings designed to run on a 486, then they won't work properly

There's really no point to it. The sound channels are not persistent resources but merely the maximun number the engine will allocate. So playing 16 sounds with a 16 channel limit will have the same CPU load as 16 sounds with a 64 channel limit. And since the sound system's inner workings are sufficiently different from the original, even setting it to 8 won't help making it sound like the original. If he's this resource constrained that lowering this affects performance he genuinely needs a different sound backend.

If he wants to run GZDoom on a system below supported specs it's in his turf, but the sound mixer has no issues with 128 sound channels on any hardware that's officially supported (i.e. every multi-core desktop or laptop system from the last 10 years or so.)

I find that Woof and GzDoom work extremely well for me. One of the things I REALLY want out of sourceports now is gamepad support, so I can run a gamepad and a mouse at the same time, which my ports of choice allow me to do.

I also really like stuff such as brightmaps (or fake brightmaps), ENDOOM support, and the ability to use the improved blockmap. Though as what a lot the playing I'm doing these days is testing for complevel 21, I can't use that and have to make sure my shit works properly without it. Some day I hope there'll be a complevel which has the improved blockmap, and maybe even skipping the whole infinite height thing.

I find the only major quibbles I have is how UMAPINFO is not 100% consistent between ports, and how a few very straightforward features that you'd see in regular MAPINFO aren't present (like the ability to toggle the Map 30 telefrag special on or off).

I can work around a lot of this, but I hope these things get developed a little bit further some day.

12 minutes ago, Graf Zahl said:

 

 

There's really no point to it. The sound channels are not persistent resources but merely the maximun number the engine will allocate. So playing 16 sounds with a 16 channel limit will have the same CPU load as 16 sounds with a 64 channel limit. And since the sound system's inner workings are sufficiently different from the original, even setting it to 8 won't help making it sound like the original. If he's this resource constrained that lowering this affects performance he genuinely needs a different sound backend.

 

If he wants to run GZDoom on a system below supported specs it's in his turf, but the sound mixer has no issues with 128 sound channels on any hardware that's officially supported (i.e. every multi-core desktop or laptop system from the last 10 years or so.)

 

i think (keyword here being think) it's not about performance, it's about maintaining nostalgia more than anything. yeah, i'm sure it still won't sound the same because gzdoom isn't the doom engine and yada yada yada, but i don't really see the point in setting a hard limit like 64. if people, as bizarre as their rationale may be, want to lower it, then why stop them?

i'm of the belief that if people want to go out of their way to fuck their experience up, then let them. imo it wouldn't hurt to make it so that you can only go down to current limits in the options menu, but editing the config file itself can let you lower it further. that's more work, sure, but you could always let some weirdo like csg modify it to be like that

17 hours ago, Csonicgo said:

I guess we ain't playing Doom properly if we can't mix 64 sounds simultaneously? Thankfully I can change the code and reduce the minimum to a saner 8, but 64 is a seriously HIGH minimum as is, why even let us set it in the first place? Who's mixing 128 sounds? 

Things can add up a lot depending on what kind of mods you're playing and on what map, and there's a massive variety of mods out there which do different things. Unless there is some sort of problem with having 64 sound channels available, I fail to see the complaint.

1 hour ago, Graf Zahl said:

Actually, modern mods need that many channels if they contain ambient sounds and the lower limit is set this high so that a certain kind of user cannot reduce it to values low enough that the sound does not play correctly anymore. It seems you have no idea how high the number of simultaneously playing sounds can get in an active environment.

Agree, in a very busy scene there can be lots of sounds going on at once.

For something I've been working on for a few years on and off, I can have the following sound effects going on during a battle in a short amount of time:

• Player's gun, either shots or the sound of reloading or manual cycling.
• Enemy weapons, including guns, and how zombies need to reload them.
• The player's automated sentry, with its alerts and its gunfire.
• Spent casings, or ejected clips and magazines, both from the player and zombies with guns.
• Bullet impacts.
• Hand grenades, thus pulling of pins, the arming lever flying off, and then the throw or drop, with the noise of the grenade bouncing on the floor and walls, before finally detonating.
• Explosions from grenades, barrels (which can be an entire series), boss monsters, as well as the ground quaking from them, and the specific sound of explosions heard from a long distance away.
• General enemy noise, like normal for Doom, but also added voice lines for some zombies, noise of spraying blood and gibs, heavy footstep sounds for medium large enemies like Barons and Mancubodes.
• Special sound effects of monsters being crushed by crushers (which creates blood and gibs), also big boss monsters having fancy added gib effects and explosions.
• Potential ambient sounds from torches, and other props.
• Specific sound effects for any and all pickups.
• All the regular sounds in a Doom level, lifts, doors, crushers, teleporters, etc.

I'm easily exceeding 32 sound channels in a busy battle scene. This may all sound like a lot, and occasionally it can be, but it's rarely all playing out at the exact same second, or in the immediate proximity. Some sounds can be far away, but still important to hear, for instance the zombie shooting at you with a rifle from 1200 map units away, if the player couldn't hear that to react to it and determine the direction, that would be cheap.

I aim for a vast soundscape where I want a lot of things to sound very distinct, and paying attention gives you cues to what's going on without having to necessarily see it. To this end I want all the monsters to have a distinct sound set, so that you can always identify what monster you're hearing purely by their attack sound, idle sound, or pain sound (maybe even the steps of some).

I want a lot of sound channels for what I'm doing with this mod, this isn't one of my Boom/MBF21 things.

1 hour ago, Scuba Steve said:

Did I mention ports which enable texture filtering by default?

I genuinely think the linear texture filtering is ugly to look at, but since I can navigate an options menu, or just plain copy over my config file from the previous version of GzDoom, I never have to look at it.

Meanwhile, as much as I love Woof, it sometimes forcibly resets my choice of midi player for no apparent reason, which GzDoom has never done to me.

19 minutes ago, roadworx said:

i think (keyword here being think) it's not about performance, it's about maintaining nostalgia more than anything. yeah, i'm sure it still won't sound the same because gzdoom isn't the doom engine and yada yada yada, but i don't really see the point in setting a hard limit like 64. if people, as bizarre as their rationale may be, want to lower it, then why stop them?

 

i'm of the belief that if people want to go out of their way to fuck their experience up, then let them. imo it wouldn't hurt to make it so that you can only go down to current limits in the options menu, but editing the config file itself can let you lower it further. that's more work, sure, but you could always let some weirdo like csg modify it to be like that

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.