Doomsday 2.0 RC2

The second release candidate is available: build 2257.

This build has a number of bugfixes and minor improvements, particularly when it comes to loading and unloading data files. Some of the fixes affect metadata generated for data files, so if you’ve been running RC1, I recommend clearing Doomsday’s resource cache. This will also ensure that all add-ons are detected again, if some files were previously missing.

When one loads a savegame, Doomsday will attempt to load or unload resources depending on what was used in the save. However, this was quite buggy and could easily lead to a crash. There was also a mixup that caused Doomsday to try load and unload the same files twice. These issues are resolved in RC2.

I’ve made a couple of usability tweaks in Home. It should now be clearer when a profile is unplayable because the game IWAD is missing, or if the problem is that your selected additional packages are unavailable.

RC1 notes

It’s time to Talk

Things have been a little stagnant here on for a while, so I’ve made some improvements.

The discussion forums have been migrated to a new platform. phpBB was getting really old and clunky so I made the decision to replace it with something more sleek and modern. You can find the announcement on Talk.

Another nice improvement is that the autobuilder now has a proper database stored here on This means that the download pages can show you the latest files instantly, and the build feed actually reflects the currently available data. The feed itself is dynamically generated from the database instead of being just a static file. Plus I’ve given the build report pages a facelift so they’re nicer to look at. Finally, all downloads are hosted primarily here on, but they are also mirrored on SourceForge as before. The mirror download buttons can be found on the build report pages.

Doomsday 2.0 RC1

Build 2250 is the first Release Candidate for 2.0.

The full release notes will be available later, but the short version is that 2.0 introduces two big changes in how Doomsday works:

  • The Snowberry front-end application has been replaced with a new Home screen within Doomsday itself.
  • Doomsday has gained more understanding of various data file formats, resource packs, and add-ons so that it can load them without assistance from a front-end app. This Packages system has wide effects inside the engine, influencing game session configuration, savegames, multiplayer games, and the UI.

The updated Readme covers most of the new stuff, so that is a good place to start if you havent been using any 2.0 unstable builds recently.

There are certainly still bugs left to find and fix, so please report any problems you encounter with the RC build(s). The best place to do so is the Tracker.

In practical terms, development of the 2.0 release has been switched to the stable branch and is now in feature freeze mode. The master branch will roll over to 2.1 for new unstable builds. Now that the stable branch is using CMake as well, I’ve resumed the first-day-of-the-month stable builds.

Memory savings and metadata cache

Build 2237 introduces a number of changes aimed at making Doomsday launch faster and use less memory overall. It also fixes a couple of threading issues that were found with the help of Thread Sanitizer.

As part of preparing the stable 2.0 release, I’ve been looking at performance and memory optimizations.

Trimming memory use

I examined memory use in Instruments on macOS and identified a number of places for savings:

  • There is now a purpose-built class for keeping track of observer relationships between objects. There are hundreds of thousands of these being used in the engine, so using a class that is more optimal for the task saves both memory and improves performance.
  • Some objects had a lot of observers (20,000+) but worst of all, this was completely unnecessary because the observers were never being notified. These cases have now been removed.
  • Reduced memory used by Doomsday Script bindings for file system access by removing several unnecessary variables and replacing them with callable functions. This saves memory because functions can be stored in the class objects rather than in the objects themselves.
  • The file system caches uncompressed ZIP file contents in memory to avoid repeatedly decompressing them when the ZIP is being accessed. However, these cached contents were never released. Now ZIP caches are freed from memory whenever you return back to the Home screen.

After all these changes, Doomsday’s memory use on my system was roughly halved (from 830 MB to 460 MB). In practice, though, this heavily depends on how many resource packs and other data files you have available.

Caching metadata

When Doomsday is starting up it indexes and quickly analyzes all the resource packs, add-ons and other data files that you may have available. This may take a while depending on the number of these files and how fast your hard drive is. Starting with build 2237, Doomsday is now able to cache this information for future use, so after the analysis has been done it doesn’t have to repeated until the files change or new ones are added. Continue reading Memory savings and metadata cache

Improved UI for multiplayer

For the past two weeks I’ve been focusing on finishing the Home UI for 2.0. I’ve also been doing plenty of small improvements and bug fixes.

The final element that has been missing from the Home is the Multiplayer tab. That is now no longer the case: build 2227 has a new UI for viewing server information, and a couple of important bug fixes for multiplayer servers.

Server info dialog

In the Multiplayer tab you can see more information about a server by right-clicking it or by clicking the […] button in the server description. This pops up the new dialog that can be seen in the screenshot above.

A direct connection to the server is automatically attempted so that you’ll see the server’s current status and to verify that the server is reachable. The status information includes the current map outline, just like in the Shell.

In addition to status information, the dialog has a “Join Game” button, a list of the packages loaded on the server (the client must load the exact same ones when it connects), and you can choose additional packages to load locally. These local packages are game-specific rather than server-specific and are remembered in the client configuration (part of persist.pack). The “Local Packages” button is disabled by default. It can be enabled in Network Settings.

