Custom episodes. Episode definitions specify the structure of game episodes (including hubs) enabling entirely new episodes and modifying the originals.

MAPINFO support. Hexen MAPINFO definitions are now supported in Doom and Heretic, as well as Hexen. Note that presently only the Hexen dialect of MAPINFO is supported (ZDoom uses it's own MAPINFO dialect).

Improved BSP builder. Better performance and more robust interpretation of Doom map hacks.

Adjustable pixel density. If your GPU is on the slower side, you can improve performance by reducing game view resolution. The rest of the UI remains sharp since the display mode isn't changed. As a bonus, you can also get a nice nostalgic aesthetic similar to the original Doom on a VGA display.

UI improvements. Refinement of the Doomsday UI continues: the tutorial has been made a little nicer, savegames can be deleted via the Home/taskbar savegame selection menu, alert notifications are hidden automatically after a couple of minutes (so you don't have to keep looking at the yellow triangle icon all the time), and a dialog has been added where you can specify the MIDI soundfont file conveniently. On OS X, there is now support for retina (HiDPI) displays.

Set IWAD folder in the Home screen. Allows starting Doomsday without the frontend or any command line options. We are not ready to remove the frontend altogether, since you still can't select add-ons or resource packs via the GUI, but this is significant progress toward an independent Doomsday.

Bug fixes. See the Detailed notes to see a summary of the bugs that have been fixed.

Dependencies. Many of the libraries Doomsday is built on have been updated. Qt 5, SDL 2, and C++11 provide new and improved functionality that runs better on modern operating systems.

If you are upgrading an existing installation of Doomsday, note the following:

• On Windows, the Menu key on your keyboard can now be used to open the task bar. The binding is added automatically after you upgrade. You can still use the Tilde key or Shift-Esc to open the task bar, too.
• server-game-episode and server-game-map no longer use numeric IDs that start from 0. The episode IDs are now defined in DEDs, and the map is identified as “E1M1”, “MAP03”, etc. This means a server that uses these cvars in a .cfg file may need some reconfiguring.

Packages. So far Doomsday has had no internal understanding of resource packaging. The Snowberry frontend has been responsible for parsing package metadata and deciding which actual files Doomsday should load when starting a game. This will be changing in the future. We have been building a new file management system (“FS2”) that does a better job at virtualizing the underlying data and has direct links to the new Doomsday Script language. We have put together a new package format that takes full advantage of FS2 and Doomsday Script. This will be the format used for packaging 3D models in the future. However, we will also allow loading old/other resource package formats for backwards compatibility, although they may not support all the new functionality that future versions of Doomsday will bring.

Assets. With the objective of formalizing resource management, a new internal concept has been introduced. Assets are sets of resources for a specific purpose, for example a 3D model for a particular lamp in Doom 2. All assets are described in package metadata using the Info syntax, and this metadata will inform Doomsday about how the individual resource files in the package should be used at runtime. Assets are uniquely identified, so information about which ones to use — or have been used — can be recorded in savegames and shared in multiplayer sessions. In 1.15, only 3D model assets are supported, but future versions of Doomsday will expand on this.

Doomsday Script subclassing. The new scripting language provided by the Doomsday 2 core library continues to evolve. In 1.15, support for subclassing has been added, meaning you can derive objects from other objects. This is a crucial mechanism when it comes to representing runtime objects like map data, files, and packages in scripts, because the superclass objects can provide all the built-in bindings, and the individual instances only need to contain instance variables.

Doomsday Script native types. A new built-in Core module was added which contains class objects for various built-in data. In 1.15, the Core module is somewhat of a proof-of-concept: it only contains a handful of classes. This will eventually be expanded to cover all relevant native classes.

DEDs visible in Doomsday Script. The built-in Defs module exposes many of the currently loaded DED definitions:

$ dir(Defs)
⇒ [ decorations, episodes, finales, flags, mapInfos, materials, models, musics, skies ]

Internal thinker data. Over the past several years we have been working to completely isolate games from the engine's internal workings. The benefit of this is that the engine can use more advanced data structures and mechanisms internally, while the games can rely on simplified, traditional map data. While the map data structures are close to achieving perfect isolation, thinkers (including mobjs like monsters and pick-up items) have been “open” data that is fully shared between the engine the games. This is not ideal because the engine in many cases benefits from having object-specific data, and keeping that “on the side” is less efficient and more complicated than having the objects themselves own it. For this purpose, internally 1.15 now allows all thinkers to have data that is only visible inside the engine. For example, 3D model animation state for the upcoming new model renderer is kept in this internal, object-specific data.

Convex map subspaces. Previously map geometry used a single component to represent both BSP half-spaces and convex subspaces. This complex dual purpose representation made dealing with Doom map hacks a messy affair and one had to be mindful of the context in which the geometry was evaluated. By separating these concerns the engine is now able to hide much of this complexity and provide a unified representation to the renderer, while also encapsulating the BSP tree within the engine.

Removed dependency on map data naming conventions. Previously maps had to be named according to an EXMY or MAPXX convention, in order for them to be found by the engine and understood as maps - this practice is no longer necessary, allowing mod authors freedom to use whatever name they like (formalized into a URI). This is achieved through a heuristic detection algorithm which scans loaded resources for map data and collates them into an internal list (associated with the URI), independent of the game they are intended for. The listmaps command can be used to inspect this list at any time and both warp command and -warp option allow maps to be specified using such URIs.

• Detailed list of changes in 1.15
• Version 1.15 in the Roadmap
• Bugs closed in 1.15
• Known issues: list of all open bugs in the Bug Tracker