Tag: ui

Files and fixes

Last week I continued working on Home and data file packages, and fixed a number of bugs.

Loading of PK3s, WADs, individual lumps, DED files, and Dehacked patches is now working via Home. Loading of .box folders is also somewhat operational, although the dependencies of the box contents are not yet completely handled. (Boxes can have required, opt-out, and opt-in files.)

I put quite a lot of additional effort into cleaning up how data files get mapped to Doomsday packages particularly when it comes to selecting identifiers and tags. This could still be improved with additional rules for smart detection of file groupings based on common names and parent folders. I’ll probably leave the finer adjustments for later.

The game profiles you see in Home are now more deeply integrated into the rest of the application. They are used when loading game plugins, so that the packages selected for the profile are appropriately loaded and unloaded. Multiplayer games will also be using profiles shared by the server.

I also did several bug fixes for issues that have cropped up in recent unstable builds:

  • On Windows, quitting the game might not always trigger unloading of the game plugin, leaving you with a black screen. (Shift-Esc was still working.)
  • If the .cfg files were missing when launching Doomsday, they weren’t written at all. The clearest symptom of this bug was that your settings were not remembered when relaunching the game.
  • There was a long-standing bug in the doomsday.out file writer that had not been triggered before. It was causing log output to stop being written to the file at a certain point.
  • The Home UI layout was not always updated correctly when the window was resized (or display resolution changed) while a game was being played.
  • Popup widgets with long text content were using too much memory.
  • There was an illegal memory access to a deleted object when closing submenu popups, for example when viewing information about a package.

Refinement

I came down with a small cold so progress has been somewhat slow recently. My main focus continues to be the Home UI.

I’ve mostly been applying small bug fixes and improvements, such as correcting errors in the Home layout. The Tutorial was also crashing because it was trying to reference a removed UI element. There is now a new settings dialog for configuring the UI. This includes a new setting for slightly scaling down the fonts and other UI elements. This should be particularly helpful when using smaller display resolutions. Continue reading Refinement

Game profiles, autobuilder upgrade

Progress has been somewhat slow recently. The central new component I’ve been working on is game profiles. They represent the combination of a game and a list of packages to be loaded with that game — much like a Snowberry profile. A key feature of the Home UI is to let you create and manipulate game profiles.

You may recall that a few years ago we added renderer appearance profiles to manage the various renderer settings. The implementation of these was tied to the old console variable system, but there was a good portion of code that was reusable also for game profiles. I refactored the appearance profiles to extract the generic parts that deal with saving and loading profiles to/from an Info document, and generalized the concept of a profile. That allowed me to rather easily implement game profiles. In practice, the profiles will be written to a file called “configs/game.dei” under the runtime folder.

Now that Ubuntu 16.04 is around the corner, the autobuilder server is due for a system upgrade. My plan is to get rid of the 32-bit Linux builders (Launchpad should take care of that), and only set up builders for 64-bit Ubuntu and Fedora. The Windows builder will be using Windows 10 and the upcoming Qt 5.6 with MSVC2015. I should be finally able to configure a 64-bit build also for Windows (fingers crossed!).

Steady progress

Last week I continued working on the Home UI as planned.

There is now basic keyword filtering for the Packages list. The entered words are matched against package names, IDs and tags, so it is possible to quickly locate specific packages.

The current implementation is quite rough, though, and not suitable for large collections of packages. It needs optimizing, and the list widget itself should support reusing a small number of widgets to represent only the potentially visible items. At the moment it simply creates widgets for the entire list, even though most of them would be outside the view.

Another improvement is persistent state for the Home columns and item selections. In other words, when you start Doomsday, the previously selected column and game are automatically re-selected.

On the whole the work is progressing as planned and it is clear what needs to be done next. My short-term goal is getting all the important features working so the new UI can be released in the unstable builds for public testing.

Prototype stage

I’m still focusing squarely on finishing a fully functional first iteration of the new Home UI, and it is coming along nicely. Here’s a brief glimpse of how things are looking currently (click for an animated gif):

home_columns

Basic tasks like selecting a game or a saved game are working, and I have a list of the multiplayer games up as well. Main focus is now on the Packages tab, where I’ve revamped the list’s appearance. The next step is to implement some additional features for managing packages, like sorting, filtering and searching. After that the only thing that’s needed is a little of bit of performance tuning in the widgets framework to iron out the worst bottlenecks — this is the most complicated UI so far running on the new widgets and it is revealing some previously unseen issues.

Home improvement

Work continues on implementing a functional prototype of the new Home design. The current status is that it is possible to select and start a game, and load saved games. The Multiplayer browser and package management UIs are still missing.

As expected, the planned ideas didn’t feel quite right when I got to try them out in practice. For instance, I was envisioning that when one selects a game (say, “Doom II”), a list of saved games would expand below it. The rationale was that it would save space to not show all the savegames all the time. However, in practice it was extremely distracting that the game items would keep moving up and down in the list due to saves being shown and hidden above them. I ended up just keeping the save lists visible all the time.

Next I will focus on the multiplayer browser. The basic idea is to use widgets similar to the ones used in game selection, but of course show information relevant to multiplayer. When it comes to the package manager, it will be based on the existing (preliminary) Packages dialog, with a couple of additions and improvements.