Tag: bug

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.

Now with twice the bits

I took a short break from the UI work to perform an autobuilder upgrade. The biggest changes are that the autobuilder now produces a new 64-bit Windows MSI package (including Start menu shortcuts), and an RPM package built on Fedora Core 23 (also 64-bit). This means all platforms now have a 64-bit package and Windows additionally has the old 32-bit one as well.

Launchpad builds both 32 and 64 bit packages for Ubuntu. All new Launchpad builds will be done on 16.04.

The upgraded Windows autobuilder uses a newer compiler (VS 2015, Visual C++ 14) and the latest version of Qt (5.6). I’ve also started signing the Windows executables and MSI packages so that you’ll have some assurance of their origin.

These changes may have caused regressions so keep an eye out for any odd behavior. Let us know how it goes!

The changes are also now reflected in the build repository here on dengine.net. For the time being I’ve linked the builds feed directly to the Autobuilder pages to access the latest files. Eventually I’ll rework the pages for builds and downloads — I’ve been eyeing the system for a backend redesign.

Bug reports have been indicating that recent work in the 2.0 unstable builds has caused some file handling issues. I took a closer look and noticed that in many cases, files written to the runtime folder were still being created using standard C I/O functions. This meant they were completely bypassing Doomsday’s internal file system and making assumptions that are no longer valid. I updated all the code that writes files to make use of Doomsday 2 APIs, including .cfg files, temporary MIDI music files, screenshots, the network ID (“client.id”), and creation of subdirectories in the runtime folder. This should take care of all these issues related to Doomsday being unable to write or save files at runtime.

These file fixes are currently in my Home UI work branch, but they will be merged into the master branch in the near future, along with the first iteration of the Home UI.