Note that if you load additional local packages in multiplayer games, you must ensure that they don’t contain gameplay-affecting changes. For example, loading a different map is out of the question, as are changes to mobj states. Doomsday 2 packages with 3D model assets are safe to use locally in multiplayer games.

I now consider this UI, along with the rest of the Home, feature-complete for 2.0. The long-term thinking behind the server info dialog is to evolve it toward a mini-Shell interface so that you could issue quick console commands to servers that you control. That will not be part of the 2.0 release, though.

Continue reading Improved UI for multiplayer

Improved UI for packages

For the past week I’ve been finishing up with the Home UI for the 2.0 release. The Packages tab has gained a lot of useful functionality.

Package popup

The Packages tab helps you browse and manage your PWADs, add-ons, resource packs and other data files (all of which are called “packages” in Doomsday 2). Build 2208 introduces a new UI for viewing information about packages and performing quick actions on them. Like the game tabs, I consider the Packages tab now feature-complete for 2.0.

The new package info popup has the following features:

  • The popup can be quickly opened by right-clicking a package in any Packages list.
  • There is a convenient “Play in…” button for quickly loading the package in an existing game profile, without making any permanent changes to profiles. This works great for quickly trying out PWADs, for example.
  • The “Add to…” button lets you add the package to any existing game profile.
  • The “Show File” button opens the folder containing the package in Windows Explorer / macOS Finder / etc. (This may not be very helpful if all your data files are lumped in a single folder.)
  • The “Options” button allows selecting from the optional .box contents. It was relocated here from the old context menu that no longer exists.

A little bit of content analysis is done on the package:

  • Doomsday tries to guess which game the package is for, looking through any auxiliary readme files, the used WAD map format, Snowberry metadata, names of parent folder(s), etc.
  • In the case of WAD files, the game title picture is shown in the popup as the package icon.
  • If the package contains an “icon.jpg” (or “icon.png”) file, it is used as the package icon image. Currently these images are only displayed in the popup.

Continue reading Improved UI for packages

Holiday update

As usual December has been a busy time, but a little bit of progress has been happening with Doomsday, too.

Saving 3D model state. I’ve put the most effort into ensuring that the state of 3D model animations gets saved and restored when writing and reading savegames. This has no bearing on gameplay as such, but visually it is pretty important that the objects get rendered the same way before and after loading a save. In practice, this was quite challenging because the new model renderer supports advanced features like multiple animation sequences, scripted rendering passes, and shader variables. All this state information gets included in the savegame package as a new file, so it can also be gracefully ignored in case any compatibility issues or other problems arise when dealing with old save files.

Multiplayer resource check. When joining a multiplayer game, the client checks that the same packages are loaded as on the server. This includes all WADs, DEHs, and PK3s. Any resource mismatches could lead to crashes or other problems during MP games.

Mac menu. I did a small tweak for the Mac UI: Doomsday now has a native menu bar for switching between the available games.

Fate. Finally, I’d like to call attention to a cool Hexen mod by fate that I recently enjoyed playing through. If like me you are a fan of Hexen, this is a nice way to spend a few hours during your holidays: fate_v0.1.pk3. Please leave your feedback and/or comments to the author on the forums.

Merry Christmas and happy holidays everyone! *<:)

UDMF experiment, Shell game options, installer facelift

Last week I went on a brief modding tangent and added a plugin that loads UDMF maps.

UDMF is an attractive choice for map editing due to its flexibility and potential to be widely compatible with map editors and source ports. However, it is basically only a syntax for describing map data; the real trick is interpreting the contents and supporting all the required gameplay logic, line and sector specials, etc. Doomsday at the moment supports only vanilla maps with a couple of Boom features. The new UDMF plugin also doesn’t yet transfer all the data to Doomsday, for example most line flags are ignored.

When it comes to extending Doomsday’s support for modding, I view full Boom compatibility as the first milestone to reach. Modding is on the roadmap for the future 2.4 release, so in the near future the UDMF importer plugin remains an experimental feature.

I also did many small improvements in preparation for the stable 2.0 release. Continue reading UDMF experiment, Shell game options, installer facelift

Version 2 multiplayer servers

Yesterday I merged a work branch where I’ve revised the way information about multiplayer servers is stored and distributed. The changes from “mp-serverinfo” are available in build 2144.

There are some important changes to discuss. Doomsday 2 servers are now incompatible and separate from Doomsday 1.x servers. Doomsday 2 uses a new status information format, new master server web API and new, compressed LAN broadcast messages. Doomsday 1.x clients will therefore not detect Doomsday 2 servers, and cannot query information about them (and vice versa). Continue reading Version 2 multiplayer servers

Tightening all the screws

For the past week I have been exclusively focusing on optimizations.

Work in the 2.0 unstable builds has been progressing without much attention having been paid to performance profiling. However, it has become clear that even in very basic maps (like Doom E1M1) there were unacceptable FPS dips. I decided to get to the bottom of what was going on. Continue reading Tightening all the screws