On Week 2/2012
skyjake:
Last week I was working on improvements to multiplayer code and API documentation.
On the multiplayer side, I fixed the problem where players would get stuck inside monsters in co-op games, and started improving robustness when it comes to possible variations in loaded resources. The server now sends a listing of the known materials so that the client knows which ones to apply e.g., when a switch is pressed. Previously it was possible that the client chose the wrong texture. While this is a good step forward, there are other indices that need similar treatment: mobj states and types. Currently the server just sends an index of the state/type, but if the client has loaded resource packs that alter the definitions, the indices may no longer match.
Another multiplayer issue that I fixed was Hexen's Bishop missiles. The Bishops fire many missiles in rapid succession, which was not always faithfully reproduced on the client. More importantly, as the missiles were following an unpredictable swirling/seeking path, they required lots of delta updates to be sent, clogging the network connection. Now the missiles are spawned locally on the clients, saving network bandwidth. However, the client-side missiles are only a visual effect; actual damage is dealt on the server.
Even though we have for a long time tried to position Doomsday Engine as a general-purpose engine on which new game plugins could be developed, in reality such efforts have not been easy. Last week we took a step toward improving the situation by setting up official documentation for the public API. However, presently the state of the documentation is rather rudimentary; we especially need to add more overviews of how the different parts tie together, what is expected of game plugins, and other such information. The documentation will be improved over time.
The Candidate phase continues, so this week I am first going to address the mobj state/type index issue and then move on to other important items on our todo list.
danij:
Last week I spent working on resolving the remaining issues with resource loading and preparing dengine.net's source for inclusion into our repository.
Loading of addons from the command line using the -file argument was fixed. This was the result of differing logic between classes of resource in the engine's resource locator. Previous releases of Doomsday used an alternate logic for locating textures which limited the files found on a given search path to only those within the root of the target directory. I addressed this by implementing new functionality allowing search logic to be specified for each search path, allowing both logics to be used for any class of resource in any namespace.
Model resource pack loading was also fixed, due to a load ordering issue in the games which failed to provide the engine with the PLAYPAL palette it needed in order to prepare sprites (which are loaded for the purpose of scaling models to the dimensions of their sprite counterpart).
The other main issue I addressed was the performance of addon loading, which should now be significantly faster as of today's build 381. This was actually rather a complex fix because of various logic dependencies and interconnections in the file system. Those issues have now all been resolved, however the handling of lump assemblys as directories in the local file system had to be sacrificed in the process (they still work as before when used in Zips). Support for lump assemblies in the local file system will be re-implemented once I've determined how they should be handled.
In addition to the above I also fixed various issues with the interpretation of texture resources, such as 32bit color fonts appearing garbled in the game menu.
As most of the resource loading issues have been resolved, its time to move on to other things. I first intend to address the Archvile crash in Doom. After which I'll make a clean up pass over the more minor issues, like the alignments of menu items.
Last week I was working on improvements to multiplayer code and API documentation.
On the multiplayer side, I fixed the problem where players would get stuck inside monsters in co-op games, and started improving robustness when it comes to possible variations in loaded resources. The server now sends a listing of the known materials so that the client knows which ones to apply e.g., when a switch is pressed. Previously it was possible that the client chose the wrong texture. While this is a good step forward, there are other indices that need similar treatment: mobj states and types. Currently the server just sends an index of the state/type, but if the client has loaded resource packs that alter the definitions, the indices may no longer match.
Another multiplayer issue that I fixed was Hexen's Bishop missiles. The Bishops fire many missiles in rapid succession, which was not always faithfully reproduced on the client. More importantly, as the missiles were following an unpredictable swirling/seeking path, they required lots of delta updates to be sent, clogging the network connection. Now the missiles are spawned locally on the clients, saving network bandwidth. However, the client-side missiles are only a visual effect; actual damage is dealt on the server.
Even though we have for a long time tried to position Doomsday Engine as a general-purpose engine on which new game plugins could be developed, in reality such efforts have not been easy. Last week we took a step toward improving the situation by setting up official documentation for the public API. However, presently the state of the documentation is rather rudimentary; we especially need to add more overviews of how the different parts tie together, what is expected of game plugins, and other such information. The documentation will be improved over time.
The Candidate phase continues, so this week I am first going to address the mobj state/type index issue and then move on to other important items on our todo list.
danij:
Last week I spent working on resolving the remaining issues with resource loading and preparing dengine.net's source for inclusion into our repository.
Loading of addons from the command line using the -file argument was fixed. This was the result of differing logic between classes of resource in the engine's resource locator. Previous releases of Doomsday used an alternate logic for locating textures which limited the files found on a given search path to only those within the root of the target directory. I addressed this by implementing new functionality allowing search logic to be specified for each search path, allowing both logics to be used for any class of resource in any namespace.
Model resource pack loading was also fixed, due to a load ordering issue in the games which failed to provide the engine with the PLAYPAL palette it needed in order to prepare sprites (which are loaded for the purpose of scaling models to the dimensions of their sprite counterpart).
The other main issue I addressed was the performance of addon loading, which should now be significantly faster as of today's build 381. This was actually rather a complex fix because of various logic dependencies and interconnections in the file system. Those issues have now all been resolved, however the handling of lump assemblys as directories in the local file system had to be sacrificed in the process (they still work as before when used in Zips). Support for lump assemblies in the local file system will be re-implemented once I've determined how they should be handled.
In addition to the above I also fixed various issues with the interpretation of texture resources, such as 32bit color fonts appearing garbled in the game menu.
As most of the resource loading issues have been resolved, its time to move on to other things. I first intend to address the Archvile crash in Doom. After which I'll make a clean up pass over the more minor issues, like the alignments of menu items.