Doomsday and glnodes
<i>This post was originally made by <b>Yagisan</b> on the dengDevs blog. It was posted under the categories: Engine, Games.</i>
<p>Doomsday has had glbsp 2.20 as it's glnode plugin for a while now, this new version supports both v5 and v2 node. Doomsday however only supports v2 nodes. Considering there are wads that overflow the v2 limits, but not the v5 limits, shouldn't we update support to include v5 nodes. We could do it one of two ways, build v2 nodes, and when that errors (like on map20 of av.wad), rebuild as a v5 node, or be lazy and just build v5 nodes.</p>
<p>Comments ?
</p>
<p>Doomsday has had glbsp 2.20 as it's glnode plugin for a while now, this new version supports both v5 and v2 node. Doomsday however only supports v2 nodes. Considering there are wads that overflow the v2 limits, but not the v5 limits, shouldn't we update support to include v5 nodes. We could do it one of two ways, build v2 nodes, and when that errors (like on map20 of av.wad), rebuild as a v5 node, or be lazy and just build v5 nodes.</p>
<p>Comments ?
</p>
Comments
<ul>
<li>Updated dpMaploader.dll to glbsp 2.20.</li>
<li>All of Doomsday's internal map data object limits have been expanded in line with other limit removing source ports.</li>
<li>Implemented routines to automatically generate a valid blockmap for levels that overflowed that limit (adapted version of the algorithm used in PrBoom).</li>
<li>Rewrote the map setup code so that it is nolonger limited to a specific map data or glnode data format. Everything is configured dynamically including byte offsets, type sizes, byte signs etc
</ul>
The final step is to finish the planned system whereby the map data and glnode formats will be configurable completely via DED definitions and setup at runtime.
This final job has been left until beta-5.
Actually, I have already implemented support for v3 nodes to test that the above all works correctly.
All that is needed is to add the correct property values to Src/p_arch.c in P_InitMapDataFormats().
That function and most of the hardcoded arrays at the top of that file will be removed completely of course once the values are read from DED. For now you get to revel in needless repetition
If you do add v5 support don't replace any of the existing values for other formats.
Since the code is a WIP it isn't very intuitive and it's likely I'm the only one who can understand some of it...
That is correct. The idea is that we'll be able to release a set of updated DED's VERY quickly whenever a new node format is introduced.
Also, any mod can create a customised map format and as long as there is a DED definition of the format Doomsday will be able to load it.
Most of the properties accessible via DMU by the game when in-game will ultimately be accessible via DAM (Doomsday Archived Mapreader) meaning it will be possible to create for example, a Doomsday specific map format where you have access to all of Doomsday's map data properties in a map editor. Things like sector lighting, surface colors, reverb properties etc etc.
glvis is a different matter entirely. We won't be able to support that just by editing a few DED definitions.
Personally I'm of the opinion that we have no use for the glvis data at this time. Doomsday's existing clipper does an excellent job so much so that the GLVIS data is redundant. Not to mention that the GLVIS data is incredibly slow to calculate (some levels I've tested in Vavoom take 10+ minutes to generate the data for).
That will never happen. We don't need to worry about it as dpMaploader.dll will always select the correct glnode format for a particular map when building the nodes.
So for example, if the map would breach the v2 limits depending on which limits are breached and the severity of the overflow - it will either generate v3 or v5 glnodes. Doomsday will respond automatically by selecting the correct glnode format when loading the glnode lumps.
In the new implementation, Doomsday also supports mixed glnode formats. So you could have the vertexes in v2 and the segs in v3/v5 (though I doubt that will ever happen
The map data format and the glnode format is NOT defined in each map. The map data format CAN be declared by name (not the glnode format) but the format defintions themselves are independant of the maps.
The declared data format in the map is not treated as absolute (and is not required in the case of DOOM and HEXEN format maps). Doomsday will check each lump to try and determine the format of each map data lump automatically.
Incidently, I've just tested AV.WAD MAP20 and it loads perfectly in jDoom with SVN 3162. That particular map only needs v2 glnodes but it DOES overflow the standard GLSEG limit.
The ultimate plan of partially freezing the rendering lists should have a drastic effect on maps like that.
You can get a rough handle on how big of a difference the partial freezing will make by toggling the CVAR "rend-dev-freeze".
On my system I get about 14.2FPS in the opening area. When freezing the rendering lists that figure jumps to 47.5FPS.
Thats still not ideal but it is a HUGE improvement considering the map's complexity.