[Spirrwell]

Hi there.

So I've pretty much been referencing this website: http://www.shikadi.n..._Format_(Build) for documentation on Duke3D file formats. The documentation on this website is pretty awesome, but I'm worried there's some errors as I seem to have run into some. It does link to this https://github.com/j...oc/buildinf.txt which does have a lot more detailed information, but I really like the condensed documentation of the map format.

I've been trying to avoid going through code because even something like eduke32 is so C like it's just so ridiculous to try to read.

Anyway, the issues I'm worried about regarding this documentation are that the types specified are wrong, and I would like to write better\easier to read documentation.

The first issue I came across was with the "cursectnum." Here it's specified as a uint32. I was getting wonky results reading it from the map file. The fact that "numsectors" was a uint16 kind of tipped me off that it was probably wrong. It doesn't make sense for the sector number to be bigger than the total number of sectors. So I assume this is supposed to be a uint16 as well?

The other thing I noticed is that the positions here are written as unsigned, yet looking in mapster32, the position is definitely signed. Is that because of additions to eduke32, or is it supposed to be signed?

Looking at the buildinf.txt, I don't even see it using unsigned. It uses longs and shorts. Also the posZ is apparently shifted up 4, but in the buildinf.txt, it doesn't show this being used. Should it then be read as posZ = posZ >> 4? What is the significance of posZ supposedly being shifted like that?

Can anyone verify that this documentation isn't completely broken?

[Hendricks266]

That page on ModdingWiki is completely wrong. As soon as my account gets approved I'll fix it.

typedef struct
{
    int32_t mapversion;

    int32_t posx;
    int32_t posy;
    int32_t posz;
    int16_t ang;
    int16_t cursectnum;

    // Past this point you could not simply fread() into the struct all at once.
    // You would need to read the array counts, malloc the proper size, assign the result to the correct pointer, and then fread into that.
    int16_t numsectors;
    sectortypev7 *sectors;
    int16_t numwalls;
    walltypev7 *walls;
    int16_t numsprites;
    spritetypev7 *sprites;
} buildmapv7;

typedef struct
{
    int16_t wallptr, wallnum;
    int32_t ceilingz, floorz;
    uint16_t ceilingstat, floorstat;
    int16_t ceilingpicnum, ceilingheinum;
    int8_t ceilingshade;
    uint8_t ceilingpal, ceilingxpanning, ceilingypanning;
    int16_t floorpicnum, floorheinum;
    int8_t floorshade;
    uint8_t floorpal, floorxpanning, floorypanning;
    uint8_t visibility, filler;
    uint16_t lotag, hitag;
    int16_t extra;
} sectortypev7;

typedef struct
{
    int32_t x, y;
    int16_t point2, nextwall, nextsector;
    uint16_t cstat;
    int16_t picnum, overpicnum;
    int8_t shade;
    uint8_t pal, xrepeat, yrepeat, xpanning, ypanning;
    uint16_t lotag, hitag;
    int16_t extra;
} walltypev7;

typedef struct
{
    int32_t x, y, z;
    uint16_t cstat;
    int16_t picnum;
    int8_t shade;
    uint8_t pal, clipdist, filler;
    uint8_t xrepeat, yrepeat;
    int8_t xoffset, yoffset;
    int16_t sectnum, statnum;
    int16_t ang, owner, xvel, yvel, zvel;
    uint16_t lotag, hitag;
    int16_t extra;
} spritetypev7;

This leaves out the need to byteswap every variable larger than (u)int8_t if you are operating on a big-endian machine.

[Spirrwell]

Ah awesome, are all Duke3D maps (excluding eduke32 additions) version 7?

[Hendricks266]

Yes, with the only exception being LameDuke. Version 8 is identical to version 7 except the internal limits for the array counts are higher (which does not affect the map structure at all). Version 9 has TROR, which again does not affect the structure besides some of the fields in the sector structure taking on different meanings.

[Spirrwell]

Cool, I see you must've already updated that wiki. Thanks a lot! This is really helpful. I just hope that the other formats listed don't have any more errors. Though I've gotten GRP and VOC support so far.