This is the final installment of a short series of posts detailing what I’ve learned while exploring the possible directions that a redesigned Doomsday renderer could take. This post is about integrating the new renderer into the existing engine.
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.
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.
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.
To kick off the multiplayer improvements for version 2.1, I’ve started with adding access to data files over the network. For example, if a server is running a custom PWAD that you don’t have, the client will automatically download a copy before joining the game.
That pretty much sums it up for the user-facing portion of this feature. You will see a popup displaying download progress, and there is an option to cancel.
Much of this work was recently merged to the master branch (in the form of 83 commits) and is included now in unstable builds. Note that this kind of a larger influx of changes usually leads to new glitches also being introduced… I will be improving the code in the coming days/weeks.
Over the past few weeks, I’ve made a couple of stable builds with the version 2.0.3. The first one of those was made a bit early as I was about to leave for a trip abroad, and mainly included one bug fix for Hexen related to saving and restoring object state from save files. Recently I’ve made a couple of additional stable builds to investigate and fix a problem with the Ubuntu Launchpad build scripts, where the “doomsday-stable” packages were correctly built but nothing was actually included in the generated DEB packages.
On the whole, progress has been somewhat slow. Perhaps the biggest advance was in the dengine.net website backend, where I’ve now split the API functionality to a separate api.dengine.net server, so that things like master server and update queries won’t interfere with the normal operation of the project home page and forums. I hope this will alleviate the issue of dengine.net sometimes failing to respond to requests.
Prompted by a forum post, over the weekend I was investigating an audio volume issue on Windows. It turns out there is a problem with the SDL_mixer music volume controls. I have yet to determine if there is a workaround that Doomsday can do to avoid the issue. Such a workaround would be preferable to disabling SDL_mixer music on Windows completely, since SDL_mixer does bring value to the table (e.g., music formats). The situation is also slightly tricky because SDL and SDL_mixer are built in to the engine, so there isn’t a plugin to take out or something simple like that.
I’ve been getting back into the swing of things with a set of smaller changes and improvements. I haven’t yet started work on the major focus of the 2.1 release, which is planned to be Multiplayer improvements.
2.0.2 will be out on Saturday, July 1st, with a couple of bugfixes that I hope will be useful. As usual, I will post the details after the build is available.
The recent changes include:
- Stability improvements. Several methods that went against the C++ standard were revised. Reliance on undefined behavior was leading to compiler optimization issues particularly with the latest GCC 7. Also, error reporting is now more robust. For instance, previously when something went wrong during busy mode (like engine startup), it could easily lead to a crash because the client app wasn’t reacting to the situation appropriately. When the error message was being shown, the application was still trying to do something in the background.
- More powerful model scripting. Starting animations and timeline scripts via Doomsday Script.
- The model renderer shaders support more macros for easier customizability. Generally speaking, using macros is more future-proof than writing completely customized shaders.
- Resource identification fixes. There was a duplicate IWAD spec for Heretic 1.3 vs. SOSR. Now only the latter remains; if you have problems with your Heretic IWADs, Clear Cache and restart Doomsday. Also, autogenerated package IDs had a problem with special characters in file names. Doomsday will choose package IDs based on the file name of the data file, however it allowed spaces and quotes be included in the IDs. This lead to problems because whitespace characters are used as separators in lists of IDs, and quotes may not be accurately escaped in Info strings. Again, Clear Cache is recommended.
- Assimp build option. There’s a new CMake build option (
DENG_ASSIMP_EMBEDDED) for disabling the use of Doomsday’s customized version of Assimp. This allows one to configure Doomsday to use the Assimp installed as a system library, which is more common on Linux for instance.
- More UI tweaks. Plenty of small things:
- Minor dialog layout improvements to avoid awkward dimensions.
- Changed the UI font on Windows.
- Added popup outlines for visual clarity.
- Fixed Home tab scrolling with the mouse wheel so that it doesn’t always jump to the previously selected item when switching between tabs.
- Game icons are refreshed when package availability changes. No more missing and incorrect icons shown for game profiles.
- Fixed missing window fullscreen state notification (was affecting the appearance of the “Quit” button on Mac).
- Monitor refresh rate. Yesterday I started working on monitor refresh rate configuration options. I realized these have been completely missing from the settings for some time now. Doomsday does query the supported display modes, which includes information about refresh rates, so now you have the option of choosing which refresh rate Doomsday will prefer when switching modes on Windows/Linux (display mode changes are not done at all on macOS). However, I recommend you consider adjusting the game pixel density instead of the screen resolution to keep the UI sharp and crispy.
I’ve been taking it easy for the past couple of weeks, but last weekend I did manage to merge the recent OpenGL changes to the master branch. Build 2353 now includes this work. Please let me know if something appears broken!
There was a slight problem with the autobuilder, so the build change log is empty. GitHub has your back, though.
Here’s a rundown of the most important changes: Continue reading Notes about build 2353
I’ve spent the past couple of weeks experimenting with an iOS port of Doomsday. This is now at a proof-of-concept level and not playable yet. It isn’t quite the right time to continue much further along this path, but read on for my findings!
The stable version 2.0 has been out for a bit over two weeks now. I hope you’ve been enjoying it! I have been busy working on bug fixes for 2.0.1, which is soon getting into shape for release.
Now that the goals for the 2.0 release have been met, it is time to look ahead to version 2.1. The first point release is planned to primarily feature improvements for multiplayer games. I won’t be exclusively working on that, though, so various minor improvements will also be included. Small things like a persistent console command history and options to start a game profile in a chosen map are already available in the unstable 2.1 builds.
When it comes to the release schedule, it remains futile to speculate about how much time I will have for Doomsday in the future, but my hope is that point releases in the 2.x series will have a roughly six month cadence. While there is no specific release date set for 2.1, I am uncomfortable with the idea of more than 12 months between stable releases. If that much time passes I am willing to postpone the remaining work to a later point release and do a smaller stable release instead. I prefer that there is a steady and predictable flow of stable releases, much like the situation is with the unstable builds.
In any case, if you run unstable builds you will of course get all the latest improvements as soon as they are implemented.
- Bug fixes. Multiplayer gameplay is suffering from a variety of small glitches, particularly in Hexen. The goal here is to get rid of the more significant ones.
- Movement smoothing for enemies. Single-player games use movement smoothing for everything, so MP games should be no different.
- New chat UI. Modern games have some established conventions regarding in-game chat, so Doomsday should take inspiration from them. The chat should use Doomsday’s native UI widgets so the font isn’t blurry or too large, text can have colors and rich formatting, there is nice scrolling, text entry is more versatile, and there is autocompletion for usernames and commands. One particular direction this feature could take is integration with the console command prompt, so one can still issue console commands using IRC-like slash prefixes while primarily still chatting.
- New scoreboard UI. A better scoreboard would be a nice thing to have for competitive game types. There should also be an option for a small, always-on scoreboard HUD. I will likely end up with a toggle between completely hidden, small HUD, and full-size scoreboard modes.
- More GUI options for configuring game via Shell GUI. Most of the gameplay cvars should be configurable via the GUI. The 2.0 Shell already offers a couple of options (such as game type and current map), but there are more options that would be useful to have conveniently available. My strategy with regard to the Shell remains unchanged, though: for hosting games, the Shell should be the tool you use. Duplicating its features in the client GUI would be more or less redundant and wasted effort. However, I can look into integrating the Shell better with the client GUI, so it is quick and easy to get a local server started, for instance, by launching the Shell via the client.
- GUI for configuring map cycle. Map cycling is one important MP feature, especially for longer-running servers. By default, a co-op server will not restart the episode once it ends; map cycling should for instance allow configuring entire episodes to be played through and then restarted.
- Remote packages. The key feature here is loading PWADs from the server.
The internal objective for 2.1 is to complete or at least take a major step toward migrating the rest of the OpenGL code to version 3.3, making it also OpenGL ES 2 compatible. GLES is a requirement for Android and iOS, and also Raspberry Pi (a good low-powered testing/development platform). As a nice side-effect, this transition will also future-proof much of the code for subsequent migrations (particularly thinking about APIs like Vulkan, or some other low-level graphics API of the future). The crucial advantage that this transition will provide is support for GLSL shaders when rendering world surfaces. This truly opens up the potential for renderer improvements.
However, in the scope of 2.1, it must be noted that this will be an internal change, meaning the renderer features available to you remain roughly the same as in 2.0. Some older GPUs may no longer be supported, although it is also possible that some OpenGL drivers work better with OpenGL 3 instead of the old compatibility profile. It may also be necessary to drop some older graphics settings that are no longer relevant, if it isn’t feasible to reimplement them with new GL code.
Finally, please remember that plans may change so none of this is particularly set in stone. Stay tuned for updates. 🙂