Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Player Start Problem

edited 2007 Aug 16 in Developers
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Games, jHeretic.</i>

I was recently digging in my backup archives and located a set of Heretic PWADs that I had created way back in 1995. But upon loading them up in Doomsday, the player start was somewhere way off the map area itself. The map itself played OK in the original Heretic. Also, it seems that in the normal Heretic E1M1 the player doesn't start at the correct place, but some way to the left (still in the correct room, though).

Danij, Yagisan, could you <a href="http://idisk.mac.com/skyjake/Public/TOMB.WAD">download the map</a> and see if the same thing is happening to you. I was ultimately able to locate the map by running towards the direction where the sky sphere was visible.

Comments

  • This is a new bug introduced when I changed the map loading code to automatically rebuild the BSP using glBSP.

    It appears the problem is caused in dpmaploader::Dumpmap(), it would seem that the WAD directory or lump offsets are not being written correctly. If you compare the copy of the map written to the bspcache with the original you will notice that the start of the THINGS lump data appears to be shifted from the actual start offset. This has the effect that the first few elements contain errornous values.

    I believe I mentioned this problem on ICQ?

    I've not attempted to fix the issue as over the past couple of weeks I've been working on a further redesign of the map loading/bsp caching code. This new code is not yet in a working state so rather than commit it to svn I've held back so that maps can at least still be loaded in the trunk.

    It would be great if we could start brainstorming some ideas for data structures for the map data objects soon.
  • OK, I see. How does the maploader differ from the original, apart from it always building the nodes? (I.e., what exactly was the change that introduced the bug?) Is it the intention to keep the basic operation the same, so that it basically generates the GL-lumps, saves them into a WAD file in the bspcache, and loads it in as the auxiliary WAD?
  • The change that introduced the bug was when dpmaploader::Dumpmap() was modified to copy all the map data lumps from the src WAD instead of just the node lumps.

    The basic operation will stay roughly the same but the majority of the logic currently in dam_main.c needs to be moved and/or restructured. The way I see it, the process should go something like this:
    <ol>
    <li>Game calls P_Setup("MAP01") to instegate a mapchange.</li>
    <li>If a cached map is available skip to #8. We will need a mechanism where the cached map is marked with a format version number and it would be rebuilt if it is in an earlier format (so that we can add new data to the cached map format in future).</li>
    <li>The core map data geometry lumps (VERTEXES, LINEDEFS, SIDEDEFS, SECTORS) are located for the map specified and are read in using all the custom binary lump format stuff currently in dam_main.c, other lumps like THINGS and BEHAVIOR are located but not read at this stage.</li>
    <li>SIDEDEFS are unpacked using the logic currently in dam_main.c</li>
    <li>VERTEXES, LINEDEFS, SIDEDEFS and SECTORS are scanned and any duplicate/unused structures are pruned (using the logic currently in glBSP).</li>
    <li>The map data structures are passed to glBSP which then creates the BSP data structures. Either by passing ptrs to them in shared memory (preferred) or writing to an intermediate WAD file as currently done in dpmaploader::Dumpmap().</li>
    <li>All map data structures are finally written to a Doomsday-specific, binary, archived map file format in the bspcache (this includes THINGS and BEHAVIOR which have been untouched so far).</li>
    <li>Locate the archived map file in the bspcache and load it in using the custom binary lump format stuff in dam_main.c.</li>
    </ol>
    BTW, I've just noticed there appears to be some minor issues with the current dengDevs stylesheet:
    <ul>
    <li>I did not realize that you had included a link to your map in the first post as it looks the same as the body text.</li>
    <li>An ordered list (above) is being displayed the same as an unordered list (this one).</li>
    </ul>
Sign In or Register to comment.