Week 2/2014: Log filtering, alerts, code base cleanup
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 or libdeng_appfw.so 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.
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 or libdeng_appfw.so 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.
Comments
My assumption is that it's another sort of verbosity; in which case, why isn't it simply the top level verbosity option in the left column, which looks like a 0-5 verbosity setting?
May I ask if Dday will have an option to filter the different message types to different out files in future? I figure that would have much the same benefits as the log system filters in game.
Although I suppose doing that could also confuse users, as they would have to search through multiple out files to find the one that relates to a crash or problem they are having/had.
We are now making a conscious choice to target log messages to either end-users or developers. The biggest difference is that the former relates to the use of the engine and the game, while the developer messages relate to programming. The idea naturally is that end-users won't get much out of developer messages, and that is why they are disabled by default.
The Dev messages are not an additional verbosity level; they can use the full verbositry range in parallel to normal messages.
That would be doable, however it would mean one can't see the interplay between subsystems and dev/non-dev stuff...
Mouse wheel scrolling seems to be the only way to move them, but I figure that not every user will have a mouse with a wheel, where as every mouse in existence, naturally, has a button.
I would like to raise the possibility of the log having some sort of separator/divider graphic for when one switches game or loads new resources?
Currently, if one switches from say, Heretic to HacX, there is no indication in the log where Heretic error logging ended and where HacX error logging begins. I suppose what I mean is there currently isn't a way to tell where resource based errors came from (i.e which ded, wad etc). But obviously, I understand that the system is still in the early stages and hence is probably not fully featured yet, that the log may well have been planned to include such information in future iterations.
I would also like to raise the possibility of all the Dday text defs being updated to include every Vanilla text def regardless of whether Dday uses them; HacX's Dehacked file includes seemingly every single Vanilla text def, but because they aren't written in the Dday text defs, Dday spits out a bunch of errors.
I figure having all the Vanilla text defs in the Dday text defs regardless of whether Dday uses them, would be better than say disabling checking on HacX's Dehacked file entirely. It would also remove all but one of the errors the HacX Iwad throws up during loading, the one remaining error being that Dday, like other ports, deliberately doesn't support Dehacked's ability to remap cheat codes.