I've been working a bit on code for reading and writing WADs. I noticed that in DOOM.WAD and DOOM2.WAD there are very frequently 1 to 3 bytes in between the data for each lump. (For example, in between the DEMO1 and DEMO2 lumps in DOOM.WAD are two apparently unused bytes, specifically 0x6D 0x6D.) These bytes are ignored by SLADE 3; loading one of these IWADs and then re-saving it removes the in-between bytes. This makes me believe that the bytes probably do not affect how the Doom engine or its ports behave when loading the file, but I would still like to understand how they got there. Maybe they're some kind of metadata used and outputted by the old WAD editing tools? I was hoping someone could shed some light.
edit: On further investigation it looks like the bytes at least function as padding, such that every lump begins on a 4-byte word boundary. But that doesn't explain why it's not all just a bunch of null bytes?
I've been working a bit on code for reading and writing WADs. I noticed that in DOOM.WAD and DOOM2.WAD there are very frequently 1 to 3 bytes in between the data for each lump. (For example, in between the DEMO1 and DEMO2 lumps in DOOM.WAD are two apparently unused bytes, specifically 0x6D 0x6D.) These bytes are ignored by SLADE 3; loading one of these IWADs and then re-saving it removes the in-between bytes. This makes me believe that the bytes probably do not affect how the Doom engine or its ports behave when loading the file, but I would still like to understand how they got there. Maybe they're some kind of metadata used and outputted by the old WAD editing tools? I was hoping someone could shed some light.
edit: On further investigation it looks like the bytes at least function as padding, such that every lump begins on a 4-byte word boundary. But that doesn't explain why it's not all just a bunch of null bytes?
Edited by meapineappleShare this post
Link to post