Week 37/2013: Profiles, script mode, style tweaks
Last week I continued working on the Renderer Appearance editor and the UI framework in general.
The Appearance editor now stores setting profiles persistently and separately from games. This means that all created profiles are available in all games; there are no game-specific profiles.
In practice, the profiles are currently written into a file called "configs/renderer.dei" in your runtime folder. There will also be a way to read profiles from resource packs in use.
Note that you can continue to change cvar values manually in the console. This is equivalent to editing the current profile in the editor, and the changes will be saved to your currently selected appearance profile (by default called "Custom"). In other words, the editor is essentially a GUI for a group of console variables.
An interactive Doomsday Script mode was added to the console command line widget. You can toggle between regular console command mode and Doomsday Script mode at any time using the console options menu. However, at this stage the usefulness of the new mode is a bit limited due to the small set of available script bindings and the lack of autocompletion. If you're interested in playing around with it, you could for instance try the following simple statements:
I also continued fine-tuning the UI style related to dialog button placement, icons, and progress indicator behavior. In the screenshot you can see how the auxiliary buttons of the dialog are now grouped to the opposite edge (e.g., "Reset to Defaults"), and that the configuration menu has an icon for each item:
As my last big change for 1.12, I revised how text is preprocessed for drawing. Recently I added a new class called TextDrawable that handles all the details of text preprocessing and also supports background tasks for lengthy operations so that the UI is not blocked if a long piece of text needs to be prepared. TextDrawable is now in use by LabelWidget, and is applied in several places of the UI — basically everything that pairs an image and some text uses a LabelWidget.
The 1.12 candidate phase begins this week (38). We are planning to make the release in the end of the month. I'm going to start the candidate work by profiling all the new/revised code to see if we can apply further optimizations.
The Appearance editor now stores setting profiles persistently and separately from games. This means that all created profiles are available in all games; there are no game-specific profiles.
In practice, the profiles are currently written into a file called "configs/renderer.dei" in your runtime folder. There will also be a way to read profiles from resource packs in use.
Note that you can continue to change cvar values manually in the console. This is equivalent to editing the current profile in the editor, and the changes will be saved to your currently selected appearance profile (by default called "Custom"). In other words, the editor is essentially a GUI for a group of console variables.
An interactive Doomsday Script mode was added to the console command line widget. You can toggle between regular console command mode and Doomsday Script mode at any time using the console options menu. However, at this stage the usefulness of the new mode is a bit limited due to the small set of available script bindings and the lack of autocompletion. If you're interested in playing around with it, you could for instance try the following simple statements:
$ import Version
$ print Version
$ for i in [0,1,2]: print i
$ print locals()
I also continued fine-tuning the UI style related to dialog button placement, icons, and progress indicator behavior. In the screenshot you can see how the auxiliary buttons of the dialog are now grouped to the opposite edge (e.g., "Reset to Defaults"), and that the configuration menu has an icon for each item:
As my last big change for 1.12, I revised how text is preprocessed for drawing. Recently I added a new class called TextDrawable that handles all the details of text preprocessing and also supports background tasks for lengthy operations so that the UI is not blocked if a long piece of text needs to be prepared. TextDrawable is now in use by LabelWidget, and is applied in several places of the UI — basically everything that pairs an image and some text uses a LabelWidget.
The 1.12 candidate phase begins this week (38). We are planning to make the release in the end of the month. I'm going to start the candidate work by profiling all the new/revised code to see if we can apply further optimizations.
Comments
The common drive of development work last week was about consolidating support and revising engine systems accordingly. Lets look at some maps which benefit from these developments.
KSutra - MAP05:
You may recall in week 34 this area was interpreted incorrectly.
Eternal DOOM III - MAP02:
Both screenshots show setups involving multiple nested map hacks, which are now interpreted correctly.
Plutonia 2 - MAP10:
I also fixed a bug with the interpretation of middle wall section coordinates.
When I began this work for 1.12 I hardly envisioned it taking quite the form it has. Certainly, I somewhat underestimated the impact it would have on the design of Doomsday's runtime map format, which I had previously thought was complete with the introduction of the half-edge data structure in 1.11.
The biggest change this week is that map hacks are now resolved dynamically in response to plane movement. World surface decoration was reimplemented to use an OO design and flare sources are now generated directly from these (which should provide a small performance boost). Also, environmental audio characteristics (reverb) now uses sector cluster granularity (rather than the same properties being used for all geometry of a sector).
Essentially a "sector" in Doomsday is now little more than a definition of plane and lighting properties once the BSP has been constructed. Nowadays it is the BSP leaf "clusters" that we primarily interested in. I expect that in 1.13 the role of a sector will further diminish and the clusters will effectively succeed them. Its interesting that we are now farther away from the design of the id Tech 1 map format than ever, yet support for it's map hacks is considerably better.
During the candidate phase I intend to continue polishing map hack support and if time permits, I'd like to introduce support for the fake plane/invisible wall hacks.
I'm just not sold on the multitexturing part of the renderer sub menu. Somebody unfamiliar with the term 'multitexturing' could confuse them for generic disable/enable 3d model, dlight, generator, fakeradio etc toggles and hence will get confused if the options don't do that. I think they should be merged into the rendering appearance menu.
I think, if a Rendering sub menu is to exist between the main menu and renderer appearance menu, it should contain things like generic disable/enable 3d model, dlight, generator, fakeradio etc toggles instead. I think that would greatly improve usability of that section of the UI.
To make clear though, I'm not suggesting moving the profile selection option from the renderer sub menu (in the long term, users will make several different profiles and what to switch between them as quicky as they can, hence that option should remain on the render sub menu), just the multitexturing options.
Of course, toggling a, for instance, enable/disable 3d models option on the rendering sub menu would update the in use profile.
My reasoning is that because the toggles for enabling/disabling 3D models, dynamic lights, etc. clearly affect the appearance of the rendered world, thus they belong in Renderer Appearance.
I will make a few changes here, though. The dialogs and menus are easy to change and the design is still in flux. I expect new dialogs, buttons, and submenus to be added and removed as the UI evolves.
I've moved the HUD weapon mirroring under "3D Models" in Renderer Appearance. I'm a bit unclear as to what is the use case of this feature, though. Is it intended for left-handed people so they can view non-centered weapons in a more suitable manner? My earlier thinking was along that line, and therefore the setting was separate from the individual appearance profiles, applied independently of the current profile.