Brainstorming a GZDoom menu revamp

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Re: Brainstorming a GZDoom menu revamp

Postby Graf Zahl » Mon Apr 09, 2018 3:53 am

This is going in the right direction, but the choice of options is still not optimal, with stuff in there that makes little sense and missing other important stuff instead

If you want a main menu with basic options, I still think that Upscaling, Anti-alias, Bloom and Dynamic lights have no place there.
Most certainly not the screen border size. That's a relic from 24 years ago when computers were slow, and only is kept for historical reasons, not because it presents a need.

Imortant things are:

Sound volume
Keyboard customization
Basic mouse options (speed, invert Y axis
Set Screen resolution - this will be the first thing most people want to go to!!!
Texture filter mode (this one I insist on, considering what a hot topic it seems to be for some users.)
Gamma correction.

And that's it.

@Matt: The menus maybe should have an expert mode, but that should be decided once we have a working design.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Brainstorming a GZDoom menu revamp

Postby Pixel Eater » Tue Apr 10, 2018 1:13 am

Menu.pk3
(5.86 KiB) Downloaded 27 times
Damn internet went down for hours right before I was about to upload this :evil:
screenshot2.jpg

Okay, so... three minor things are left to do. The Player and Joystick menus need to be brought forward into the Multiplayer and Control menus and there is a section mapped out for each with links to their old pages. I've attempted to do it myself but it throws up errors, likely because it's a custom menu. And the third teensy thing is the !!!GRAPHICS MENU!!! I wish I could make that font flash :lol:
User avatar
Pixel Eater
I sense evil I fear it here today, Like a bad dream that never goes away -MBerry
 
 
 
Joined: 02 Aug 2017
Location: In between the Moon and you, between the buried and me.

Re: Brainstorming a GZDoom menu revamp

Postby Pixel Eater » Wed Apr 11, 2018 8:41 am

Menu.pk3
(8.51 KiB) Downloaded 27 times
screenshot3.png
The graphics menu is done. I think the wording needs a lot of work overall and I've had to shorten a few descriptions to keep the menus centered. It still needs the player and joystick menus brought forward but how is it feeling to people so far?
User avatar
Pixel Eater
I sense evil I fear it here today, Like a bad dream that never goes away -MBerry
 
 
 
Joined: 02 Aug 2017
Location: In between the Moon and you, between the buried and me.

Re: Brainstorming a GZDoom menu revamp

Postby m8f » Wed Apr 11, 2018 8:49 am

Aren't "Software" and "OpenGL" too vague? Maybe "Software Rendering" and "OpenGL Rendering"? This may cause too long lines in Lighting section, and can be fixed by moving Dynamic Lights to a separate section:
Spoiler:
User avatar
m8f
the dreamer
 
 
 
Joined: 29 Dec 2017
Discord: m8f#0629
Github ID: mmaulwurff

Re: Brainstorming a GZDoom menu revamp

Postby Kotti » Wed Apr 11, 2018 8:50 am

I see you still have separate entries for Rendering and Truecolor Software. These have been merged in the 2D Refactor branch which the next minor release will probably be based on.
Kotti
 
Joined: 27 Dec 2016

Re: Brainstorming a GZDoom menu revamp

Postby Pixel Eater » Wed Apr 11, 2018 9:07 am

Screen-Shot-4.png
Hmm, makes the above section look a little thin. I could bring Fake Contrast out of the advanced menu to fill it out I guess and change it's heading to Static or Stationary Lighting...
User avatar
Pixel Eater
I sense evil I fear it here today, Like a bad dream that never goes away -MBerry
 
 
 
Joined: 02 Aug 2017
Location: In between the Moon and you, between the buried and me.

Re: Brainstorming a GZDoom menu revamp

Postby Pixel Eater » Wed Apr 11, 2018 9:10 am

Kotti wrote:I see you still have separate entries for Rendering and Truecolor Software. These have been merged in the 2D Refactor branch which the next minor release will probably be based on.
Oh I'll take a look at that, thanks! I haven't been keeping up on the lastest while working on this.
User avatar
Pixel Eater
I sense evil I fear it here today, Like a bad dream that never goes away -MBerry
 
 
 
Joined: 02 Aug 2017
Location: In between the Moon and you, between the buried and me.

Re: Brainstorming a GZDoom menu revamp

Postby Hipnotic Rogue » Wed Apr 11, 2018 10:08 am

Iterative change in the menu layout might be easier for users to swallow. After all, a lot of the menu stuff has been like this for a very long time.

While I like a lot of Pixel Eater's stuff, I actually kinda like the menu re-jig in Adventures of Square 2. It's a good step in the right direction.

Also, just as a quick change, I'd suggest combining Video Options and Display Options. To my mind Video and Display are almost the same thing. :)
User avatar
Hipnotic Rogue
 
Joined: 15 Jul 2016

Re: Brainstorming a GZDoom menu revamp

Postby Pixel Eater » Wed Apr 11, 2018 10:35 am

Hipnotic Rogue wrote:Also, just as a quick change, I'd suggest combining Video Options and Display Options. To my mind Video and Display are almost the same thing. :)
For this proposal, Video Options (now called Setup Display) is staying separate and identical, acting as part of a simplified 'quick setup' screen while Display Options (or Graphics) is where the fun begins. You can test it out as a .pk3 file just a few posts back.

Edit: Even though it's after 2am I had to download and try Square. That's pretty awesome :D
User avatar
Pixel Eater
I sense evil I fear it here today, Like a bad dream that never goes away -MBerry
 
 
 
Joined: 02 Aug 2017
Location: In between the Moon and you, between the buried and me.

Re: Brainstorming a GZDoom menu revamp

Postby GFD » Wed Apr 11, 2018 12:00 pm

It's clear that we really need to know specifics on how the 2D refactor will affect what options affect what renderers now. I'm close to finishing the design and writeup on my "simplified" menu, but I'm no longer sure about the layout of video and graphic options in light of 2D refactor stuff. For example, will the brightness, contrast, and saturation options be able to apply to the software renderer in addition to the OpenGL renderer now? What about the bloom and lens distortion effects? Will dynamic light settings be reduced to a single set of CVARs instead of having separate ones for software and OpenGL?
User avatar
GFD
My brain's probably worth a lot of money!
 
Joined: 31 May 2010
Location: Canada

Re: Brainstorming a GZDoom menu revamp

Postby Pixel Eater » Wed Apr 11, 2018 3:54 pm

What about the bloom and lens distortion effects? Will dynamic light settings be reduced to a single set of CVARs instead of having separate ones for software and OpenGL?
Those would be nice.
Recently I've been thinking that if the software engine gained PP shader support it would become a very solid contender for first place :)

Edit: I've made a feature request regarding the dynamic light cvars.
User avatar
Pixel Eater
I sense evil I fear it here today, Like a bad dream that never goes away -MBerry
 
 
 
Joined: 02 Aug 2017
Location: In between the Moon and you, between the buried and me.

Re: Brainstorming a GZDoom menu revamp

Postby Pixel Eater » Sat Apr 14, 2018 5:12 am

Menu.pk3
(8.71 KiB) Downloaded 41 times
The Mac developer build came out today so I got to add in the new renderer switching changes.
It's now pretty close to how I want it and if it's approved I'll clean up the messy code and update the language file. Does anyone have thoughts/suggestions?
User avatar
Pixel Eater
I sense evil I fear it here today, Like a bad dream that never goes away -MBerry
 
 
 
Joined: 02 Aug 2017
Location: In between the Moon and you, between the buried and me.

Re: Brainstorming a GZDoom menu revamp

Postby GFD » Sun Apr 15, 2018 3:19 pm

Pixel Eater wrote:The Mac developer build came out today so I got to add in the new renderer switching changes.
It's now pretty close to how I want it and if it's approved I'll clean up the messy code and update the language file. Does anyone have thoughts/suggestions?
Respectfully, I find this messy. Any attempts to put the most "important" options on the topmost level will fail because every user prioritizes different options. This layout makes it harder to find options by not categorizing them all consistently; now users have to look through all the options on the top level to make sure it's not one of those before they start the usual process of looking through categories.
The language used also remains confusing. Uninitiated users won't understand the terminology used in option names like "FX volume" and "shadowmaps" and "show player sprites".
I do like the usage of a > character at the end of some of the submenu entries. They've always been in need of visual distinction, and this is simple but effective.

Graf Zahl wrote: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.
Those three features aren't strictly necessary, but in terms of major features that would greatly improve menu usability, those were the biggest ones I could think of at the time. They're listed from most-important to least-important—I would still say showing all available settings in a list with left-click or enter is a must. Here's a concept as to how this would look:

Image

In this concept, the yellow asterisk shows the current setting, and the blue highlight shows the current selection. Up and down change the selection, enter changes the setting to the selected one and closes the popup, and escape closes the popup without changing anything.

Now, I will cover the simplified options menu I've designed as a counterpart to the more advanced menu we already have. (I also plan to do some reorganizing of the existing advanced options menu, but I haven't had time to focus on that yet. Just don't forget that it and its settings are not going anywhere!) But keep in mind that there's a lot of stuff that straight-up doesn't work at all right now as a result of various hardcodings and inflexibilities with how MENUDEF currently functions. A bunch of this is probably fixable with ZScript already, but I simply lack the time and expertise to delve into the code myself.
I follow several menu design guidelines that I've created and laid out in this document. Give it a read if you want to better understand some of the design decisions I've made, such as the renaming of many options and settings. (Be aware that several examples in this document are outdated and don't reflect the current state of the menu redesign.)
A global change is that I've increased the spacing of menu items a bit. This makes it much easier to read, at least for me. Several OptionValues also use coloured text now, eg. green for "on" and red for "off". This increases readability, but it isn't done in a very flexible way right now. Ideally, there should be a way to control these "positive" and "negative" OptionValue font colours with GameInfo properties.

Image

The top-level menu now has about half as many categories. I doubled-spaced the items just because there was room to do so. In theory, this could be implemented as a ListMenu instead of an OptionMenu, since there's more room for bigfont text now.

Image

"Controls" is a consolidation of the top three categories from the old options menu. All the mouse options have been seriously condensed to just two menu items here. This is based on the assumption that the game will be starting with mouselook enabled by default for most players, which it really should in this day and age. (My vision here is for a first-time startup dialogue box asking the player to pick a control preset, with everything enabling mouselook by default except for the ancient "DOS defaults" preset for advanced users.) The "Looking up and down" option actually controls m_pitch. Setting this to "Disabled" should also vertically centre the player's view in-game somehow, since it's fairly useless to have the view get stuck in a non-centred position when disabling this.
Reasoning for excluding the other options from the old "mouse options" menu:
Spoiler:
This menu is a perfect place for the "always run" and "autoaim" options that were previously located in the old "player setup" menu, which never made any sense. The "switch on pickup" option from the old "player setup" menu has not been carried over, however, as its function is difficult to explain concisely, and it has very little impact on gameplay relative to everything else. The "always run" option was renamed to "Default move speed", with options of "Walking" and "Running", to better clarify what it does exactly. The term "auto-aim" now has a hyphen added to it, which makes it easier to read. Even though it's not how the Doom community at large tends to spell it, it doesn't really add any confusion here. The "Vertical auto-aim" option still controls "autoaim", but only has "On" and "Off" settings of 35 and 0 respectively, as full control over the vertical autoaim distance seems unnecessary for almost all users. "Auto-aim priority" was moved here from the old "gameplay options" menu (where it was called "smart autoaim"), but it's still a candidate for removal, as it's relatively obscure. It greys out when "Vertical auto-aim" is "Off". Its settings have been renamed for clarity, but the "never friends" setting was removed entirely. Friendly monsters are an infrequently used mechanic, which would make it confusing to players who have never encountered this mechanic before, while even even if they have encountered it, it's still a setting with relatively little impact.

Image

The "customize controls" menu has been renamed to "Change Game Controls" to further distinguish between this menu and the "Change Map Controls" menu. The information text at the top has been expanded to two lines to allow for clearer explanations, and the blank separator line has been changed to a row of underscore characters, so it's visibly obvious that there's a separation happening here. A lot more headers have been added. Some controls have been renamed for clarity.
Some other controls have been removed from the list, but the most important are "fly / swim up/down" and "stop flying", because their removal is based on a rework of the flight and swimming controls to be simpler and require fewer keybinds. (Of course, options can be added to the advanced menus to control this behaviour.)
  • "Jump" should provide the same functionality as moving up by default. (Currently it does move up, but it is significantly slower.)
  • "Crouch" should provide the same functionality as moving down by default.
  • Flight should automatically be stopped when touching the ground by default, and only reactivated when the player inputs jump or fly/swim up.
Reasoning for excluding the other controls from the old "customize controls" menu:
Spoiler:
This menu is in dire need of some adjustments and new features. Some item at the top of this menu for loading and saving control presets (as discussed in a couple places before, like here by me) would be wonderful. It would also be great to be able to further condense all these controls. (Just think of how small the menu could be with a vanilla Doom mod!) If possible, there should be a method for detecting what controls are actually in use by the current game, and greying out the controls that aren't applicable to the current setup. (Some things might only be reliably detectable by just letting mods tell GZDoom if they needs the controls or not.) These non-essential controls include:
  • "Look up", "Look down", "Center view", "Jump", "Crouch (hold)", and "Crouch (toggle)", when these abilities are disabled by all the maps or the user;
  • "Secondary attack", "weapon reload", "Weapon zoom", "Weapon state 1", "Weapon state 2", "Weapon state 3", and "Weapon state 4", when no weapons use these states;
  • The entire "Inventory" section, when inventory items are not used;
  • The entire "Multiplayer" section, when not playing multiplayer or with bots, and just the message functions when only playing with bots;
  • The entire "Strife Popup Screens" section, when not used.
Assignment of controls could also benefit from more features. Allowing an indefinite number of inputs to be bound to a control by using a list popup would generally be very useful. Some controls like Run and Show scores have "hold" and "toggle" variants, but it'd be generally useful to have the option to make any bound input a "hold" or a "toggle" type, for controls where holding does something different from tapping. I could draw up concepts of how these ideas might look and work if anyone is interested in doing the work to implement this.

Image

"Change Map Controls" is the only submenu that appears in two places, being located both here in "Controls" and in "Interface and HUD → Map Options". Reasoning for excluding the other controls from the old "customize map controls" menu:
Spoiler:


Image

"Controller options" has had the options to disable individual types of controllers removed, as I'm not sure how this functionality would be useful to most users. The global toggle and menu control option remain, to ensure that issues with misbehaving joystick devices can be troubleshooted. Actual joystick selection functionality remains limited to the old controller menu right now, as it appears to be hardcoded.
This menu attempts to use a newline in the name of an option to make things fit better (I'm aiming to fit as much as I can on-screen at 320×200 with all supported IWADs). Unfortunately, it doesn't work very well right now; the setting is not vertically centred with the text, and these items need blank lines manually added beneath them so that they don't overlap with other option names. (As well, I had to include a LANGUAGE file with my MENUDEF file below, because string literals in MENUDEF can't have newlines.)
The hardcoded "Configure Controller" menu needs some changes that I don't know how to make. Ideally, I would think the title of the menu should be the name of the controller as seen in the previous menu. "Overall sensitivity" should only be used for the global sensitivity slider; the others should just be called "Sensitivity". The sensitivity sliders for each axis shouldn't be borked by toggling the "invert" option; either these sliders should be able to go into the negatives, or how the "invert" option works should be changed. I would also rename the "strafing" setting for axes to "Moving left / right", to remain consistent with changes made in the "Change Game Controls" menu.

Image

"Player Setup" now only has stuff actually related to configuring the player, instead of also having some control settings shoved in there. I hate the old gross and hardcoded menu, since its appearance and functionality differ so much from all the other menus, but unfortunately I can't replicate all its functionality in a normal OptionMenu. Notably, there are no usable pre-populated OptionValues for "team", "color", "class", and "skin", so these options don't really work right now. There is also obviously no player preview window. The "Team" option is greyed-out when teamplay is false. "Custom color" should be greyed out when colorset is not -1. "Class" and "Skin" should be hidden entirely when there is only one option for them.

Image

"Interface and HUD" is meant to house options for configuring all 2D screen elements. "HUD type" actually controls screenblocks, but only has options of "None", "Status bar", and "Fullscreen", since the smaller screen sizes are no longer useful for performance reasons when render resolution can be controlled directly. The "alternative HUD" options have been discarded entirely, because it seems more like a legacy relic to me than anything else, and interferes with the ability for mods to present the user with a more useful HUD tailored to that mod's mechanics. "Weapon graphics" is the "show player sprites" option, moved here from the old "display options" menu. The entire old "scaling options" menu has been replaced with a single "Interface & HUD size scale" option here, to reduce complexity while still serving the needs of most users. It also no longer uses the hopelessly confusing ScaleSlider setting type, which I super hate. (While "hud preserves aspect ratio" from the old menu has also been discarded, I'm not sure why the default is "off".) The "Mouse cursor" option only has choices of "Game default", "Simple arrow", and "System cursor", as having the cursors for other IWADs seemed out of place and just complicated things. The "Menu appearance" option does not actually work; it is meant to be a toggle between the default appearance of the menu (being dimcolor, dimamount, and gl_menublur) and a customized appearance, but no such CVAR exists yet. The three settings following it would be greyed out when it's set to "Default". (This assumes the menu blur effect will be able to apply to the software renderer in the future.) The flash type settings from the old "hud options" menu have not been carried over, as they should just default to the faithful settings. The "use old ouch mug shot formula" setting is also discarded, due to being something only advanced Doom users would understand.

Image

A global change to the simplified menus is changing "automap" to just "map" to reduce usage of confusing buzzwords, which makes this the "Map Options" menu. "Change map controls" is available here in addition to the "Controls" menu. "Map rotation" only has "On" and "Off" as settings, to reduce complexity added by the "On for overlay only" setting that wouldn't apply to all settings for "Map type" anyway. "Display statistics" does not work right now, but would consolidate am_showitems, am_showmonsters, am_showsecrets, am_showtime, and am_showtotaltime into this single toggle. This would be greyed out when "Map type" is "Overlay".
Reasoning for excluding the other options from the old "automap options" menu:
Spoiler:


Image

"Crosshair Options" is a small menu for any needed crosshair options from the old "hud options" menu. Every other option should be greyed out when "Default shape" is "None".
I don't love using a regular slider for controlling the size, because it makes the "no scaling" setting of zero difficult to understand, but I'm not sure what the best alternative here is. ScaleSliders would be a minor improvement if they supported floats, but they do not.
"Custom color" should be greyed out when "crosshairhealth" is false. The "force default crosshair" option has been removed for being confusing and largely unneeded. The "grow crosshair when picking up items" option doesn't seem necessary for most users when there's plenty of other audiovisual feedback for picking up items.

Image

"Message Options" has been greatly simplified. The three options below "Messages" are greyed out when it is "Off". Reasoning for excluding the other options from the old "messages" menu:
Spoiler:

Image

"Display and Video" is mostly for show right now, as it's currently not possible to functionally implement this menu the way I envision it. it's based on a radical proposition: changing the actual screen resolution is a relic of ancient times. With LCD screens and square pixels, it doesn't make sense to run at anything besides the native resolution of the monitor. Reducing the actual screen resolution to save on performance only made sense with CRT monitors, which could display multiple resolutions with the same level of clarity. With the ability to arbitrarily resize the window, and the ability to change the rendering resolution separate from the display resolution, there's no reason to have a video menu with a confusing list of screen resolutions at all. At least with this menu, GZDoom should always fullscreen at the native resolution of the monitor.
Pre-edit: it looks like the devs share some of these thoughts here. However, Graf mentions that legacy users might need to change the actual screen resolution because their systems cannot make use of resolution scaling. In this case, the "Resolution Options" section's items might need to be replaced with ones for choosing an actual screen resolution when it's not possible to use resolution scaling.
"Fullscreen" does not function currently, as the borderless mode is controlled by a different CVAR from exclusive fullscreen. The "Monitor for fullscreen" option is a must, rather than making users go to the console to execute vid_listadapters and then set vid_adapter. This doesn't have a pre-populated OptionValue it can use right now. Such an OptionValue should have settings in the format "n [WidthxHeight] (Primary)", and ideally with these settings in the order of left to right (and top to bottom, if multiple monitors have the same X coordinate). The "GPU selection" option is here right now, but it's a candidate to be either moved to or duplicated in the "graphics and effects" menu, as most other performance-affecting settings are located there.
The "Resolution Options" section does not work, so I will describe how I want it to work.
  • "Upscaling type" will be greyed out when "Resolution scaling" is "none".
  • "Scale factor" will be greyed out when "Resolution scaling" is not "Factor".
  • Changing "Render width" and "Render height" will directly change the rendering resolution. They cannot be set below 320 and 200, respectively. Any 8:5 resolution entered will automatically add letterboxing so that users can easily replicate "classic" resolutions with tall pixels. They will be greyed out when "Resolution scaling" not is "Custom size".
  • Changing "Window width" and "Window height" will directly change the window resolution. They cannot be set to be larger than the canvas size of the computer's attached displays. They will be greyed out when "Fullscreen" is not "Off".
The width and height options use the not-so-useful NumberField type, but there's no good alternative here. NumberFields just need to be made more useful, but my previous proposal to do so was uh, sabotaged.
The "Stereoscopic 3D mode" option removes the "left eye" and "right eye" settings. Generally, I'm unsure as to why it's necessary to have a separate CVAR that enables quad-buffered 3D; ideally, this would be eliminated, the "Stereoscopic 3D mode" setting would be archived, and switching to quad-buffered stereo would show the user a prompt that says GZDoom must be restarted for it to be enabled. As well, is quad-buffered stereoscopy used by any 3D PC display hardware besides NVidia 3D Vision? If not, I would refer to it as that instead.
Excluded from the old "video mode" menu are "aspect ratio", "forced aspect ratio", and "forced ratio style". These are fairly complicated options that require a good understanding of how aspect ratios work, and so would just confuse most users.

Image

"Graphics and Effects" has a "Rendering type" option at the top level, which is the only option that is placed above any submenu entries, because it affects which submenu is currently applicable. The "Graphics Options (Classic)" and "Graphics Options (OpenGL)" submenus should be greyed out when their renderer is not in use. The poly renderer isn't to be included as a setting here, since it's still experimental right now, to my knowledge.
As we get into the graphics options menus, which have been a hot topic for discussion lately in terms of presets and whatnot, here are my thoughts that have shaped my menu designs here. Presets for these things can never get the job done, because it's just too subjective for each user. My solution here is to make the most important / impactful graphical options available here, use clearer language to describe their functions, and consolidate some options that should logically go together.

Image

"Classic Graphics Options" includes an option for FXAA right now. If the software renderer will never support FXAA as the OpenGL renderer does, this option should be removed. Otherwise, FXAA should be given a separate CVAR between software and OpenGL renderers, so that it can be usable with the software renderer while not clashing with MSAA in the OpenGL renderer. The options under "Texture Options" are greyed out when "Color type" is "8-bit palette". (The 2D refactor renders this option inoperable right now.) Here, "Texture filter mode" controls r_magfilter, while "Far texture filter" controls r_minfilter.

Image

In "OpenGL Graphics Options, the "Color type" option here actually controls the gl_tonemap CVAR, with settings of "8-bit palette" and "Full color". The other tonemap options are excluded—dpJudas himself called them "mostly useless", and more suited to be used as artistic choices by mappers. Ideally, this option should also control the gl_bandedswlight CVAR, since using the palette tonemap doesn't replicate the classic look very well without it, and having it enabled in truecolour seems pointless and also looks gross. While "Rendering precision" isn't a very clear option name, the setting names still help users choose. The "Smooth edges" option doesn't work right now, but it would control both FXAA and MSAA, as it doesn't make sense to have them both on at the same time anyway. The acronyms for these AA types are still included in the option values so that users who know what they mean can quickly understand what they're controlling more exactly.
Similarly, "Texture filter type" and "Far texture filter" don't work right now. The former would change between none and linear filtering. The latter would control the mipmapping type and anisotropic filtering; "None" means no mipmapping or anisotropic filtering, "Low quality" means nearest mipmapping and low anisotropic filtering, "Medium quality" means linear mipmapping and medium anisotropic filtering, and "High quality" means trilinear and high anisotropic filtering.
"High-res upscaler" no longer has two types of hqx and xBRZ. The "MMX" version of hqx was discarded since it seems to turn everything green. The "old" version of xBRZ was discarded, since I assume "old" is a codeword for "worse", and sprite edges seem to look worse with this to me.
"Shadow quality "is greyed out when "Lights cast shadows" is "No". "2D object style" controls billboarding, with "Vertical" being y billboarding and "Tilting" being x/y billboarding. These names are the best I could come up with without using technical terminology here.
"Fog / lighting style" and "Invisibility style" are two options I'm very unsure about, and that I most want to hear feedback on. I don't even feel like "Fog / lighting style" should have any options besides "Classic", as maps can specify their own lighting mode through MAPINFO. At the same time, though, other options might need to remain available for old maps made for GZDoom before the software fog style existed. But will most users even know to use them? Most settings for "Invisibility style" seem unnecessary now, as they seem to try and imitate the software renderer fuzz in different ways, but the new method looks a lot more faithful than any of them. I did leave in "Shadow" in for users who dislike the constant movement of the other style.

Image

"Special Effect Options" includes other graphical stuff that's renderer-agnostic. ("Screen transition" appears to default to "Melt (Doom)" for IWADs that used other types, like Heretic and Strife... Why?) The three "intensity" options are candidates to be combined into a single option, but at least right now I feel it's better for them to stay separate. For example, some users might like the visual feedback from taking damage, but find the flashing from picking up items annoying. "Bloom effect" and "Lens distortion effect" don't seem to affect the software renderer in the 2D refactor like I had anticipated, and if this continues to be the case going forward, then I'm unsure as to where these two options should be placed. They don't change how things are rendered like other options in "Graphics Options (OpenGL)", but they couldn't stay in this otherwise renderer-agnostic menu either. "Bullet puff type" and "Rocket trail type" are currently IfGame(Doom)'d, since they don't have any effect in other supported IWADs by themselves as far as I'm aware.

Reasoning for excluding the other options from the old "display options" menu:
Spoiler:


Image

"Sound" is greatly simplified. As is visible in the preview GIF, this is one menu where settings can get cut off at 320×200, but I don't see an easy way around this here when "Microsoft GS Wavetable Synth" is so bloody long. (Heretic/Hexen/Strife, with their larger smallfonts, also can't fit "OPL Synth Emulation".)
Reasoning for excluding the other options from the old "sound options" menu:
Spoiler:


