Maploader 2 - Milestone One Reached

edited 2007 Dec 2 in Developers
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Blog, Engine, Mac OS X, Platforms, Unix/Linux, Windows.</i>

As you'll be aware from my recent posts, lately I have been working on the map loading process in Doomsday. This work has just reached a milestone in that the new maploader is now working and Doomsday is once again able to load maps. If that wasn't good enough, Doomsday is now able to load maps far larger than ever before.

So to celebrate, I thought some pics of a HUGE map running under Doomsday were in order. The largest map I had to hand being Deus Vult MAP05.

Here is a shot of the entire map (pretty much) in view at the same time.

<img title="Deus Vult MAP05: Almost the entire map on screen at once!" alt="Deus Vult MAP05: Almost the entire map on screen at once!" src="http://www.dengine.net/testing/dvmap05_1.png&quot; />

And here is the same map as seen from the new automap (excuse the incorrect map name for now):

<img title="Deus Vult MAP05: As seen from the new automap." alt="Deus Vult MAP05: As seen from the new automap." src="http://www.dengine.net/testing/dvmap05.png&quot; />

Those of you with keen eyes have no doubt noticed the FPS count in the above screenshots and you would be right in thinking, that it is currently unplayable. However, 1.5fps with the entire map in view is not bad considering no attempt has been made to optimize yet.

Once the work on the new maploader has been completed we can begin to think about ways to raise the fps to something playable.

Over the coming weeks I will be continuing to develop the new maploader.

Comments

  • The code for milestone one has now been commited to svn. This commit sees maploading working again in svn and the various issues with dpmapload::DumpMap() are no longer pertinent.

    Work has since begun on the second phase of the redevelopment of the map loading process (refactoring the node building logic into an OO design and remove the use of duplicate data structures).
  • Time for a progress update I think.

    Since my last post I have been continuing to develop the new map loading code. Work is progressing steadily towards milestone two. This work includes:
    <ul>
    <li>One-time allocation of map data structures. In the current svn version, map data is loaded through the following process, 1) Read from lump 2) Build Nodes 3) Allocate new structures to replace those originally read in #1 with the transformed structures produced in #2. We now work entirely within one format and set of map data structures and transform them appropriately. In other words, the glBSP node building logic is being melded completely with our own mapdata loading/management logic as each have structures and algorithms that benefit the other.</li>
    <li>Complete update of the playsim to use floating point math. Somewhat surprisingly, this work is going pretty smoothly and I've now got a completely functional jDoom. Another four games to go...</li>
    <li>The blockmaps used for mobjs/lines/polyobjs/subsectors are being moved completely into the engine. The games should not need to know about how we structure the map data internally. This has implications for both the map loading process and the freezing of the Doomsday API, so now seemed like a good time to do it. In the place of "P_BlockObjectsIterator" we now have a plethora of "P_ObjectsInBBoxIterator" which take world coords rather than a blockmap vector. Conceptually, they should be interfaced through DMU where possible but, first things first :)</li>
    <li>In the process of the blockmap work, I've removed the fixed blocksize limitations. Meaning we now have the option of using sparser/denser blockmaps depending on e.g. the size of the map, or an average of the number of linedefs per square world unit etc.</li>
    </ul>
    Hopefully this work will be hitting svn fairly shortly.
  • After running into some issues with our blockmap code I decided it would be most helpfull if we had some sort of graphical debugging aid. So here is the new blockmap visualizer:

    <img title="Blockmap visualizer" alt="Blockmap visualizer" src="http://www.dengine.net/testing/blockmapdebug.png&quot; />
    <ul>
    <li>Green Square - The viewPlayer.</li>
    <li>Yellow Line - Linedef linked to the block the viewPlayer is in.</li>
    <li>Orange Line - Linedef linked to a block within the extended collision box of the viewPlayer.</li>
    <li>Red Line - Block-linked linedef.</li>
    <li>White Block - The block the viewPlayer is in.</li>
    <li>Light Gray Block - A block within the extended collision box of the viewPlayer.</li>
    <li>Transparent Block - A block with one or more linked linedefs.</li>
    <li>Black Block - A NULL block, does not exist in our blockmap.</li>
    </ul>
  • Time for another progress update.

    Work is continuing on maploader 2 and I've now just about finished dividing the code into the three seperate phases that is the final design (milestone 2):
    <ol>
    <li>Read the map data from WAD format maps. Here transforms are done to adjust the map to the format expected by Doomsday. This part will be moved out of the engine and into a plugin (maploader 2).</li>
    <li>The new Doomsday map building API is used by maploader 2 to recreate the loaded map. Once all structures have been transfered, Doomsday is signaled that the map is complete.</li>
    <li>Doomsday then carries out yet more transforms on the map data to convert it into our native map format (this includes building the BSP and triangulation of subsectors).</li>
    </ol>
    The next step is to implement some form of caching mechanism so that we don't need to go through this process each time a map is loaded.
Sign In or Register to comment.