Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Maes

Discrepancy in VERTEXES and other on-disk structs counts.

Recommended Posts

I've reached the point where I'm performing a complete level loading from disk with my Mocha Doom project, however I've noted some discrepancies/dualities between the on-disk structs and the in-memory ones.

E.g. the C code has a mapsector_t struct for reading a sector from disk, and then copies its fields (as well as generating others) procedurally in the sector_t structs actually used in memory. The same thing happens with other map structs as well.

I had no problem replicating this functionality in Java, however when I fired up some level and lump editors to cross-verity that I was reading the correct amount and types of data, I stumbled upon some inconsistencies, and so I am not sure what is supposed to be valid.

I am using E1M1 for reference, as found in the DOOM1.WAD Shareware IWAD.

The inconsistencies:

  • THINGS count: should be 138 using 10-byte structs. XWE fucks this count up by using Hexen THINGS as a reference, but Doombuilder reports 138 too, so I guess that one should be OK.
  • VERTEXES count: that is pretty messed up. The length of the lump ON DISK is 1868 bytes, so by reading two 16-bit shorts for each vertex, we should have 467 entries, aka 467 vertices (XWE and mochadoom agree on this one) but DoomBuilder reports 385. Is DoomBuilder performing some sort of optimization/rejection of unused vertices or something?
  • NODES count: 236 (XWE reports 472, but it seems like bogus, since the entry is 6608 bytes long and a NODE structure on disk (mapnode_t) should be 28 bytes. It's one of the few map structs that match exactly in memory and on-disk, BTW.
Some other metrics I need to confirm:
  • SSECTORS size: 237 entries (XWE agrees)
  • SECTORS size: 85 entries (DW agrees)

  • I still need to load SSEGS (depend on LINEDEFS which depend on SIDEDEFS, which I must also load)
BTW, a trend I noticed with this project is that very often I have to reach into the lowest levels of how stuff works. On the converse a C/C++ port can overlook most of this stuff unless the structs themselves are altered. To convert the thing into Java I literally have to look at every single line of code at least once, which I doubt most source port authors had to do.

Share this post


Link to post

Once, I had to convert a Hexen format map into UDMF. The resulting map was correct, except that it had lots of extra unlinked vertices, placed right on top of linedefs. They were spawned according to a pattern, to a grid (they were collinear and parallel to the X or Y axes). Maybe those are the "ghostly" vertices you're seeing extra.

Perhaps some utility needs those extra vertexes to simplify calculations... and Doom Builder and most editors automatically delete them for you, unless it's reading from TEXTMAP........

Share this post


Link to post

Don't use DoomBuilder (either 1 or 2) for your comparisons - it will always prune and merge on load/save and there is no way to disable this behavior.

Share this post


Link to post

IIRC the extra vertices are used by the nodes\subsectors\nodesbuilder. A map editor will, as DaniJ said, prune these.

Share this post


Link to post

Well, seems that's the way it's meant to be. I completed loading of all structs of a map from disk, so the very least I have a complete Java-fied DOOM map library in my hands, that's also awfully close to the original SC (of course I rewrote some things like e.g. the lines-per-sector counting code, as it doesn't need to be so fucked in Java as it's in C).

I must say that reaching the point where one really finds himself at the lowest, most basic point where the innards of Doom have no more to reveal is very, very satisfying. I find myself regularly putting hours into this.

Share this post


Link to post
exl said:

IIRC the extra vertices are used by the nodes\subsectors\nodesbuilder. A map editor will, as DaniJ said, prune these.

The things you learn every day. No documentation has ever told me of extra vertices added into the map for processing reasons. Then again, I was never curious to study the BSP tree logic of Doom.

Share this post


Link to post
printz said:

The things you learn every day. No documentation has ever told me of extra vertices added into the map for processing reasons. Then again, I was never curious to study the BSP tree logic of Doom.

Well of course. When linedefs are split into segs they have to terminate somewhere don't they? Vertices are added by the BSP builder to serve as endpoints for segs which do not coterminate with their parent linedef.

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
×