Brainstorming a GZDoom menu revamp

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
User avatar
Trusty McLegit
Posts: 264
Joined: Sun Feb 07, 2016 8:42 pm

Re: Brainstorming a GZDoom menu revamp

Post by Trusty McLegit »

Any idea when Vulkan is coming? I know there's probably not a set time line but like are we talking near future, or like 10 years from now?
User avatar
insightguy
Posts: 1730
Joined: Tue Mar 22, 2011 11:54 pm

Re: Brainstorming a GZDoom menu revamp

Post by insightguy »

Trusty McLegit wrote:Any idea when Vulkan is coming? I know there's probably not a set time line but like are we talking near future, or like 10 years from now?
Sorry, This seems to be the wrong thread for that, Vulkan support is not probably included in this thread, you might want to make a new thread for that

Also, can we have a master audio slider? Makes for convenient volume adjustment for when you just want the volume to go down in general. (NB4 "just turn down your volume insightguy" a master volume slider is still standard in many cases.)
User avatar
Trusty McLegit
Posts: 264
Joined: Sun Feb 07, 2016 8:42 pm

Re: Brainstorming a GZDoom menu revamp

Post by Trusty McLegit »

Well I only asked here because GFD mentioned phasing out opengl2
User avatar
Caligari87
Admin
Posts: 6174
Joined: Thu Feb 26, 2004 3:02 pm
Preferred Pronouns: He/Him
Contact:

Re: Brainstorming a GZDoom menu revamp

Post by Caligari87 »

insightguy wrote:Not sure how viable is this, but what about a "simulation map" of sorts? a map that runs in the background to show what actually changed and to test what's making the game into a power point presentation?
Why not just run a map, turn on vid_fps and start changing settings?

8-)
User avatar
GFD
Posts: 347
Joined: Mon May 31, 2010 7:42 pm
Preferred Pronouns: He/Him
Location: Canada
Contact:

Re: Brainstorming a GZDoom menu revamp

Post by GFD »

An extra feature I thought of recently would be a very basic "benchmarking" tool that, using the current scene, automatically goes through the process of disabling individual graphical enhancements and measuring their relative impact on performance. The end result would be a menu presented to the user where options are listed, from highest impact to lowest impact, underneath headers that show some indication of how much impact they have (probably either FPS gain or percentage of speed gain). This would all be prefaced with a disclaimer that this isn't an exact science, of course, but it would still save users the time of constantly opening and closing the menu and squinting at the FPS counter to see how they can improve performance best. Not to mention they can do this without actually messing with their gameplay session at all, which could have time-sensitive elements that are impacted by having to do all this manual performance evaluation.

But, such things can be explored more in the future after a fundamental menu reorganization has already been completed. Basics like a better organizational structure and clearer language should be the priority for the time being.
Gez
 
 
Posts: 17831
Joined: Fri Jul 06, 2007 3:22 pm

Re: Brainstorming a GZDoom menu revamp

Post by Gez »

GFD wrote:A global change to the simplified menus is changing "automap" to just "map" to reduce usage of confusing buzzwords
I strongly disagree with this. Automap isn't confusing. Map, however, is confusing because it's a synonym for level. I mean, we have the MAPINFO lump and all.
Automap is what it's called in Doom and other games.
GFD wrote:"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.
You could have a "Player lose upon dying" header with the items grouped below.
GFD wrote:
  • the "advanced options", "midi player options", "module replayer options", and "reverb environment editor" submenus are all things that would go straight over the heads of most users.
Then they don't need to enter these menus.
GFD wrote:[*]"icon's death kills its spawn" is very niche and also uh doom 2 spoiler warning much????
[*]"end sector counts for kill %", [...] are pretty niche.
Perfectionists like to have those.
Last edited by Gez on Fri May 18, 2018 12:34 pm, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49053
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Brainstorming a GZDoom menu revamp

Post by Graf Zahl »

Please note that trying to make a product idiot-proof will also mean that most knowledgeable people will have difficulty operating it.
How often have we seen that somebody 'optimized' their product by dumbing down the user interface and in the process the old power users lost their flexibility.
No, thank you. Constructive ideas are welcome but if it boils down to "we don't need insert random options" I'm out.
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Brainstorming a GZDoom menu revamp

Post by Apeirogon »

Graf Zahl wrote:Constructive ideas are welcome
Make another survey, which checks what options user change after first run of gzdoom?
Looks into another game options menu and check what, where and how game designer/programmer grouped?
User avatar
GFD
Posts: 347
Joined: Mon May 31, 2010 7:42 pm
Preferred Pronouns: He/Him
Location: Canada
Contact:

Re: Brainstorming a GZDoom menu revamp

Post by GFD »

