On Week 14
<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>Most of my time was spent on Amethyst and a filter for outputting Unix manual pages. I am happy to say that I got it working quite nicely, so that for the next stable release we will be able to have a proper Unix manual page for Doomsday. As to its content, I think it will be a description of the most important command line arguments plus the portions of the old readme that haven't become obsolete. I also got halfway through writing a filter for .RTF, so we can have a revised Mac OS X "Read Me.rtf". Let's see what is the best format for Windows; plain text is always a reliable option.</li>
<li>As to the multiplayer code, I did some more thinking and analyzing of the current behavior, and came to the conclusion that the way Doomsday handles mobjs on clientside is rather inadequate for reliable behavior. The essence of it is that the gameside logic needs to handle the mobjs in order for everything to behave correctly, and that is currently impossible because clmobjs are created by the engine and are incompatible with the game's mobjs. Thus I am planning on changing the clmobjs so that they are an extension of the game's mobjs: the engine simply allocates enough memory for the mobj and lets the game worry about setting all the parameters — in fact, the server sets the parameters and they are just replicated on clients. This will make it possible for the engine to treat game mobjs and client mobjs in exactly the same way.
<li>I intend to carry out this refactoring during the coming week. As the clientside code is rather self-contained, I don't expect the changes to have a very great impact on the rest of the code base.
</ul>
<strong>danij:</strong>
<ul>
<li>Last week was rather productive. Much of the materials subsystem has been overhauled, fixing many of the most salient problems in the process. The highlights being 1) relocation of the material patching and auto-generation mechanisms into the .DED reader and 2) extraction of nearly all material and texture specification meta into new objects. In addition, I also resolved a prominent performance bottleneck when detail and/or shiny textures are used.</li>
<li>Unfortunately I'm not quite at the point where I can move on to the texture atlases (and thus complete the composite bitmap font management) but its certainly within touching distance. The main task remaining is to relocate the material snapshots into material variant. After which I can finish up the API refactoring (mostly naming standardizations and other lite changes).</li>
<li>This week I expect I'll have much less time for deng. Although, perhaps some background processing will help me solve a couple of design issues I'm (probably needlessly) agonizing over. One of which being the point the detail texture contrast cvar is interpreted.</li></ul>
<strong>skyjake:</strong>
<ul><li>Most of my time was spent on Amethyst and a filter for outputting Unix manual pages. I am happy to say that I got it working quite nicely, so that for the next stable release we will be able to have a proper Unix manual page for Doomsday. As to its content, I think it will be a description of the most important command line arguments plus the portions of the old readme that haven't become obsolete. I also got halfway through writing a filter for .RTF, so we can have a revised Mac OS X "Read Me.rtf". Let's see what is the best format for Windows; plain text is always a reliable option.</li>
<li>As to the multiplayer code, I did some more thinking and analyzing of the current behavior, and came to the conclusion that the way Doomsday handles mobjs on clientside is rather inadequate for reliable behavior. The essence of it is that the gameside logic needs to handle the mobjs in order for everything to behave correctly, and that is currently impossible because clmobjs are created by the engine and are incompatible with the game's mobjs. Thus I am planning on changing the clmobjs so that they are an extension of the game's mobjs: the engine simply allocates enough memory for the mobj and lets the game worry about setting all the parameters — in fact, the server sets the parameters and they are just replicated on clients. This will make it possible for the engine to treat game mobjs and client mobjs in exactly the same way.
<li>I intend to carry out this refactoring during the coming week. As the clientside code is rather self-contained, I don't expect the changes to have a very great impact on the rest of the code base.
</ul>
<strong>danij:</strong>
<ul>
<li>Last week was rather productive. Much of the materials subsystem has been overhauled, fixing many of the most salient problems in the process. The highlights being 1) relocation of the material patching and auto-generation mechanisms into the .DED reader and 2) extraction of nearly all material and texture specification meta into new objects. In addition, I also resolved a prominent performance bottleneck when detail and/or shiny textures are used.</li>
<li>Unfortunately I'm not quite at the point where I can move on to the texture atlases (and thus complete the composite bitmap font management) but its certainly within touching distance. The main task remaining is to relocate the material snapshots into material variant. After which I can finish up the API refactoring (mostly naming standardizations and other lite changes).</li>
<li>This week I expect I'll have much less time for deng. Although, perhaps some background processing will help me solve a couple of design issues I'm (probably needlessly) agonizing over. One of which being the point the detail texture contrast cvar is interpreted.</li></ul>