This tutorial is dedicated to the art of texture maintenance in Doom wads, in particular as far as
choice of software is concerned. We'll be going over two popular choices for the task, SLADE
and DoomMake, and the pros and cons of each.
There's a lot that goes into texture maintenance in wads - not only do you want to ensure that all
necessary custom textures are included, but preventing bloat and removing resources duplicated from
IWADs is also important. More often than not, SLADE is adequate for importing your custom textures
into a wad, and it can also remove duplicated IWAD resources with a single button click. However,
when it comes to removing resource bloat, SLADE's built-in tools can remove actually used textures
at best and completely break your wad at worst.
Let me share an anecdote to illustrate: back when I was compiling Literalism,
I ran into a problem at one point where SLADE removed one too many custom textures from the wad and
resulted in a wad that was completely unplayable. And when I say "completely unplayable", I mean it
did not even boot up - every source port I dared test it in errored out and refused to load the wad.
Ultimately, the issue led to me recompiling the entire wad from scratch when I was unable to fix it
by just editing the wad.
Following that incident, I started looking into DoomMake, and when I found out just how good it is
when it comes to automating a lot of the compilation work, I started using it in my own projects.
Projects like Devious Deviance, McDoomguy's
Slaughterific Sample Platter and the still-WIP ColdWire all
use(d) DoomMake as part of the workflow. At this point, the question probably lingers in your brain:
why is DoomMake so good? And the answer is simple: DoomMake is good because it does the texture
maintenance a fuckton more reliably than SLADE.
While SLADE and DoomMake's methods for scanning the wads for (un)used textures are largely similar,
one of the advantages of DoomMake over SLADE is that it properly accounts for animated/switch textures.
With SLADE's texture cleanup tool, you still have to manually sift through the texture list and uncheck
any textures you want to keep before hitting the OK button, which has the potential to break your
animated textures - and, worse yet, your wad - if you forget to uncheck them. With texture packs like OTEX
with thousands of textures, doing so can become a major pain in the ass. DoomMake automates that
task by checking if a texture is animated and, if it is, grabbing the animation frames and embedding
them into the wad.
DoomMake also automates the resource cleanup part of texture maintenance by scanning the maps only
for the textures they actually use and building the final wad with only those textures embedded.
Granted, SLADE does it very similarly, but there's still a manual step to it and, as explained above, it's
not the most foolproof method. I have yet to run into a case of a broken wad with DoomMake. DoomMake also
makes building a resource pack for your project easy, especially when combined with WadMerge - just build
the textures to combine all your custom textures into a single wad, or write a WadMerge script and run it
to get a single wad with textures, sprites, DeHackEd etc. all included. DoomMake's only downside is that
it doesn't have built-in functionality for scanning and removing duplicate IWAD resources, so it's a good
idea to open the wad up in SLADE and run the duplicate IWAD resource removal just in case.
So, in summary, here are TL;DR versions of the pros and cons of both SLADE and DoomMake:
SLADE:
DoomMake:
With all that considered, if you've never used DoomMake before, I whole-heartedly recommend you give it
a spin. I promise it'll make your wad compilation life easier in the long run. But that's not to say DoomMake
is a full-on replacement for SLADE - the latter still has its place in your wad editing workflow. Once
you've built your final wad ready for submission to /idgames, open it in SLADE and run the duplicate IWAD
resource removal. Moreover, DoomMake integrates with SLADE for tasks such as modifying sprite offsets.
That concludes this tutorial.