On Week 15
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Blog.</i>
<strong>skyjake</strong>:
<ul><li>During week 15 I had the good fortune of spending plenty of time on Doomsday, particularly on continuing the multiplayer fixes. Refactoring the client mobjs turned out to be a good call, as it removed a major obstacle in getting the clientside to use the game plugin's logic for controlling engine-created objects. The state of the objects is now more accurately and completely synchronized from the server to the clients. Another important glitch that was fixed was in weapon changing, where the serverside player instance was forcing a weapon change when a client joined the game. Also, the client is now locally spawning objects whose definition includes the <tt>local</tt> flag, as the server is excluding these from the normal state deltas.</li>
<li>I started work on fixing tick smoothing for the client, which includes purging the old mobj handling code from the engine: this code was originally duplicated from gameside code and includes not-quite-correct versions of mobj movement, collision checking, and plane height checks. I intend to make the engine rely on gameside logic when it needs to invoke this kind of functionality (which shouldn't be that often, in fact). All in all, the fact that all mobjs, be they normal or clientside, are now compatible with each other makes life significantly easier.</li>
<li>My plan for the coming week is to continue with the multiplayer. In particular I will focus on completing the mobj handling issues, which are currently preventing the player from picking up any items. After that, it might be time to take a closer look at what is messing up the sync on tick smoothing.</li></ul>
<strong>danij</strong>:
<ul>
<li>As predicted my available time for deng was somewhat limited this past week. Consequently I opted to spend it on quantifiable tasks such as optimization of the <tt>FileDirectory</tt> in ringzero. Previously this was a special-case data structure used only for representing paths on the local file system. The file directory is now implemented by wrapping <tt>PathDirectory</tt>, which is a generalization of the hierarchical path data structure formerly implemented in the file directory itself. The optimization work was rather successful with engine startup time reduced substantially through the introduction of path hashing and path fragment name interning schemes. This now presents us with a general data structure that can be utilized in other places. One potential use that springs immediately to mind is the console variable directory, which if implemented using <tt>PathDirectory</tt> would significantly reduce the storage needed to represent the two hundred or so variables presently registered.</li>
<li>I also tackled the forum registration problems which turned out to be a relatively simple matter of updating our forum-style. Registration should now be working once again.</li>
<li>The coming week is looking rather better as far as deng development time is concerned. My current plan is to get back to finishing the work on the materials and textures subsystems, in particular the conclusion of the recently added specification abstractions. This work is designed to address a prominent bottleneck in the world render which was introduced at the time the materials subsystem was first implemented.</li>
</ul>
<strong>skyjake</strong>:
<ul><li>During week 15 I had the good fortune of spending plenty of time on Doomsday, particularly on continuing the multiplayer fixes. Refactoring the client mobjs turned out to be a good call, as it removed a major obstacle in getting the clientside to use the game plugin's logic for controlling engine-created objects. The state of the objects is now more accurately and completely synchronized from the server to the clients. Another important glitch that was fixed was in weapon changing, where the serverside player instance was forcing a weapon change when a client joined the game. Also, the client is now locally spawning objects whose definition includes the <tt>local</tt> flag, as the server is excluding these from the normal state deltas.</li>
<li>I started work on fixing tick smoothing for the client, which includes purging the old mobj handling code from the engine: this code was originally duplicated from gameside code and includes not-quite-correct versions of mobj movement, collision checking, and plane height checks. I intend to make the engine rely on gameside logic when it needs to invoke this kind of functionality (which shouldn't be that often, in fact). All in all, the fact that all mobjs, be they normal or clientside, are now compatible with each other makes life significantly easier.</li>
<li>My plan for the coming week is to continue with the multiplayer. In particular I will focus on completing the mobj handling issues, which are currently preventing the player from picking up any items. After that, it might be time to take a closer look at what is messing up the sync on tick smoothing.</li></ul>
<strong>danij</strong>:
<ul>
<li>As predicted my available time for deng was somewhat limited this past week. Consequently I opted to spend it on quantifiable tasks such as optimization of the <tt>FileDirectory</tt> in ringzero. Previously this was a special-case data structure used only for representing paths on the local file system. The file directory is now implemented by wrapping <tt>PathDirectory</tt>, which is a generalization of the hierarchical path data structure formerly implemented in the file directory itself. The optimization work was rather successful with engine startup time reduced substantially through the introduction of path hashing and path fragment name interning schemes. This now presents us with a general data structure that can be utilized in other places. One potential use that springs immediately to mind is the console variable directory, which if implemented using <tt>PathDirectory</tt> would significantly reduce the storage needed to represent the two hundred or so variables presently registered.</li>
<li>I also tackled the forum registration problems which turned out to be a relatively simple matter of updating our forum-style. Registration should now be working once again.</li>
<li>The coming week is looking rather better as far as deng development time is concerned. My current plan is to get back to finishing the work on the materials and textures subsystems, in particular the conclusion of the recently added specification abstractions. This work is designed to address a prominent bottleneck in the world render which was introduced at the time the materials subsystem was first implemented.</li>
</ul>