During the first two weeks of 2014 we have been fixing up bugs in the 1.13 release and kicking off some new development tasks.
One issue with 1.13
is with NVIDIA's special coverage-sampled antialiasing mode
. This can be forced on the NVIDIA driver settings, which Doomsday was not prepared for. Fortunately, we found the source of the issue
and Doomsday will be able to take advantage of NVIDIA's CSAA antialiasing if it is supported by the driver.
Later this week we plan to release a second patch (1.13.2
) with the CSAA fix plus a few more minor UI improvements.
With 1.13 out of the way, we can start shifting our focus to entirely new tasks for 1.14. Before continuing with the multiplayer UI and new lens flares, I've decided to start my work for 1.14 with code base cleanup.
I've split off the client's new UI framework into its own library, as it has grown already rather large in size. The new library is called "libappfw", and will appear as deng_appfw.dll
in the installation. Going forward, we might split off further functionality into separate modules in this manner to maintain proper decoupling and cleanliness in the code base.
The above diagram shows the sizes of each of the components in the project. The first observation is that we haven't even begun to properly separately the client and server: most of the code remains in the client, and is simply shared between the client and server executables. The new libappfw clocks in as the second biggest supporting library. It is interesting to see that libdeng2, the core of the Doomsday 2 written from scratch according to the new 2.0 architecture, is almost as big as the shared portion of the game plugins (plugins/common). However, the individual game plugins still have some redundant parts that could be generalized and migrated to plugins/common.
I've also continued improving the client UI with a couple of new tools that should be particularly helpful for power users and developers. The first new addition is an alert notification mechanism:
This draws your attention to the problems that Doomsday has noticed without forcing you to dig through the log for the warning/error messages. The alerts have already highlighted some lingering issues and misbehavior in the engine that needs addressing.
However, for this to have the maximum benefit, it is necessary to also clean up the log messages so that only the relevant ones are shown and/or warned about. I've added a new filtering tool that allows one to select the level of verbosity and type of messages for each subsystem. For advanced users interested in a particular topic (like resource pack maintenance or creating new maps), this should be a useful tool for getting the maximum information about the interesting subsystems without the deluge of spam from everything else. The new filtering also separates developer-targeted messages from usage-related messages, which brings additional clarity to the log history.
The hardest part is that we'll need to go through all the places where log messages are printed and update them with the appropriate metadata so that the filtering can work correctly. This is a big, arduous task but it will pay off in the long run.