Week 1/2013: Separate server, new public API mechanism
skyjake's notes:
Last week I got back to work on Doomsday after a brief holiday break. It was quite a productive week.
Doomsday 1.9.10-1 was released. With any luck this is the final release in the 1.9 series, as we're switching to a new minor version for the next stable release.
I've been working on a bigger work branch called "separate-server." The idea is to split the server off out of the main Doomsday executable into its own, smaller executable that does not have dependencies to any graphics, audio, or input code. The new executable will be called doomsday-server. In the next release (1.10), it will be used for hosting multiplayer games instead of the main executable. In the beginning it is merely a copy of the main executable with certain functionality omitted. Ultimately doomsday-server will be a background daemon that is controlled via a shell connection, command line tool, or a GUI/text mode frontend of some kind. It will take some time to cull away all the unnecessary code for a server build, though. This is a very exciting first step toward the unified networking goal that will fully separate the server and the client from each other.
As I was setting up doomsday-server it became clear that the way symbols are exported out of Doomsday is not going to work any more. For a long time, Doomsday has been using the practice of exporting certain functions from the main executable so that plugins may call them. There are a few problems with this:
Therefore it was necessary to revise the engine's public API mechanism. Instead of exporting symbols, the engine will now provide the plugins with a collection of structs containing function pointers. This gives us full control over the engine's ABI with support for modularity and versioning; a big improvement all around.
The work on doomsday-server now continues as part of the master branch, with gradual improvements and removal of unnecessary functionality. My next big task is to start work on the next-generation scriptable UI controls.
danij's notes:
After a nice break from Doomsday over Christmas, last week I got back into the swing of things with some much needed material system cleanup.
Last week I spent time on improving the material subsystem, which now employs a similar high level design to the texture resource collection (which itself is inspired by the libdeng2 file system).
During the development of Doomsday 1.9.10 some uncomfortable truths came to light about the exact behavior of id Tech 1's somewhat esoteric software renderer column drawer. Specifically regarding how texture geometry is calculated & interpreted and that two textures with the same name in the same resource scheme may well be in use at the same time. Addressing the issues these raise should be done for the 1.10 release, as these have implications for the construction of renderable map geometry (and by extension the new map renderer, when we get to that).
The first job I'm focusing on for the 1.10 release is a rethink of the way id Tech 1 flat and texture animations are interpreted so as to address the "flashing BLOODFALL" issue (as seen in mods like Plutonia 2). Essentially this means redefining the animations using material's layer stage animation rather than as a sequence of material "frames". Once this has been achieved, work can then begin on addressing the "uncomfortable truths".
Last week I got back to work on Doomsday after a brief holiday break. It was quite a productive week.
Doomsday 1.9.10-1 was released. With any luck this is the final release in the 1.9 series, as we're switching to a new minor version for the next stable release.
I've been working on a bigger work branch called "separate-server." The idea is to split the server off out of the main Doomsday executable into its own, smaller executable that does not have dependencies to any graphics, audio, or input code. The new executable will be called doomsday-server. In the next release (1.10), it will be used for hosting multiplayer games instead of the main executable. In the beginning it is merely a copy of the main executable with certain functionality omitted. Ultimately doomsday-server will be a background daemon that is controlled via a shell connection, command line tool, or a GUI/text mode frontend of some kind. It will take some time to cull away all the unnecessary code for a server build, though. This is a very exciting first step toward the unified networking goal that will fully separate the server and the client from each other.
As I was setting up doomsday-server it became clear that the way symbols are exported out of Doomsday is not going to work any more. For a long time, Doomsday has been using the practice of exporting certain functions from the main executable so that plugins may call them. There are a few problems with this:
- On Unix platforms, it requires the "-rdynamic" linker option that allows dynamic linking to occur from shared libraries to the binary loading the library. This may cause unexpected problems as global symbols present in the engine may be confused with symbols in shared libraries; a situation that would normally never occur as the symbols of different binaries are, by default, kept separate from each other.
- On Windows, a static library (e.g., doomsday.lib) is generated containing the locations of the exported symbols. A plugin is linked against this library to allow it to call the functions in the engine. However, if another executable (say, doomsday-server.exe) loads the plugin, the locations of the exported symbols are different than in doomsday.exe, causing a crash if the functions are called.
- Doomsday and doomsday-server export a different set of symbols, because the server build lacks certain subsystems (like the renderer).
Therefore it was necessary to revise the engine's public API mechanism. Instead of exporting symbols, the engine will now provide the plugins with a collection of structs containing function pointers. This gives us full control over the engine's ABI with support for modularity and versioning; a big improvement all around.
The work on doomsday-server now continues as part of the master branch, with gradual improvements and removal of unnecessary functionality. My next big task is to start work on the next-generation scriptable UI controls.
danij's notes:
After a nice break from Doomsday over Christmas, last week I got back into the swing of things with some much needed material system cleanup.
Last week I spent time on improving the material subsystem, which now employs a similar high level design to the texture resource collection (which itself is inspired by the libdeng2 file system).
During the development of Doomsday 1.9.10 some uncomfortable truths came to light about the exact behavior of id Tech 1's somewhat esoteric software renderer column drawer. Specifically regarding how texture geometry is calculated & interpreted and that two textures with the same name in the same resource scheme may well be in use at the same time. Addressing the issues these raise should be done for the 1.10 release, as these have implications for the construction of renderable map geometry (and by extension the new map renderer, when we get to that).
The first job I'm focusing on for the 1.10 release is a rethink of the way id Tech 1 flat and texture animations are interpreted so as to address the "flashing BLOODFALL" issue (as seen in mods like Plutonia 2). Essentially this means redefining the animations using material's layer stage animation rather than as a sequence of material "frames". Once this has been achieved, work can then begin on addressing the "uncomfortable truths".