Gez wrote:I strongly disagree with this. Automap isn't confusing. Map, however, is confusing because it's a synonym for level. I mean, we have the MAPINFO lump and all.
Automap is what it's called in Doom and other games.
Yes, while I haven't made a post about it yet, this is actually one of the changes I've already made locally, for the same reasons. I realized it ended up being more confusing without the distinction between "level" and "map" (something I realized while using the 'map' CCMD and being like "hmm, hold up").
Gez wrote:
GFD wrote:"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.
You could have a "Player lose upon dying" header with the items grouped below.
The problem is that, from what I can tell, with 7 options there are 128 possible combinations, but only 48 of them aren't redundant. Many combinations also seem very unlikely to be used, so I thought the best solution might be to just give a couple "presets".
It could still work well as you said, with all the options under a header to offer more flexibility. It's not like there's a whole lot else in my "Cooperative Options" menu anyway. But I'd need more clarity on how exactly all these options actually work, since they seem pretty confusing as they are.
  • Wouldn't "lose entire inventory" make every other option have no effect at all? In which case, why not leave it out and let this functionality be accomplished by setting all the other "keep" options to "no"?
  • Does having "keep ammo" off make "lose half ammo" have no effect? In this case, they should become a single option, perhaps "keep ammo" with settings like "yes", "only half", and "no".
  • Does "keep powerups" even do anything...? Stuff like invisibility or berserk seem to reset as soon as the player dies anyway, so I don't know what this is meant to do.
Gez wrote:
GFD wrote:
  • the "advanced options", "midi player options", "module replayer options", and "reverb environment editor" submenus are all things that would go straight over the heads of most users.
Then they don't need to enter these menus.
The whole idea is to offer a version of the menus with reduced complexity. Leaving these submenu entries intact means the user has to scan over more items to find the ones they want, and makes the menu more imposing/intimidating, while not offering enough benefit for non-power users.
Of course, one approach to this whole thing would be to have an "advanced options" menu at the bottom of every single "simplified" menu. I went with the idea of having a global toggle between "simple" and "advanced" to more easily preserve the current option menu structure for users more familiar with it, and reduce unnecessary navigations for power users. You could have it both ways, though, by keeping the global toggle while adding an "advanced options" shortcut to the bottom of simple options menus that have an advanced counterpart. With the way my simple menus have been restructured, though, not every simple menu has a direct advanced counterpart now.
Gez wrote:
GFD wrote:[*]"icon's death kills its spawn" is very niche and also uh doom 2 spoiler warning much????
[*]"end sector counts for kill %", [...] are pretty niche.
Perfectionists like to have those.
Wouldn't these perfectionists be the sorts of power users accustomed to the inner workings Doom engine that would be using the advanced menus anyway?
Graf Zahl wrote:How often have we seen that somebody 'optimized' their product by dumbing down the user interface and in the process the old power users lost their flexibility.
Again, my vision is to preserve the existing menu structure separately for power users like you and me. They can completely ignore this simplified version I'm building for less advanced users. I don't see any downside to offering this as an optional option.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49053
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Brainstorming a GZDoom menu revamp

Post by Graf Zahl »

Even then, dumbing down the terminology is going to help nobody.
User avatar
Pixel Eater
 
 
Posts: 667
Joined: Wed Aug 02, 2017 12:31 am
Location: In between the Moon and you, between the buried and me.

Re: Brainstorming a GZDoom menu revamp

Post by Pixel Eater »

GFD wrote:Again, my vision is to preserve the existing menu structure separately for power users like you and me.
Ok so it's not really a replacement menu, it's actually a supplemental one. I can get behind that.
User avatar
insightguy
Posts: 1730
Joined: Tue Mar 22, 2011 11:54 pm

Re: Brainstorming a GZDoom menu revamp

Post by insightguy »

Graf Zahl wrote:Even then, dumbing down the terminology is going to help nobody.
not really, you don't have to remove what's there, just make a description pop up when the option is selected. A short description makes things miles easier than guessing what something like the poly-render option does and why you may want it on-off.

Keep all the power user options but at least add a longer description on the bottom or something.
User avatar
GFD
Posts: 347
Joined: Mon May 31, 2010 7:42 pm
Preferred Pronouns: He/Him
Location: Canada
Contact:

Re: Brainstorming a GZDoom menu revamp

Post by GFD »

Help text is another thing to consider for the future after other stuff like organization has been agreed upon. It would be a whole task unto itself, considering the sheer amount of text that would have to be written and reviewed.
User avatar
Tapwave
Posts: 2096
Joined: Sat Aug 20, 2011 8:54 am
Preferred Pronouns: No Preference
Graphics Processor: nVidia with Vulkan support

Re: Brainstorming a GZDoom menu revamp

Post by Tapwave »

GFD wrote:Help text is another thing to consider for the future after other stuff like organization has been agreed upon. It would be a whole task unto itself, considering the sheer amount of text that would have to be written and reviewed.
I'd volunteer to it, personally. I just need a communication channel with a dev.
Gez
 
 
Posts: 17831
Joined: Fri Jul 06, 2007 3:22 pm

Re: Brainstorming a GZDoom menu revamp

Post by Gez »

I'd like to point out that we already have a huge bunch of help text written for the existing menu options and their associated CVARs; it's called the ZDoom Wiki.
Post Reply

Return to “General”