Week 2/2013: Map data upgrade begins
skyjake's notes:
Last week we started a big refactoring task related to map data. When discussing future plans with danij, it became clear that a large obstacle for moving forward is that the runtime map data is still stored in data structures implemented in C. This makes them inflexible and rather cumbersome to work with. So, we started a new work branch called "mapdata-c++" where the goal is to upgrade the internal map data structures to C++ classes.
For some time now, the engine sources have comprised both C and C++ source files. However, with runtime map data moving the C++ classes, it necessitates switching nearly all of the engine's source files to C++. This is a welcome (albeit rather laborious) change as it further enables the use of libdeng2 internally and gives us more powerful building blocks.
"mapdata-c++" will be fairly large as work branches go, because map data is perhaps the most integral data in the engine and the changes radiate to practically all parts of the engine. Luckily, the plugins are mostly shielded from changes because in the past we've been isolating the engine's internals from the plugin/game code.
I also spent a few moments preparing the next step of setting up the separate Doomsday Server executable. Because the server is an invisible background process, it needs a user interface so one can control it. I have chosen to make it possible to have multiple different UIs, because the server needs to be controlled via the Client (when running local games), the command line (e.g., a headless Unix server), and a separate GUI app (hosting a private dedicated server on Windows or Mac without participating in the game). Therefore, I added a new shared library called libshell that will contain functionality for starting, stopping, monitoring, and manipulating server processes. libshell will then be used in various executables, including the Doomsday Client, for controlling the local (or remote) server processes.
This week I will focus on the mapdata-c++ refactoring. I would like to finish this work as soon as possible so that I can move on to revising Doomsday's GUI framework.
danij's notes:
Last week also saw the beginnings of a smaller work branch called "revise-texture-animation", where I am tackling the refactorings I laid out in my dev blog post for Week 1/2013.
This work has progressed quite swiftly thus far. id Tech 1 texture/flat animations are now modelled using the material layer stages mechanic I first introduced for Doomsday 1.9.0-beta6 and the older frame (group) based method has since been removed.
With the animations now modelled within materials, it meant that the next significant step could be taken; context-specific animation states. For a while now Doomsday has featured a mechanism which allowed multiple usage-context specialised versions of a material to exist in parallel. However their animation was still done centrally with all context variants sharing the same animation state. This shortcoming has now been addressed and each usage context is now animated independently. For example, this means that if a material is in simultaneous use in both the game world and the UI (such as the console background), that the UI version will continue to animate even though the game itself is paused.
Another repercussion of the change in animation mechanism is the management of light decorations. These are similarly now modelled at material level with their own stage based animation mechanism (which works independently from layer stages and allowing each decoration to be animated with it's own timings). Light decoration animations are also now interpolated.
There is still some work to do before this branch can be merged back to the master. The so-called "smooth texture animation" feature needs to be reimplemented and new logic is needed for backward compatibility with mods using the older animation method. However I hope to have it completed this week.
Last week we started a big refactoring task related to map data. When discussing future plans with danij, it became clear that a large obstacle for moving forward is that the runtime map data is still stored in data structures implemented in C. This makes them inflexible and rather cumbersome to work with. So, we started a new work branch called "mapdata-c++" where the goal is to upgrade the internal map data structures to C++ classes.
For some time now, the engine sources have comprised both C and C++ source files. However, with runtime map data moving the C++ classes, it necessitates switching nearly all of the engine's source files to C++. This is a welcome (albeit rather laborious) change as it further enables the use of libdeng2 internally and gives us more powerful building blocks.
"mapdata-c++" will be fairly large as work branches go, because map data is perhaps the most integral data in the engine and the changes radiate to practically all parts of the engine. Luckily, the plugins are mostly shielded from changes because in the past we've been isolating the engine's internals from the plugin/game code.
I also spent a few moments preparing the next step of setting up the separate Doomsday Server executable. Because the server is an invisible background process, it needs a user interface so one can control it. I have chosen to make it possible to have multiple different UIs, because the server needs to be controlled via the Client (when running local games), the command line (e.g., a headless Unix server), and a separate GUI app (hosting a private dedicated server on Windows or Mac without participating in the game). Therefore, I added a new shared library called libshell that will contain functionality for starting, stopping, monitoring, and manipulating server processes. libshell will then be used in various executables, including the Doomsday Client, for controlling the local (or remote) server processes.
This week I will focus on the mapdata-c++ refactoring. I would like to finish this work as soon as possible so that I can move on to revising Doomsday's GUI framework.
danij's notes:
Last week also saw the beginnings of a smaller work branch called "revise-texture-animation", where I am tackling the refactorings I laid out in my dev blog post for Week 1/2013.
This work has progressed quite swiftly thus far. id Tech 1 texture/flat animations are now modelled using the material layer stages mechanic I first introduced for Doomsday 1.9.0-beta6 and the older frame (group) based method has since been removed.
With the animations now modelled within materials, it meant that the next significant step could be taken; context-specific animation states. For a while now Doomsday has featured a mechanism which allowed multiple usage-context specialised versions of a material to exist in parallel. However their animation was still done centrally with all context variants sharing the same animation state. This shortcoming has now been addressed and each usage context is now animated independently. For example, this means that if a material is in simultaneous use in both the game world and the UI (such as the console background), that the UI version will continue to animate even though the game itself is paused.
Another repercussion of the change in animation mechanism is the management of light decorations. These are similarly now modelled at material level with their own stage based animation mechanism (which works independently from layer stages and allowing each decoration to be animated with it's own timings). Light decoration animations are also now interpolated.
There is still some work to do before this branch can be merged back to the master. The so-called "smooth texture animation" feature needs to be reimplemented and new logic is needed for backward compatibility with mods using the older animation method. However I hope to have it completed this week.
Comments
Text {
ID = "RENDER_GLOWFLATS";
Text = "LAVA1 LAVA2 LAVA3 LAVA4 NUKAGE1 NUKAGE2 NUKAGE3\_
FWATER1 FWATER2 FWATER3 FWATER4";
}
Text {
ID = "RENDER_GLOWTEXTURES";
Text = "FIREBLU1 FIREBLU2 FIRELAVA FIRELAV2 FIRELAV3 FIREMAG1\_
FIREMAG2 FIREMAG3 FIREWALL FIREWALA FIREWALB";
}
I'm raising this because I'm sure Deng team would like either full backward compat or no backward compat and this def type seems to have been forgotten (it was cut way back in the early 1.9 betas). Half backward compat seems pointless.
These def's allowed one to make a texture or flat full bright and a glow was automatically added to any flats (there were no variables a modder could change). I don't actually think this def type was even documented in the 1.8 days and was strangely in with and uses the text string def headers.
Please submit a bug report about RENDER_GLOWTEXTURES/FLATS. It won't have a very high priority, but we might for instance implement a way to take the contents of any text definition and apply the glow property for the named materials (in the future this could be done with a script, say).