Doomsday 2.1 released

Doomsday 2.1 has been released (build 2900), coinciding with the 25th anniversary of DOOM!

This version contains several improvements for an all-around nicer experience:

  • Graphics optimization. While games still use the classic renderer like in 2.0, all graphics are now drawn using OpenGL 3.3. This enables optimizations for more efficient rendering of the player view, menus, text, and the Doomsday UI.

  • UI improvements. The Doomsday UI look and feel has been refreshed. The game library is now more flexible and powerful with further game customization settings and view options.

  • Multiplayer convenience. Clients will automatically download missing PWADs from the server before joining the game.

Download 2.1

Release notes

Doomsday 2.1 RC3

The third and possibly final release candidate of 2.1 is now available (build 2898).

This build comes with a couple of Windows-related updates: the Qt library has been upgraded, and the 32-bit Windows build now has a fully functional FluidSynth audio plugin. This has been available in the 64-bit build for a while.

Unless any showstoppers are discovered, the next build will be the stable 2.1.0.

Doomsday 2.1 RC2

2.1 RC2 was released today (build 2895).

The issues discovered in RC1 were fixed but a couple of new ones were found. If you download RC2, please note the following:

  • MIDI sound font cannot be changed via the audio settings GUI. One can still change the sound font manually via the “music-soundfont” cvar, though.
  • A resource error occurs during the Ultimate Doom (BFG Edition) title sequence.
  • Some data files are inadvertently tagged as “hexen” (thanks to deus-ex for researching this!).
  • Data file version numbers are not always parsed from the file name.

In addition to these, there is an older issue that the 32-bit Windows build does not support FluidSynth for music. This will be addressed before the next build.

Doomsday 2.1 RC1

2.1 RC1 is now available (build 2890).

I’ve listed many of the changes in the previous post. Since writing that I’ve been optimizing rendering performance. You should find the engine running a bit snappier now.

However, there are a couple of known issues in this build:

  • Weapon switching keys are cycling weapons instead of switching to a particular weapon.
  • There are warnings about random “renderer.pack” issues.
  • Readme has not been updated with any of the new features, and some of the links are obsolete.

Let me know if you find any other issues. RC2 will be available once these are fixed.

What’s new in 2.1

Version 2.1 is now feature complete. While I originally hoped to focus on multiplayer-related enhancements in this release, it turned out a little differently. Roughly speaking the first half of 2018 was spent working on the foundations of the next revision of the renderer (not included in 2.1), and only during the second half I focused on 2.1 related work.

One important multiplayer improvement has been added for 2.1, though: clients can download mods (e.g., PWADs) from the server in case they are needed for joining a multiplayer game.

The stable 2.1.0 will be released before the end of the year. I intend to spend the remaining time on fixing bugs (some already listed in the roadmap).

Let’s have a quick look at the changes done over the past weeks.

Continue reading What’s new in 2.1

Further rendering explorations – Part 2

During the spring I’ve been exploring the possibilities and potential directions that a completely redesigned renderer could take. Continuing from part one, this post contains more of the results and related thoughts about where things could and should be heading.

Continue reading Further rendering explorations – Part 2

Further rendering explorations – Part 1

When it comes to graphics, things sure have changed since the beginning of the project. Back in the day — almost 20 (!) years ago — GPUs were relatively slow, you had a few MBs of VRAM, and screen resolutions were in the 1K range. Nowadays most of these metrics have grown by an order of magnitude or two and the optimal way of using the GPU has changed. While CPUs have gotten significantly faster over the years, GPU performance has dramatically increased in vast leaps and bounds. Today, a renderer needs to be designed around feeding the GPU and allowing it do its thing as independently as possible.

With so much computation power available, rendering techniques and algorithms are allowed to be much more complex. However, Doomsday’s needs are pretty specific — what is the correct approach to take here? During the spring I’ve been exploring the possibilities and potential directions that a completely redesigned renderer could take. In this post, I’ll share some of the results and related thoughts about where things could and should be heading.

Continue reading Further rendering explorations – Part 1

Status update

The spring months have been a little crazy with various Real Life time sinks preventing me from delving too deep into fun coding. Consequently, there has been little to no progress with the tasks on the roadmap, such as the multiplayer improvements for version 2.1. Given that several months have passed, it will be challenging to find motivation to restart this work. I am tempted to make some changes to the roadmap to get things rolling along again.

I have managed to steal away some time to explore an exciting new direction for the renderer, though. The basic gist of this effort is to completely revise how the game world is drawn, bringing it up to par with the recently redone 3D model renderer.

Continue reading Status update