Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Acid

Updating "directory" of pwad

Recommended Posts

(Using this as reference)

From chapter 2, "The Basics", "the directory has one 16-byte entry for every lump".

Say I had my wad as:

HEADER
STUFF
DIRECTORY
STUFF

If I were to say, manually add a new graphics lump (or anything) to my wad, how would I update my directory table? If I added 16-bytes to the end of the table, wouldn't that overwrite anything that comes after the table? Does that mean I need to "shift" everything after it 16-bytes (but wouldn't that mean that I'd need to update every single offset in my directory table)?

Similarly (from chapter [8-4], "A TEXTURE lump starts with a 4-byte long integer N which is the number of textures defined in it. Following it are N long integers which are the offsets in bytes from the beginning of the TEXTURE lump to the start of each texture's definition."

If I wanted to manually define a new texture in my TEXTURE1, how would I add a new long integer after the texture count at the start of the TEXTURE1 lump?

Any help or guidance would be greatly appreciated!

Share this post


Link to post
BloodyAcid said:

Does that mean I need to "shift" everything after it 16-bytes (but wouldn't that mean that I'd need to update every single offset in my directory table)?

Yes and yes. Although in practice, the directory is often placed at the very end of the wad, so that offsets won't have to be recalculated. But you would have to "shift" the directory itself in order to put data before it while keeping the directory at the end.

This is why wad content editors like SLADE3 exist, they do all this "shifting and recalculating" work for you automatically.

Share this post


Link to post
scifista42 said:

Yes and yes. Although in practice, the directory is often placed at the very end of the wad, so that offsets won't have to be recalculated. But you would have to "shift" the directory itself in order to put data before it while keeping the directory at the end.

This is why wad content editors like SLADE3 exist, they do all this "shifting and recalculating" work for you automatically.

Ah gotcha, thanks for the response. I'm practicing some programming, and decided to fiddle around with pwads. Slade would be my go-to solution for any real wad editing anyways :) It just seems like a huge pain to have to update every little thing in the wad to account for a really minute change, but then again, this was from 1993...

Share this post


Link to post

Updating offset positions isn't that hard.

Each lump should be treated as a class (or struct, if you're not using OOP) with at a minimum the following properties:
- Name (an array of 8 chars is enough)
- Data size (unsigned int)
- Data (you'll probably want a pointer for that)
- Offset (another unsigned int)

When you save the .wad, you write each lump in sequence. You have a rolling offset variable that can start at the value of the size of the header, and then each time you write a lump's data, you set that lump's offset to this variable, then add the lump's size to your rolling offset variable. Once you've finished writing the data from all the lumps, write the directory, using this time each lump's name and offset.

There isn't any data storage format in existence where you may not need to worry about shifting and recalculating some bytes around if you change the size of one of the elements. I mean, there are some formats (like tar) which use a lot of padding so that every file start is aligned to a multiple of 512, which does allow some room for lumps to grow without having to recalculate everything, but that's only if you increase the size by less than the existing padding.

Share this post


Link to post
Gez said:

Updating offset positions isn't that hard.

I spent a good chunk last night thinking about implementing what I want to accomplish, and I do agree that it's not really that hard. I think your proposed solution is a bit of a cheat-sheet for me, but I think it's because I never realized that the directory could be written at the end of the wad.

Share this post


Link to post

When it comes to programming, there's no such thing as a cheat.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×