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

To merge, or not to merge (vanilla PWAD oddities)

Recommended Posts

from here

"Replacing sprites using a PWAD file presents certain problems"

What problems, exactly?

I've always heard conflicting statements on what would constitute a requirement of using deusf/nwt/etc. utilities.

Can someone knowledgeable in this weird limitation explain what exactly prevents certain resources from being replaced using a PWAD the conventional way? This has never been fully explained to my knowledge, and if it has, it certainly doesn't seem to be common knowledge among mappers these days.

Share this post


Link to post

Vanilla Doom requires you to include all the sprites in a Pwad.

Hence a program, DEUSF, was created that automatically copied the Iwad and patched a mods new sprites into it.

Share this post


Link to post

Sprites have to be in a contiguous block, beginning with S_START and ending in S_END. If there is any lump within that block that doesn't fit the expected format for a sprite lump (four letter sprite name + two or four letter code indicating frame and angle), the game bombs out with an error at startup.

The end result is that you can't put sprites in WADs. When you use -file, it's conceptually the same as appending the PWAD's list of lumps to the IWAD's list of lumps. Therefore, if you put S_START ... S_END in a PWAD, the startup code will expect that block to include the complete set of all sprites used in the game. So you can make a PWAD that replaces all the game's sprites, but that isn't usually what you want to do.

The same problem also exists for flats (which have to be in F_START ... F_END), but there's a clever workaround you can use for them. You put F_END in a PWAD but no F_START. When the game starts up, it sees F_START from the IWAD and F_END from the PWAD. Some of the lumps in the range aren't really flats but Vanilla Doom doesn't mind. You can't use the same trick for S_START ... S_END because it's pedantic about insisting that everything has to be a sprite.

Share this post


Link to post

OK, now it makes sense to me. My follow-up question: Why was this still the case all the way to v1.9? The only guess I can make is that Doom was originally created with no thought of modifying it, but by v1.666, weren't there already TCs in existence that required this technique to work? If it is an oversight, it is a massive one.

Just something to ponder about, I suppose... What is the code responsible for this? how do modern ports handle it?

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
Sign in to follow this  
×