Image

The "Gameplay" menu houses compatibility options and multiplayer options. The only user-facing thing here for compatibility options is the presets, since making individual compatibility toggles available is far too confusing and overwhelming.

Image

"Cooperative options" is fairly brief, but it's still necessary for it to be its own submenu to clearly separate these options from the deathmatch ones. "Dead players lose" does not currently function, but would be a lot less confusing to use than the current system of 7 separate menu items for controlling what's lost upon death.

Image

"Deathmatch options" is more expansive, but to be honest, I'm not sure how much of this can be changed after a network game has already begun, as I've never tried or tested. "Big powerup respawning" is greyed out when "Item respawning" is "Off". "Friendly fire" and "Team switching" are greyed-out when "Teams" is "Off". "Friendly fire" reduces control over teamdamage to 1 or 0, since finer control complicates things without adding enough benefit.

Reasoning for excluding the other options from the old "gameplay options" menu:
Spoiler:


You might have noticed the old "miscellaneous options" and "network options" menus have been completely discarded. Everything in those menus is advanced and niche-use. In general, I've been relatively aggressive in removing anything I didn't think would be useful to non-advanced users, but I figure it's better to remove something and re-add it after feedback than to leave too much stuff cluttering up the menus.

I would love to hear any and all thoughts or feedback about these designs, whether you love it or hate it.

