Brainstorming a GZDoom menu revamp
- Zenon
- Posts: 531
- Joined: Thu Apr 20, 2006 6:05 pm
- Graphics Processor: nVidia with Vulkan support
- Location: New Zealand
Re: Brainstorming a GZDoom menu revamp
I appreciate and am thankful for the encouragement and the offer of assistance, really I am.
But I wasn't gifted with the enthusiasm of wanting to learn any sort of coding, programming or any of that sort of thing.
Heck, the same can be said about me learning anything at all, it seems.
I'm just a suggestion guy who has no abilities of any sort to bring to the table
My apologies
I'm such a mess
But I wasn't gifted with the enthusiasm of wanting to learn any sort of coding, programming or any of that sort of thing.
Heck, the same can be said about me learning anything at all, it seems.
I'm just a suggestion guy who has no abilities of any sort to bring to the table
My apologies
I'm such a mess
Re: Brainstorming a GZDoom menu revamp
This isn't about not being able to contribute at all. We do want constructive feedback here.Zenon wrote:I appreciate and am thankful for the encouragement and the offer of assistance, really I am.
But I wasn't gifted with the enthusiasm of wanting to learn any sort of coding, programming or any of that sort of thing.
Heck, the same can be said about me learning anything at all, it seems.
I'm just a suggestion guy who has no abilities of any sort to bring to the table
My apologies
I'm such a mess
But the fact of the matter is that eventually some decision has to be made - for something like texture filtering there is no clear consensus - some like it on and some like it off. I'm personally firmly in the camp that likes it off, using None (Trilinear) myself. Still, by the end of the day when I read Graf likes it as it is that more or less settled it. The default will be filtering on.
Yes, it sucks for those that would prefer it to be off, but let's not overstate the problem: it is changed in less than 10 seconds. Keep in mind that if someone else than Graf would be in charge then the default settings would be different, but other people would be unhappy instead. For example, I would have enabled bloom and dynamic lights. Maybe even have increased the default gamma value. The only way you can have GZDoom default to working exactly 100% like you desire is to do your own fork. I believe that was Rachael's primary point there.
- gwHero
- Posts: 360
- Joined: Mon May 08, 2017 3:23 am
- Graphics Processor: Intel with Vulkan/Metal Support
- Location: The Netherlands
Re: Brainstorming a GZDoom menu revamp
I think the menu system as it is now is not that bad: a real bad menu is a menu that changes every new release, like for instance is the case with Microsoft Office. At least (G)ZDoom has been pretty consistent in the menu's over the years, and that's good.
But I agree that some parts could be improved. For instance I've always found the split up between Video & Display a bit awkward. But it's the same as with key bindings: let 10 people make a proposal and you'll probably end up with 10 different schemes. Overall I think I most agree with Xaser's proposal.
But I agree that some parts could be improved. For instance I've always found the split up between Video & Display a bit awkward. But it's the same as with key bindings: let 10 people make a proposal and you'll probably end up with 10 different schemes. Overall I think I most agree with Xaser's proposal.
- GFD
- Posts: 347
- Joined: Mon May 31, 2010 7:42 pm
- Preferred Pronouns: He/Him
- Location: Canada
- Contact:
Re: Brainstorming a GZDoom menu revamp
I'll need a few days to finalize details of how I personally would overhaul the menu designs, but here are some of the important, broad concepts.
Showing all available settings at once would go a long way towards usability. While left and right can still be used for immediately switching between settings, left-click and enter should open a vertical (and scrollable, if really necessary) list of available settings. Here's an example from DOOM 2016, but obviously the layout in GZDoom wouldn't be exactly like this, as we don't have as much (or sometimes any) space to the right of the menu to work with. This example also has an unnecessary scrollbar—that fifth setting could easily fit on the screen with all the others.
[imgur]https://i.imgur.com/JuuzKv6[/imgur]
Help pages are a necessity. While the wiki's CVAR/CCMD descriptions are useful, they're not accessible in-engine at all, and use more technical language. Every CVAR/CCMD needs to have some accompanying help text written, which would then be accessible through both a "help <CVAR|CCMD>" CCMD, and any menu item attached to that CVAR/CCMD. In menus, the help page would functionally be a submenu that's just a bunch of scrollable text. An unfortunate consequence of this, however, is that we're creating a whole lot more work for translators.
A search function would be incredibly useful. This was the best thing to happen to the settings page in Android, and it would probably go a long way in GZDoom too. It would search the menu item strings, value strings, and maybe also the associated help page texts. Of course, coding this would be a whole bunch of work too.
Showing all available settings at once would go a long way towards usability. While left and right can still be used for immediately switching between settings, left-click and enter should open a vertical (and scrollable, if really necessary) list of available settings. Here's an example from DOOM 2016, but obviously the layout in GZDoom wouldn't be exactly like this, as we don't have as much (or sometimes any) space to the right of the menu to work with. This example also has an unnecessary scrollbar—that fifth setting could easily fit on the screen with all the others.
[imgur]https://i.imgur.com/JuuzKv6[/imgur]
Help pages are a necessity. While the wiki's CVAR/CCMD descriptions are useful, they're not accessible in-engine at all, and use more technical language. Every CVAR/CCMD needs to have some accompanying help text written, which would then be accessible through both a "help <CVAR|CCMD>" CCMD, and any menu item attached to that CVAR/CCMD. In menus, the help page would functionally be a submenu that's just a bunch of scrollable text. An unfortunate consequence of this, however, is that we're creating a whole lot more work for translators.
A search function would be incredibly useful. This was the best thing to happen to the settings page in Android, and it would probably go a long way in GZDoom too. It would search the menu item strings, value strings, and maybe also the associated help page texts. Of course, coding this would be a whole bunch of work too.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Brainstorming a GZDoom menu revamp
This sounds more like a complete redesign which is way out of scope. What we need right now is to regroup the menu to be easier to access, not a new menu system.
- m8f
-
- Posts: 1445
- Joined: Fri Dec 29, 2017 4:15 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Manjaro Linux
- Location: Siberia (UTC+7)
- Contact:
Re: Brainstorming a GZDoom menu revamp
phantombeta's menus are good.
There are some nitpicks:
1. Word "options" is redundant (it is in menu title, no reason to repeat "Player Options", "Gameplay Options", etc)
2. The new menu system must be backwards-compatible with mods that add their own menus to main options (AddOptionMenu "OptionsMenu"). So top-level menu name must be "OptionsMenu".
3. "Dynamic lights" is a submenu of "OpenGL Options", but it contains "Dynamic Lights (software)" option, which belongs to "Software Options".
4. Maybe rename "OpenGL Options" and "Software Options" to "OpenGL Renderer Options" and "Software Renderer Options"? Because "Software Options" is too generic name.
5. "Software Options" and "OpenGL Options" should become darkened and unselectable when other renderer is active. It will show what options are effective now.
Also, can we consider adding [Shortcut Menu] Vanilla Essence somewhere?
There are some nitpicks:
1. Word "options" is redundant (it is in menu title, no reason to repeat "Player Options", "Gameplay Options", etc)
2. The new menu system must be backwards-compatible with mods that add their own menus to main options (AddOptionMenu "OptionsMenu"). So top-level menu name must be "OptionsMenu".
3. "Dynamic lights" is a submenu of "OpenGL Options", but it contains "Dynamic Lights (software)" option, which belongs to "Software Options".
4. Maybe rename "OpenGL Options" and "Software Options" to "OpenGL Renderer Options" and "Software Renderer Options"? Because "Software Options" is too generic name.
5. "Software Options" and "OpenGL Options" should become darkened and unselectable when other renderer is active. It will show what options are effective now.
Also, can we consider adding [Shortcut Menu] Vanilla Essence somewhere?
- phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Brainstorming a GZDoom menu revamp
That was so it can be loaded as a PWAD instead of replacing the MENUDEF in gzdoom.pk3. (It would be changed to "OptionsMenu" if added to GZDoom, of course.)2. The new menu system must be backwards-compatible with mods that add their own menus to main options (AddOptionMenu "OptionsMenu"). So top-level menu name must be "OptionsMenu".
That can be probably chalked up to it being 3~4AM when I made that. I expected it to be worse.3. "Dynamic lights" is a submenu of "OpenGL Options", but it contains "Dynamic Lights (software)" option, which belongs to "Software Options".
BTW, I think the old menu system will need to be kept entirely. There's at least a few mods that add stuff to menus like the gameplay options menu (Hideous Destructor does this), and this new menu wouldn't necessarily be compatible with them.
So the new menus should be added with different internal names, and the old menus kept the same name, with a link to the old options menu at the bottom of the new menu or something.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Brainstorming a GZDoom menu revamp
Yeah, one can tell people a thousand times NOT to do that - one can even block replacement of existing menus and create an uproar - and people STILL do not create their own top level menu to do stuff but instead clutter it across the exiting menus. Frankly, I'm not sure how to deal with this. I have been extremely clear on saying that this stuff will break if the menus change and it still gets done.phantombeta wrote: BTW, I think the old menu system will need to be kept entirely. There's at least a few mods that add stuff to menus like the gameplay options menu (Hideous Destructor does this), and this new menu wouldn't necessarily be compatible with them.
-
- Posts: 4949
- Joined: Sun Nov 14, 2010 12:59 am
Re: Brainstorming a GZDoom menu revamp
A future-proof solution could be to have an engine-"endorsed" menu where modders can put their menus in. It could be a new options menu dedicated for that purpose. If modders stubbornly ignores it and put their menus somewhere else, they have nobody to blame but themselves if something happens in the future that breaks compatibility.
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact:
Re: Brainstorming a GZDoom menu revamp
Or that "AddOptionMenu" function we've had for a few versions.Blue Shadow wrote:A future-proof solution could be to have an engine-"endorsed" menu where modders can put their menus in. It could be a new options menu dedicated for that purpose. If modders stubbornly ignores it and put their menus somewhere else, they have nobody to blame but themselves if something happens in the future that breaks compatibility.
-
- Posts: 4949
- Joined: Sun Nov 14, 2010 12:59 am
Re: Brainstorming a GZDoom menu revamp
So this is not about adding to as well as modifying the menus? My bad, then. Ignore what I said.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Brainstorming a GZDoom menu revamp
Modifying the menus should be strongly discouraged.
This entire discussion is about reducing clutter, but adding options to the existing menus is the total opposite of that. How are people supposed to find stuff in there if they already have difficulties navigating it?
Any mod that wants its options to be FOUND, should group them in their own menus, which should be a submenu of the main options menu, or if the main menu is also redesigned, a submenu of that.
This entire discussion is about reducing clutter, but adding options to the existing menus is the total opposite of that. How are people supposed to find stuff in there if they already have difficulties navigating it?
Any mod that wants its options to be FOUND, should group them in their own menus, which should be a submenu of the main options menu, or if the main menu is also redesigned, a submenu of that.
- phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Brainstorming a GZDoom menu revamp
Doing that shit also makes the mod's options harder to find. I really don't get why people think adding their mods' options to the existing menus is a good idea.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Brainstorming a GZDoom menu revamp
Indeed. And that even applies to experienced users.
- Trusty McLegit
- Posts: 264
- Joined: Sun Feb 07, 2016 8:42 pm
Re: Brainstorming a GZDoom menu revamp
Another +1 to Xaser's proposal. I also think texture filtering should be on None (Trilinear) by default if that's still up for discussion