Week 35/2013: Video settings
Last week I made a replacement for the old Control Panel Video settings page and tweaked the UI style.
The big thing for last week was creating a new Video Settings dialog for changing the display mode, window attributes, and monitor color adjustments. I managed to complete this and removed the corresponding Video page from the old Control Panel.
While working on the Video Settings dialog I encountered several issues in the UI framework that needed addressing and/or refactoring. To mention a few: popup menus now automatically make themselves scrollable if they don't fit in the view; it is possible to have multiple columns of items in a popup menu; all widgets weren't using margins properly; text drawing was made easier with the help of a high-level utility class; image layout issues in labels; and widgets weren't told the size of the view when they were added to the widget tree.
The monitor color adjustments dialog that can be opened via Video Settings needed a "slider" type of widget. Sliders are also heavily used in the old Control Panel to adjust various cvars, so I needed to implement one for the new UI framework.
Now that there is a larger set of widgets available, we can take steps toward a more cohesive visual UI style. I tweaked some aspects, most notably button borders and border glow. The changes are quite subtle but can be seen in the screenshot:
The 1.12 release has been scheduled for the end of September, which means we'll be entering Candidate phase around mid-September. Until then I will be continuing work on tearing down the old Control Panel.
The big thing for last week was creating a new Video Settings dialog for changing the display mode, window attributes, and monitor color adjustments. I managed to complete this and removed the corresponding Video page from the old Control Panel.
While working on the Video Settings dialog I encountered several issues in the UI framework that needed addressing and/or refactoring. To mention a few: popup menus now automatically make themselves scrollable if they don't fit in the view; it is possible to have multiple columns of items in a popup menu; all widgets weren't using margins properly; text drawing was made easier with the help of a high-level utility class; image layout issues in labels; and widgets weren't told the size of the view when they were added to the widget tree.
The monitor color adjustments dialog that can be opened via Video Settings needed a "slider" type of widget. Sliders are also heavily used in the old Control Panel to adjust various cvars, so I needed to implement one for the new UI framework.
Now that there is a larger set of widgets available, we can take steps toward a more cohesive visual UI style. I tweaked some aspects, most notably button borders and border glow. The changes are quite subtle but can be seen in the screenshot:
The 1.12 release has been scheduled for the end of September, which means we'll be entering Candidate phase around mid-September. Until then I will be continuing work on tearing down the old Control Panel.
Comments
However, I question the need for two panels (i.e a separate 'video settings' and 'colour adjustments'). I don’t think they individually contain enough things to make a second window nesscerry. Obviously yourself may be planning for the future though (i.e dozens more options may be added to either panel in future as Dday gains more graphical features or the number of separate pages on the old control panel are streamlined into fewer in the new UI).
That said, I admit that if the panels where merged into one, that I’m not sure in which existing panels place it should open on the screen at. I like that the video settings panel opens right next to where the mouse cursor is and I also imagine that yourself placed the colour adjustment panel where you did because you wanted the user to be able to see clearly what effect moving each slider was having in the game world.
Personal opinion is that the maximized option shouldn't immediately take effect if the user toggles it while in full screen; it's effect should be delayed until the user actually enters windowed mode.
On another note, I notice that toggling Antialiasing pauses the game, I assume due to the feature requiring the rebuilding of the image and hence focus on Dday is temporarily lost?
- On average the user needs to adjust the colors less often than the other display mode settings, so keeping them separate reduces clutter.
- As you noted, when adjusting colors it's good to allow maximum visibility of the game view.
That's a good point. I'm also thinking about having the "Mode:" only affect fullscreen mode, with the windowed mode having to be sized with the mouse as one would resize any other window.Yeah that's correct. The bug here is that window focus shouldn't be considered lost in this situation.
EDIT: Fixed.
Last week I continued work on improving the interpretation of map hacks and specifically, implementing "missing texture" hack support. I decided to split this task in two after determining that such constructs fall into two logically distinct subgroups. Depending on the geometry of the map and the relationship between sector planes on the Z axis, Doomsday will need to handle each subgroup somewhat differently.
The case of a map geometry where such a hack is used to visually "transfer" a physically lower sector plane to a higher one in another sector is now supported. This includes all variants of this method for "deep water", rising pits in the floor which conceal monsters, etc...
The more difficult and opposite case of a hack which visually transfers a physically higher sector plane to a lower one in another sector is not yet supported however. This variant (which includes such constructs as "invisible walls") produces different results in vanilla depending on the position of the viewer vs that of the geometry itself. Generating different geometry in such a manner is far from ideal so instead I'm looking into a mechanism whereby both geometries are always available. Essentially this means dynamically generating additional visual planes.
Implementing support for the simpler case revealed that it was necessary to update various old map renderer mechanisms in order to visualize these correctly. Supporting the hack in itself was relatively straight forward but updating these older systems is taking a little longer.
My plan for next week is to continue working on map hack support.
Obviously, the user will still have to confirm actual install. Or might that be considered too intrusive?
Or some sort of flashing icon saying something like 'there is an update availible; click for more information' in the corner, rather than displaying a prompt in the middle of the screen at preset times?
Obviously, I am aware that the current phase is updating the existing UI to the new one, rather than adding new features and I might be being presumptuous.
I’m not sure that 'developer' is the best term to describe 'advanced options that Deng team assume won't be of interest to the common user'.
I don't think it's 'friendly' to users, to 'assume' various options will only be of interest or understood by certain groups of people (i.e deng team, mod developers etc).
In some cases, it obscures what the option actually is; for instance 'Developer info' on the audio menu displays the sound channel information. An option that was clearly called that on the old Control Panel; well, it was called 'show status of channels'.
We can naturally use more concise language in the settings, for instance for the sound channel info.
I can only think of "Advanced" or "Tools" to use instead of "Developer", though... What would be your suggestion?
Every game I can recall uses 'advanced', 'advanced options', 'advanced settings' etc.
This should be what you need?
May I suggest changing 'fullscreen mode' to something like 'resolution'?, particularly as it's now seemingly used to set the windowed mode resolution?