Week 49/2012: Native functions, defaults, leaks, upsampling
skyjake's notes:
Last week I continued long-term work on libdeng2 a.k.a. the Doomsday 2 architecture. I also got started with bug fixing for 1.9.10.
Serialization is a core concept in libdeng2. It entails converting runtime objects to a series of bytes that can then be saved, copied, transferred over the network, and later restored into copies of the original runtime objects. While libdeng2 already applies serialization in many places, a crucial element has been missing. It is inevitable that the format of the serialized data changes over time as the system evolves, so there must be a graceful way to handle old formats, be they network traffic, savegames, maps, demos, or some other persistent data.
libdeng2 now has a built-in mechanism for versioning serialized data. The practical benefit is that all persistent data, such as the configuration variables saved into "persist.pack", will no longer be lost if the serialization format changes. The same mechanism can be applied to any data that libdeng2 deals with, bringing nice coherence into the design.
Another new feature that I am quite excited about is the ability to call native functions from Doomsday Script. So far the libdeng2 scripting facilities haven't had many ties to the engine itself, but this is slowly changing. I added the DisplayMode and Version modules that allow scripts to query information about the monitor display mode and the engine's version. With this knowledge, the configuration script (/modules/Config.de) can now determine the default configuration for the window manager.
In other news, we've now started the candidate phase for 1.9.10; to round out the year, our focus shifts temporarily to bug fixing and optimization.
I started my bug fixing efforts by correcting some issues with the window manager (centering the window), a song-stopping problem with the FluidSynth music player, and looking at issues related to log message output in libdeng2. It is noteworthy that the window manager now uses your desktop resolution as the default resolution when launching for the first time. (On Linux, the default is a maximized window.)
We also went through a couple of rounds of memory leak analysis and I did some performance optimizations after profiling engine startup. Both the memory and performance analyses will continue during the candidate phase.
One last thing: Doomsday has its own sound effect upsampler that converts audio samples to 2x or 4x the original sample rate. However, it uses naive linear interpolation to do this, which does not preserve the shape of the original audio waveforms. This is why the samples sound "crisper" after having been upsampled by Doomsday. When using FMOD, which does proper resampling on its own, Doomsday will no longer mess with the samples but instead provide them as-is to FMOD, yielding improved (or at least less distorted) audio quality.
This week my plan is to continue with bug fixing and polishing in preparation for the 1.9.10 release.
Last week I continued long-term work on libdeng2 a.k.a. the Doomsday 2 architecture. I also got started with bug fixing for 1.9.10.
Serialization is a core concept in libdeng2. It entails converting runtime objects to a series of bytes that can then be saved, copied, transferred over the network, and later restored into copies of the original runtime objects. While libdeng2 already applies serialization in many places, a crucial element has been missing. It is inevitable that the format of the serialized data changes over time as the system evolves, so there must be a graceful way to handle old formats, be they network traffic, savegames, maps, demos, or some other persistent data.
libdeng2 now has a built-in mechanism for versioning serialized data. The practical benefit is that all persistent data, such as the configuration variables saved into "persist.pack", will no longer be lost if the serialization format changes. The same mechanism can be applied to any data that libdeng2 deals with, bringing nice coherence into the design.
Another new feature that I am quite excited about is the ability to call native functions from Doomsday Script. So far the libdeng2 scripting facilities haven't had many ties to the engine itself, but this is slowly changing. I added the DisplayMode and Version modules that allow scripts to query information about the monitor display mode and the engine's version. With this knowledge, the configuration script (/modules/Config.de) can now determine the default configuration for the window manager.
In other news, we've now started the candidate phase for 1.9.10; to round out the year, our focus shifts temporarily to bug fixing and optimization.
I started my bug fixing efforts by correcting some issues with the window manager (centering the window), a song-stopping problem with the FluidSynth music player, and looking at issues related to log message output in libdeng2. It is noteworthy that the window manager now uses your desktop resolution as the default resolution when launching for the first time. (On Linux, the default is a maximized window.)
We also went through a couple of rounds of memory leak analysis and I did some performance optimizations after profiling engine startup. Both the memory and performance analyses will continue during the candidate phase.
One last thing: Doomsday has its own sound effect upsampler that converts audio samples to 2x or 4x the original sample rate. However, it uses naive linear interpolation to do this, which does not preserve the shape of the original audio waveforms. This is why the samples sound "crisper" after having been upsampled by Doomsday. When using FMOD, which does proper resampling on its own, Doomsday will no longer mess with the samples but instead provide them as-is to FMOD, yielding improved (or at least less distorted) audio quality.
This week my plan is to continue with bug fixing and polishing in preparation for the 1.9.10 release.