I just pushed 1036 commits to the master branch. This switches it over to Doomsday 3.
Doomsday 3 in its current form is still quite unfinished and broken in many places. Especially the new renderer remains disabled by default, and cannot be enabled without recompiling. However, the basic things are running, and they’re running fast!
Even the classic renderer has gotten a boost. Although to be fair, it still has the same old bottlenecks as before. The difference is that the application event loop has been optimized, which raises the FPS ceiling even though the floor remains largely the same. On average, the game should be running more smoothly.
Continue reading The Switchover
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.
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
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
There has been quite a bit of progress during the past two weeks, in the areas of Home/UI, frameworks and resources, and general optimizations. Continue reading 2000+
Last week I got back to working on Doomsday after taking an extended break (that featured large quantities of Uncharted). I took significant steps forward in supporting the Snowberry resource pack formats, made further UI improvements, and applied various performance optimizations.
The changes described below are available in today’s build 1983. Continue reading Speeding up