On Week 32
skyjake:
During the past week I continued working on the multiplayer code. As we have switched to public testing, the progress of this work can be followed in the Public Multiplayer Testing thread in the News subforum. I won't go into specific details in this update, but rather try to provide a high-level view of the work.
It seems that there are still a couple of more serious flaws to be dealt with, particularly in the stability of the server and the client and the robustness of network communications. One of the biggest flaws currently is that the server is not doing anything to track the amount of data being sent to the client; if the connection bandwidth is for any reason insufficient, it will start clogging up. Complicating the matter is Doomsday's need for portability across the three major operating systems: Windows, Mac OS X and Linux. Whatever we use for communications, it has to work on all these OSes reliably and preferably with identical behavior. Our current low-level network library, SDL_net, does not even provide an interface for monitoring the status of the connection. Consequently, we may need to replace it with something better in order to reach acceptable levels of quality for robust multiplayer. I suspect that the biggest hurdle in switching away from SDL_net is updating our build system so the new dependencies are properly used and included in the distribution packages -- this should be a straightforward task, but when all the OSes need to be considered separately, it ends up being quite a lot of work.
Apart from that, the list of known issues is quite lengthy, so it will take a considerable amount of time to address each issue. Some of issues are small and easy to fix, but some may need a lot of investigation before the underlying cause reveals itself. As an example, I had to spend hours tracking down why water splashes aren't properly disappearing after their animation cycle is complete; as usual, the source of the bug was an obsolete, forgotten piece of code that should've been deleted long ago.
Overall, I am quite optimistic about the progress. The new way of working with the automatic unstable builds has proven quite effective during the past months, and it should eventually get us to a point where we have stable and well-behaving multiplayer in Doomsday. After that we can get to the fun stuff like implementing better chat and Game Rules for a more refined multiplayer experience.
danij:
I took some time today to compile a known issues/todo-list for the ringzero project.
This week I've been working on the management of WAD archives and the file resources they contain (lumps) in order to re-implement the IWAD recognition logic within the engine.
In previous versions of Doomsday the game load process worked as follows:
In addition to the WAD module work I also implemented some debugging tools to de::PathDirectory for analysing hash efficiency. This led to a simple optimization whereby nodes of the directory are split into separate hash lists by node type, speeding up searches significantly (e.g., when searching CVars ~65% of the directory is now immediately rejected).
The plan for next week is unchanged - continue addressing regressions and improving robustness of ringzero functionality.
During the past week I continued working on the multiplayer code. As we have switched to public testing, the progress of this work can be followed in the Public Multiplayer Testing thread in the News subforum. I won't go into specific details in this update, but rather try to provide a high-level view of the work.
It seems that there are still a couple of more serious flaws to be dealt with, particularly in the stability of the server and the client and the robustness of network communications. One of the biggest flaws currently is that the server is not doing anything to track the amount of data being sent to the client; if the connection bandwidth is for any reason insufficient, it will start clogging up. Complicating the matter is Doomsday's need for portability across the three major operating systems: Windows, Mac OS X and Linux. Whatever we use for communications, it has to work on all these OSes reliably and preferably with identical behavior. Our current low-level network library, SDL_net, does not even provide an interface for monitoring the status of the connection. Consequently, we may need to replace it with something better in order to reach acceptable levels of quality for robust multiplayer. I suspect that the biggest hurdle in switching away from SDL_net is updating our build system so the new dependencies are properly used and included in the distribution packages -- this should be a straightforward task, but when all the OSes need to be considered separately, it ends up being quite a lot of work.
Apart from that, the list of known issues is quite lengthy, so it will take a considerable amount of time to address each issue. Some of issues are small and easy to fix, but some may need a lot of investigation before the underlying cause reveals itself. As an example, I had to spend hours tracking down why water splashes aren't properly disappearing after their animation cycle is complete; as usual, the source of the bug was an obsolete, forgotten piece of code that should've been deleted long ago.
Overall, I am quite optimistic about the progress. The new way of working with the automatic unstable builds has proven quite effective during the past months, and it should eventually get us to a point where we have stable and well-behaving multiplayer in Doomsday. After that we can get to the fun stuff like implementing better chat and Game Rules for a more refined multiplayer experience.
danij:
I took some time today to compile a known issues/todo-list for the ringzero project.
This week I've been working on the management of WAD archives and the file resources they contain (lumps) in order to re-implement the IWAD recognition logic within the engine.
In previous versions of Doomsday the game load process worked as follows:
- User specifies path to an IWAD and the game component they wish to use, using the command line
- Engine selects the specified game component and initializes it
- Engine loads the specified IWAD
- Engine calls the game component to verify the current configuration (IWAD recognition and game type determination)
- User specifies all paths to all IWADs using either the command line or system/environment paths
- Game plugins are systematically loaded by the engine and each registers the game components playable by them, including the lists of required resources needed
- Engine processes the registered game component(s) and reconciles them with the available resources
- Engine determines which game components are playable (all resources found) and possibly autoselects a game for loading (either; a) explicitly specified by the user via command line or in-game console, b) deterministically from the available resources)
- Engine calls the game component associated with the chosen game and load begins
In addition to the WAD module work I also implemented some debugging tools to de::PathDirectory for analysing hash efficiency. This led to a simple optimization whereby nodes of the directory are split into separate hash lists by node type, speeding up searches significantly (e.g., when searching CVars ~65% of the directory is now immediately rejected).
The plan for next week is unchanged - continue addressing regressions and improving robustness of ringzero functionality.