Brainstorming a GZDoom menu revamp
- Trusty McLegit
- Posts: 264
- Joined: Sun Feb 07, 2016 8:42 pm
Re: Brainstorming a GZDoom menu revamp
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?
- insightguy
- Posts: 1730
- Joined: Tue Mar 22, 2011 11:54 pm
Re: Brainstorming a GZDoom menu revamp
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 thatTrusty 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?
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.)
- Trusty McLegit
- Posts: 264
- Joined: Sun Feb 07, 2016 8:42 pm
Re: Brainstorming a GZDoom menu revamp
Well I only asked here because GFD mentioned phasing out opengl2
- Caligari87
- Admin
- Posts: 6174
- Joined: Thu Feb 26, 2004 3:02 pm
- Preferred Pronouns: He/Him
- Contact:
Re: Brainstorming a GZDoom menu revamp
Why not just run a map, turn on vid_fps and start changing settings?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?
- GFD
- Posts: 347
- Joined: Mon May 31, 2010 7:42 pm
- Preferred Pronouns: He/Him
- Location: Canada
- Contact:
Re: Brainstorming a GZDoom menu revamp
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.
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.
Re: Brainstorming a GZDoom menu revamp
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.GFD wrote:A global change to the simplified menus is changing "automap" to just "map" to reduce usage of confusing buzzwords
Automap is what it's called in Doom and other games.
You could have a "Player lose upon dying" header with the items grouped below.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.
Then they don't need to enter these menus.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.
Perfectionists like to have those.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.
Last edited by Gez on Fri May 18, 2018 12:34 pm, edited 1 time in total.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Brainstorming a GZDoom menu revamp
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.
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.
Re: Brainstorming a GZDoom menu revamp
Make another survey, which checks what options user change after first run of gzdoom?Graf Zahl wrote:Constructive ideas are welcome
Looks into another game options menu and check what, where and how game designer/programmer grouped?
- GFD
- Posts: 347
- Joined: Mon May 31, 2010 7:42 pm
- Preferred Pronouns: He/Him
- Location: Canada
- Contact:
Re: Brainstorming a GZDoom menu revamp
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: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.
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".Gez wrote:You could have a "Player lose upon dying" header with the items grouped below.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.
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.
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.Gez wrote:Then they don't need to enter these menus.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.
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.
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?Gez wrote:Perfectionists like to have those.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.
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.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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Brainstorming a GZDoom menu revamp
Even then, dumbing down the terminology is going to help nobody.
- 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
Ok so it's not really a replacement menu, it's actually a supplemental one. I can get behind that.GFD wrote:Again, my vision is to preserve the existing menu structure separately for power users like you and me.
- insightguy
- Posts: 1730
- Joined: Tue Mar 22, 2011 11:54 pm
Re: Brainstorming a GZDoom menu revamp
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.Graf Zahl wrote:Even then, dumbing down the terminology is going to help nobody.
Keep all the power user options but at least add a longer description on the bottom or something.
- GFD
- Posts: 347
- Joined: Mon May 31, 2010 7:42 pm
- Preferred Pronouns: He/Him
- Location: Canada
- Contact:
Re: Brainstorming a GZDoom menu revamp
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.
- 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
I'd volunteer to it, personally. I just need a communication channel with a dev.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.
Re: Brainstorming a GZDoom menu revamp
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.