3 console commands that should be available from the menu

[Coon]

vid_vsync (already in GZDoom), cl_maxdecals (should switch to 0 and back to it's previous number) and r_smoothlighting.

Thanks.

[Xaser]

I wouldn't mind seeing "dimcolor" and "dimamount" there too. I never realized they existed until a few days ago during a chance discussion.

[Enjay]

I can see an argument for vid_vsync but the others strike me as things that should not be in the menu.

[Coon]

The default cl_maxdecals number can have a performance hit in older computers, not to mention ZDoom decals are ugly as hell, thus I believe it should be more accessible for both performance and cosmetic reasons.

r_smoothlighting can greatly improve the visuals depending on the area, something seldom ever seen in software renders.

If we have sprite and particle effects for rocket trails, puffs and blood already in, why not these?

[Enjay]

I'm not convinced that those other ones you mention should have a place in the menu either.

Seriously though, most of the ones you mentioned are the kind of things the people set once (or rarely) and leave. As such, I can't see a strong argument for them being in the menu. This is compounded by a number of additional considerations:

1) The menus are already quite crowded and (IMO) adding more to them would be counter productive.
2) If you add these, where do you stop? I'm sure that equally strong arguments could be made for the inclusion of many of the console options - but there are dozens of them.
3) The menu code is, apparently, quite untidy and Graf at least has expressed reluctance to do too much with it. Other people have looked at it and agreed.

[Gez]

Hell, I'd motion removing "direct draw palette hack" and "use attached surface" from the [wiki]display options[/wiki] menu. I mean, one is considered "hopefully obsolete" since 2004, and the other is ignored unless you run Windows NT 4.

[Coon]

1) The menus are already quite crowded and (IMO) adding more to them would be counter productive

I say the more the merrier, it's a bit like the reverse of Vavoom's motto (hide everything useful and expect people to waste time searching the documentation for stuff you normally get to modify in a couple of seconds when using ports with full-featured menus) I don't think that integrating these would be counterproductive in any way. ZDoom is not going to run any slower and quite certainly it will not make the menu "crowded" as in "where did the other options go?" Correct me if I'm wrong.

2) If you add these, where do you stop? I'm sure that equally strong arguments could be made for the inclusion of many of the console options - but there are dozens of them

You stop right here, and I don't think equally strong arguments could be made for other commands.

3) The menu code is, apparently, quite untidy and Graf at least has expressed reluctance to do too much with it. Other people have looked at it and agreed.

Maybe it's time for a clean-up?

[Enjay]

You stop right here, and I don't think equally strong arguments could be made for other commands.

I dunno. I just had a look through the cvarlist and spotted a few that I use quite a bit and which are either not on the menu or difficult enough to spot in the menu that I have developed the habit of using them from the console.

Maybe it's time for a clean-up?

Could be.

@Gez, those two you mention have already gone from my own private messing-around build,

[Graf Zahl]

Not every CVAR can go into the menu. VSync, yes, that should be added but the others not - especially those which need additional coding lile cl_maxdecals.

[randi]

The default cl_maxdecals number can have a performance hit in older computers

When I wrote the decal code, 1+ GHz machines were becoming common, but mine was still a 350 MHz Pentium II that did not meet even the minimum specs for newly-released games. I found the performance to be quite satisfactory so long as you didn't repeatedly blast rockets at the same spot on a wall. Knowing that it ran well for me on outdated hardware, I had no issue with selecting the default value I chose.

[Rachael]

The only instance where I can see decals causing such a huge problem on slower computers is where you're running an extremely high resolution that said computer shouldn't be running anyway.

The lower the resolution, the less of an impact decals should have on your computer, as with any other transparent rendering.

[Coon]

I found the performance to be quite satisfactory so long as you didn't repeatedly blast rockets at the same spot on a wall

Which happens quite often and even my 3ghz suffers, plus facing one of these spots at very close range literally gives you 0 fps.

Decals in software mode look like hell and slow things down, but your port, your business.

[Rachael]

Well, Mr. whatever-the-fuck I should call you (not by your registered name, mind you), you're the one in ten million that nobody notices, because you're the one exception to the rule. And besides, you already know how to disable decals - it isn't rocket science, you've got it well in hand. Case closed.

[Coon]

you already know how to disable decals

That's beyond the purpose of my original post. I believe this option is significant enough visually and performance-wise hence should be integrated into the menu out of mere convenience.

[HotWax]

You're welcome to code it into your own private build of ZDoom. Graf already said he's not putting it in ZDoom, and randee doesn't seem to keen on it either, so you're wasting time arguing the matter here.