Supporting old-style resource packs in 2.0

This week my primary attention has been on figuring out an approach for handling v1.x style resource packages (PK3s and Snowberry boxes) natively in Doomsday. On the side I’ve been working on dynamically loading and unloading shaders from Doomsday 2 packages.

Since we’ve gotten rid of Snowberry in the 2.0 unstable builds, Doomsday needs to provide the UI for selecting which addons and resource packages to use when playing a game. While Doomsday already generally knows how to load data files, it doesn’t have any concept of configuring game sessions comparable to how the frontend did this.

For Doomsday 2 packages I’ve implemented an internal package manager that can find packages in the file system, carry out the loading and unloading operations, and keep track of the metadata. This is all the plumbing that is needed for Snowberry-style resource packages. Fortunately, the new Doomsday 2 package metadata syntax is largely compatible with Snowberry’s metadata.

When it comes to packages that are not in the Doomsday 2 package format, the internal package manager will just keep track of their metadata and leave the loading and unloading to the existing resource handling code that Doomsday has been using in the v1.x series. This should ensure compatibility with existing resource packs going forward. I expect the real challenges await us down the road when it comes time to upgrade the resource handling code itself — Doomsday 2 packages introduce the concept of assets that is not present in the old code. The asset system provides the fundamental integration with Doomsday Script and the v2 file system.

During the past few days I’ve written up a detailed implementation plan for allowing Doomsday to understand old-style resource packs. The gist of it is to extend FS2 to recognize and understand the old data file formats (PK3/WAD/LMP, DED/DEH) as far as metadata is concerned, and represent them internally as Doomsday 2 packages. However, the load/unload operations will in practice be redirected to the v1 resource code. After this is working, the new Packages dialog can be extended with management of these old-style packages as well. Finally, one should be able to use the Packages dialog to select packages for specific available games in addition to the currently running session.

Work on the 3D model renderer continued on a closely related area. For certain special effects, it is very useful if models can supply their own customized shaders. However, the renderer currently loads all the shaders it can find during startup, and doesn’t support loading any additional shaders from the packages that the user later selects. The goal here is for the renderer to observe when packages are loaded or unloaded, and check them for shaders at that time. This approach will work equally well with any package, be it the net.dengine.client package or a package with a bunch of model assets.