Beta 5 Planning
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Beta 5, Engine, Games, Releases, Version 1.9.</i>
Let us decide the features to implement for 1.9.0 Beta 5.
<h3>Beta 5</h3>
I have listed these in rough order of priority.
<ol>
<li>Move development back to the repository trunk.</li>
<li>Revise source directory hierarchy. How about the runtime directory structure? It should be revised as well. However, we must try to retain compatibility with the old structure.</li>
<li>New savegame format and system, where the engine is allowed to save and restore data as well. Should allow future expansion without breaking compatibility. Read support for old savegame format needs to be retained.</li>
<li>Multiplayer fixes. Client crashing when another player connects. (Cl_Frame2Received: Unknown delta type 5. (<a href="https://sourceforge.net/tracker/?func=detail&atid=542099&aid=1019136&group_id=74815">report</a>) (<a href="https://sourceforge.net/tracker/?func=detail&atid=542099&aid=1496666&group_id=74815">report 2</a>)</li>
<li>Precaching problems. During gameplay, all resources should be loaded. Especially models. If there is not enough memory to hold all the textures, downscale them automatically until they fit.</li>
<li>Crash at startup when no IWAD has been specified (after startup aborted by user). Also when launching WolfenDoom without doom2.wad (<a href="https://sourceforge.net/tracker/?func=detail&atid=542099&aid=1496661&group_id=74815">report</a>)?</li>
<li>Proper notifications via DMU: R_UpdateSector replacement. Vital for efficient LG updates. Need to do something about the glow property update?</li>
<li>XG: Still some noticeable problems here due to the existing DMU implementation being incomplete. Noteably dummy object handling - Doomsday isn't checking if an object is a dummy before calling P_Callback(p). Mostly fixed / still broken?</li>
<li>Should mobjs be included in the DMU? Notification of mobj data changes would be beneficial as well.</li>
<li>Finish customizable map data format support and export via DED. Create definitions for ALL existing GL Node formats.</li>
</ol>
<h3>Beta 6: The Final Beta?</h3>
Focus mostly on finishing and tuning bias lighting. This is an engine-internal feature, but it has to be completed for 1.9.0, which means it cannot be postponed any further.
<ul>
<li>Current light range is reset when when changing sectors.</li>
<li>Lighting is not consistent between onesided seg middles and twosided seg uppers+lowers.</li>
<li>Surface colors are not intergrated with BIAS, twosided seg middles are currently hidden to remind us of this</li>
<li>Lightning in jHexen causes massive slowdown due to having to change the light levels of all outdoor sectors (lightgrid update). Fix this by calculating another matrix of grid blocks affected by skylight. The skylights are added to the regular bias lighting during evaluation.</li>
<li>Bias light sources don't affects mobjs yet. When drawing a mobj, the bias light level at the location should be evaluated to get a basic ambient light level.</li>
<li>Automatic conversion of huge dynamic lights to bias sources needs to be revised. Currently any sources acquired by mobjs are not released back into the pool when the mobj is destroyed while the current sprite frame has a light.</li>
<li>Performance optimization for LG map setup and per-frame/update.</li>
<li>Are player view angle changes still properly synchronized with gameplay? Investigate circle-strafing issues.</li>
<li>Snowberry UI tweaks. Make it possible to create the basic layout in a plugin, and have a simpler variant with just the game list, a play button, and a text field for custom options. Make it possible to have the tab area in a separate window from the game list (so that it can appear only when needed).</li>
<li>Sound and model decorations in addition to light decorations. (Does not affect the ABIs, so not really in any hurry but a really nice feature to have.) An intergrated decorations subsystem (including decor lights) that allowed for any object to be used as a decoration would be very nice. A proper decal system should be considered when designing this.</li>
</ul>
Comments? Did I forget anything?
Let us decide the features to implement for 1.9.0 Beta 5.
<h3>Beta 5</h3>
I have listed these in rough order of priority.
<ol>
<li>Move development back to the repository trunk.</li>
<li>Revise source directory hierarchy. How about the runtime directory structure? It should be revised as well. However, we must try to retain compatibility with the old structure.</li>
<li>New savegame format and system, where the engine is allowed to save and restore data as well. Should allow future expansion without breaking compatibility. Read support for old savegame format needs to be retained.</li>
<li>Multiplayer fixes. Client crashing when another player connects. (Cl_Frame2Received: Unknown delta type 5. (<a href="https://sourceforge.net/tracker/?func=detail&atid=542099&aid=1019136&group_id=74815">report</a>) (<a href="https://sourceforge.net/tracker/?func=detail&atid=542099&aid=1496666&group_id=74815">report 2</a>)</li>
<li>Precaching problems. During gameplay, all resources should be loaded. Especially models. If there is not enough memory to hold all the textures, downscale them automatically until they fit.</li>
<li>Crash at startup when no IWAD has been specified (after startup aborted by user). Also when launching WolfenDoom without doom2.wad (<a href="https://sourceforge.net/tracker/?func=detail&atid=542099&aid=1496661&group_id=74815">report</a>)?</li>
<li>Proper notifications via DMU: R_UpdateSector replacement. Vital for efficient LG updates. Need to do something about the glow property update?</li>
<li>XG: Still some noticeable problems here due to the existing DMU implementation being incomplete. Noteably dummy object handling - Doomsday isn't checking if an object is a dummy before calling P_Callback(p). Mostly fixed / still broken?</li>
<li>Should mobjs be included in the DMU? Notification of mobj data changes would be beneficial as well.</li>
<li>Finish customizable map data format support and export via DED. Create definitions for ALL existing GL Node formats.</li>
</ol>
<h3>Beta 6: The Final Beta?</h3>
Focus mostly on finishing and tuning bias lighting. This is an engine-internal feature, but it has to be completed for 1.9.0, which means it cannot be postponed any further.
<ul>
<li>Current light range is reset when when changing sectors.</li>
<li>Lighting is not consistent between onesided seg middles and twosided seg uppers+lowers.</li>
<li>Surface colors are not intergrated with BIAS, twosided seg middles are currently hidden to remind us of this</li>
<li>Lightning in jHexen causes massive slowdown due to having to change the light levels of all outdoor sectors (lightgrid update). Fix this by calculating another matrix of grid blocks affected by skylight. The skylights are added to the regular bias lighting during evaluation.</li>
<li>Bias light sources don't affects mobjs yet. When drawing a mobj, the bias light level at the location should be evaluated to get a basic ambient light level.</li>
<li>Automatic conversion of huge dynamic lights to bias sources needs to be revised. Currently any sources acquired by mobjs are not released back into the pool when the mobj is destroyed while the current sprite frame has a light.</li>
<li>Performance optimization for LG map setup and per-frame/update.</li>
<li>Are player view angle changes still properly synchronized with gameplay? Investigate circle-strafing issues.</li>
<li>Snowberry UI tweaks. Make it possible to create the basic layout in a plugin, and have a simpler variant with just the game list, a play button, and a text field for custom options. Make it possible to have the tab area in a separate window from the game list (so that it can appear only when needed).</li>
<li>Sound and model decorations in addition to light decorations. (Does not affect the ABIs, so not really in any hurry but a really nice feature to have.) An intergrated decorations subsystem (including decor lights) that allowed for any object to be used as a decoration would be very nice. A proper decal system should be considered when designing this.</li>
</ul>
Comments? Did I forget anything?
Comments
Re. #5. if no -iwad specified we should probally look for doom2.wad, then freedoom.wad and finally doom1.wad (sharewhare) in that order, before exiting with a no wad found error. On *nix we should be lookind for them in /usr/share/games/doom as that is where the Doom policy ( http://lists.debian.org/debian-devel-games/2006/05/msg00059.html ) specifies they should be.
Possible #9. On some systems (even very high end ones) we get severe lag effects eg opening a door to a big room with lots of monsters, or strafing around corners into open areas drops the fps into single digits.
The frequency of changes will naturally be much higher than those for the other world data types.
In practice, it would mean that mobj locking and unlocking calls would have to be placed wherever changes are made to the mobj struct members. I have a feeling that implementing this on game-side would not be that much of an ordeal — after all, there is only a limited number of places that actually modify mobj properties, and only one lock and unlock call is needed per mobj-changing function. I shall take a look through the code and try to evaluate the impact.
What I was thinking is that once unlocked, a mobj would remain that way until the end of the current tick in DD_RunTics. At which point it can be relocked automatically and changes engine side can be made in one go. Then lock the mobj before then running the next tic.
I'll reply on that mobj locking later on.
Since we are looking at refining the decorations subsystem we should consider whether decal support can be intergrated also as they would be implemented in a somewhat similar way to decor lights.