Howdy, Stranger!

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

In this Discussion

Week 20/2013: GUI widgets

edited 2013 May 20 in Developers
Last week we released the 1.10.3 patch and I was working on the UI framework.

The 1.10.3 patch corrects a few regressions that were introduced during the 1.10 unstable phase. It is worth mentioning that in the future, we will try to continue pushing bug fixes out via the "stable" branch, as not all of them can be caught during the candidate phase(s). Also, 1.10 will likely receive some patches even after the stable 1.11 is out as the minimum system requirements will be upgraded somewhat in 1.11.

My primary focus has been on new UI widgets for the client's GUI. All the things I've been working on during the past weeks are now coming together: the next-gen UI framework in libdeng2, drawing graphics using the new GL2 code, reading definitions for fonts, colors, length rules and images from scriptable Info-based files, managing data objects at runtime using Banks, reusing UI widget logic from the text-based UI components created for the Shell, and animating widget positions at runtime using the Rules system.

I'm currently working on a set of basic UI widgets that are required for the new console UI: text editor, log entry history view, and basic buttons/labels. On the whole, I would characterize the new UI widgets as extremely flexible from both programmer and modder point of views. Eventually I plan to set up a mechanism for constructing the entire UI based on scriptable Info-based definitions: then one can easily add completely new UI elements/dialogs/menus in addition to just changing the UI style parameters. (Initially the UI structure will be hardcoded, though.)

Finally, a screenshot showing a test of the new UI code drawn on top of Heretic:
hello_world.jpg

Comments

  • Last week I continued working on the map geometry generation.

    At the start of the week I continued revising the generation in the map renderer. The sky fix geometry (that which is drawn in outdoor areas to "mask" areas in the z-buffer) was abstracted, extracted and then implemented using the same edge centric model used for wall sections and FakeRadio shadows. The algorithm responsible for converting a stream of geometric edges into a triangle strip geometry was wrapped up into a generic component (can now be used with any edge type).

    The second half of the week was all about the BSP building side of the map geometry generation. Specifically I focused on bug hunting and routing out the obvious issues with the geometry it was producing. Several significant bugs in the space partitioning algorithm which inadvertently subverted the partioning logic were found and fixed. The final geometry is now looking a lot cleaner and few of the id Tech 1 map hacks are now working (without any changes to the engine itself). There is however at least one bug remaining in the space partitioner that has so far managed to elude me.

    This week I plan to continue working on the BSP (in particular focusing on the interpretation of invalid mapping constructs) and to implement a redesigned wall geometry generation inspired by DOOM's software column renderer.
Sign In or Register to comment.