Attached is a small mod to add this menu, but you'll have to excuse its state. Besides lots of stuff not being functional as discussed earlier, properly using it right now requires commenting out all "protected" keywords in gzdoom.pk3's menudef.txt, or replacing the file entirely. Obviously this isn't how anything should be done, but that's how I have things set up right now so I can just focus on editing this file. I've also replaced all LANGUAGE keywords with their actual strings, again to make it easier for me to edit. (The exception is the previously mentioned cases where I've used LANGUAGE keywords to make usage of newlines.)

I'm about to find out if the ZDoom Forums have a character limit.
Attachments
gfd_simple_menu_v1.zip
(22.72 KiB) Downloaded 43 times
User avatar
GFD
My brain's probably worth a lot of money!
 
Joined: 31 May 2010
Location: Canada

Re: Brainstorming a GZDoom menu revamp

Postby Nash » Mon Apr 16, 2018 2:49 am

I admit I haven't read EVERYTHING that gfd wrote (sorry, at work) but at a quick glance, I can say that most of it looks alright, but what I specifically wanted to praise was the use of colours on the option menu items. I personally dig that. :D

Will have a more thorough look later
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: Brainstorming a GZDoom menu revamp

Postby Graf Zahl » Mon Apr 16, 2018 5:25 am

Most of GFD's stuff looks really good. Unfortunately I'm not at my home computer right now but I'll check it this evening and provide some feedback.

Just one thing: The main options menu has a very distinct appearance and I'd like to preserve that, if possible. This has been in ZDoom for 20 years and is one of its trademarks.
Last edited by Graf Zahl on Mon Apr 16, 2018 12:56 pm, edited 2 times in total.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to General

Who is online

Users browsing this forum: Majestic-12 [Bot], Xtor98 and 7 guests