Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

Week 32/2013: Toggles

edited 2013 Aug 12 in Developers
Last week I was working on a number of topics, although my focus remains on the UI framework.

I added a new type of UI widget called ToggleWidget. It is a simple on/off switch that is now used for enabling the FPS counter and for a new "Go to Bottom on Enter" option in the console log options:


The toggle widgets are basically buttons that have a specific, animated graphic displayed next to their label. To make this as flexible as possible, I modified the base label widget class to allow drawing animated graphics in addition to static 2D images from the UI style definitions. This means that all label-based widgets are now able to draw animated content. This should prove quite useful in the future.

(As always, the visual appearance of the new widgets is a work-in-progress and will likely be refined in the future.)

Console autocompletion was tuned to behave in a more user-friendly manner: the first press of Tab will only show the completion popup if nothing can be inserted to the command line. Otherwise the popup will appear on the second press of the Tab key. This avoids the popup from obscuring the view needlessly.

The possible completions are now shown also in the Shell app, although as text rather than a popup.

Another console related change was that if you leave something typed on the command line and close the task bar, the contents of the command line will be moved to the command history and the command line is cleared.

I proceeded to fine-tune and make various fixes in the UI framework, related to clipping at view boundaries, animation of popups and buttons, and optimizing the performance of certain aspects of the framework. You should be able to see a noticeable FPS increase with the DE menu open, for instance.

The Doomsday Script environment continues to evolve. This time I added a new script module called that is responsible for application-specific default configuration. Previously this was all mashed together in libdeng2's module, which is incorrect as libdeng2 is intended to be a generic component shared by many applications and thus should contain no functionality unique to any of them.

In the long-term, we plan to migrate to Qt 5 as this allows us to expand our operating system reach. I downloaded the latest version of Qt 5 and gave it a whirl. After fixing a couple of minor compatiblity issues I was able to get through a build, but unfortunately it didn't run properly. I will return to this once Qt 5 has been developed further — the problem is likely due to us using some obsoleted APIs or mechanisms.

Related to this, I checked where we are at for creating a 64-bit build on Windows. In short, the story is that while there should be no problems compiling the engine with MSVS 2012 in x64 mode, we are dependent on a number of third-party libraries that also need to be switched to 64 bits. This will take a bit of time and effort to do, although thankfully many of them already offer prebuilt 64-bit versions.

Finally, we tried to hunt down a cause for the high-resolution texture suppression bug that is present in the autobuilt Windows packages but not in our developer builds. This is the problem where, for instance, this switch shows an incorrect texture in Alien Vendetta when running with high-res textures:
Unfortunately, we couldn't yet determine the exact cause for this in the Windows builds.

My plan for this week is to readjust back to normal life rhythm after the summer vacation. :)


  • Last week I continued work on the map representation by cleaning up a few loose ends from the Doomsday 1.11 release.

    With the map geometry now fully modelled with a half-edge data structure, the role of a "Segment" in the id Tech 1 map format is now almost entirely fulfilled by these more generalized geometry components. However, for the 1.11 release the segments were left in situ as work on fixing up the BSP builder overran significantly.

    Today I merged the 'remove-segment' branch which sees the old segment component removed and the map renderer's data for these relocated up the map element hierarchy into Line::Side. From a user perspective there is no perceivable difference, however from an engine design perspective this is an important step toward generalizing the drawable map geometry generation.

    My plan for this week is to remove another component which remains from the old days -- the "LineOwner" concept (which, links map geometry vertices to lines). Similarly to Segment, line owners are now redundant in the presence of the map wide half-edge data structure.
Sign In or Register to comment.