-
configure.acis now compatible with autoconf 2.70. C99 is assumed as a baseline default and should not be explicitly called for. -
./configure --enable-manis now the only way an error occurs if AsciiDoc (a2x) is not installed.
-
./configurewas broken in 5.2.0 for systems without AsciiDoc installed. It now properly checks for a2x conditionally along with the possible--disable-manparameter.
-
DeuTex supports textures in TX_START and TX_END markers. These are used by certain editors/engines for textures, with support for storing PNG and JPEG files directly in the WAD. Extraction is likewise handled for all formats.
-
The texture name array was fixed so the maximum possible string size is now supported.
-
Some warnings and errors with old versions of pkg-config and gcc have been fixed.
-
Aliasing errors have been resolved, which caused crashes on some architectures, such as sparc64.
-
DeuTex can now build WADs with an arbitrary number of lumps, but prints a warning when more than 4046 are included (the Vanilla Doom limit).
-
The
-overwriteoption now works. -
Levels are extracted/inserted in a way to preserve GL nodes.
-
Inserting pictures with a height of 1 pixel no longer causes a malloc error, and allows the operation of rebuilding a Doom 1 or 2 IWAD.
-
texture lump file names can now be overridden.
-
DeuSF.
-
-mantroff format generation. -
WinTex options.
-
-fullsnd: now the only mode. -
MS-DOS and OS/2 compatibility.
-
Incomplete (and conditioned out) Rise of the Triad support.
-
PNG support added, creating an optional dependency on libpng 1.6. If compiled in, it is the default extraction format, PPM otherwise.
-
Au and VOC sound formats removed. WAV is the only supported format for extraction and creation.
-
Full sound lumps from the WAD are always extracted.
-
MIDI files can be included just by being named *.mid, and are extracted to the same file name extension.
-
Log file support has been removed, in favor of the user doing a shell redirection (eg, with
>or2>) instead. -
Arch-vile sprites are now extracted and inserted using literal names for sprites with the
[and]characters in names (illegal file name characters on DOS, but not current Windows systems), and sprite names with\are now altered to use^on-disk, matching the ZDoom PK3 standard. -
Graphics with a height > 128 are now inserted into Doom WAD files correctly.
-
UDMF (Universal Doom Map Format) support.
-
Real Autoconf+Automake build system to replace the barely-functioning imitation one.
./configure,make, and related environment variables work as should be expected. -
MS-DOS and OS/2 batch files removed.
-
A
malloc.hinclude was removed to allow compilation on Mac OS X, and is not needed by current Unix systems in general. -
Thousands of lines of code deleted and the entire tree reformated (primarily by using
indent -kr, followed up by manual touch-ups). Several unused files, functions, and commented out code removed. -
C99-style cleanups to use (
u)intN_ttypes,bool,true,falsethroughout the code, replacing old defines. -
AsciiDoc now used for documentation, and building the manpage requires it to be installed.
-
Vanilla
makecompatibility: removed all occurrences of$<not in inference rules in the makefile. -
Vanilla
makecompatibility: removed all\followed by empty lines. On NCR MP-RAS,makequotes all empty lines that follow! -
There is now a
./configurescript (GNU autoconf work-alike).
+ Installing somewhere else than/usr/localis now done by giving./configurethe--prefixoption.
+CC,CFLAGSandLDFLAGSare now auto-detected. The defaults can be overridden by passing./configurethe--cc,--cflagsand--ldflagsoptions.
+ The fixed-size types (Int16etc.) are now correctly set on all LP64 platforms, not just Alpha. -
The OPTIONS section is now updated automatically. This impacts no-one but hackers.
-
two
char[8]were used aschar[9](caught by NCR/MetaWareccon NCR MP-RAS). -
C89 compatibility: removed a few
//comments that had slipped into the source. -
A few functions were declared as
staticbut defined asextern(caught by NCR/MetaWareccon NCR MP-RAS). -
static- andconst-correctness fixes. -
Removed the little-used
Legal()function.
-
Man page: in DESCRIPTION, added a short list of examples to help new users getting started. Added a FILES section. Made the SEE ALSO section a bit more specific.
-
In
--helpand the man page, divided the options into groups and sorted them alphabetically within each group. It seems to be clearer that way. -
Added a FAQ.
-
Obfuscated all email addresses (
tr .@ +=).
The SCRIPTnn lumps are now extracted in human-readable form into the
scripts/ directory. The reverse operation is not implemented. Since
we understand the Strife script format only partially, the output format
is still in flux. New option -scripts to extract only the scripts.
The reverse engineering was done in collaboration with
Matthew W. Miller.
-
It’s now possible to build wads that use a custom
PLAYPAL. Previously, DeuTex always used the PLAYPAL from the iwad when building. It now uses the one inlumps/if it exists. Thanks to Ras2 for reporting the problem. -
Rewrote
COLdiff()as a macro. On my system, the time to build a wad made of a single 1M-pixel patch is down from 1.32s to 0.85s (35% faster), which is not surprising since DeuTex used to spend about 40% of its time inCOLdiff(). The time to rebuild the Strife iwad is down from 8.6s to 7.2s (16% faster). -
Removed the “quantisation is slow” warnings that DeuTex used to spew when composing from PPMs and 24-bit BMPs. Those warnings were relevant to an old quantisation algorithm that has not been used since at least version 3.8 (
#ifdef QUANTSLOW). -
Lifted the arbitrary limit of 256 patches per texture. DeuTex will now accept as many patches as the wad format allows (32,767). If a texture definition has more than that many patches, DeuTex will discard the excess patches with a warning, instead of dying with a cryptic message like
Line n: Illegal char '*'. -
Lifted the arbitrary limit of 4096 on patch width. DeuTex now handles patches as wide as the wad format allows (32,767).
-
Textures wider than 4096 are now accepted with a warning. PrBoom 2.2.3 is known to take textures as wide as 16,384 pixels. 8192×128 textures make XDoom 20001001 crash in
Z_Malloc. 1024×128 textures make Doom freeze inR_Init. The maximum acceptable widths might be higher if the height of the texture is lesser than 128 but I haven’t looked into it. Thanks to David Damerell for testing.
-
Removed the annoying startup banner.
-
If no command is given, emit a meaningful error message instead of suggesting to switch to WinTex. And exit with code 1 instead of 255.
-
All messages now look like this:
+ c code string
+ c is the class of the message: i for information, w for warning, E for error, B for bug.
+ code is a unique 4-character alphanumeric code which unambiguously identifies the message.
+ Some of the messages have been rewritten to be more informative (mention the filename, the nature of the error, etc.). -
At the request of Kim “Sparky” Parrott, all messages are now copied to a file named
deutex.log(deusf.logfor DeuSF). The default log file name can be overridden through the-logoption. If you don’t want a log file, try-log /dev/null(Unix) or-log nul(DOS).
+ The log is only written if a command that works with wads is given.--help,--versionetc. do not create a log. -
Removed the 30 command-line arguments limit.
-
Made exit status a little bit more normal (2 for errors and 3 for bugs instead of -5 and -10).
-
New option
-rateto specify what DeuTex should do when including sound files whose sample rate is not exactly 11025 Hz. The choices are:
+reject: consider it a fatal error and exit immediately with a non-zero exit code.
force: emit a warning and force it to 11025 Hz by resampling up or down.
warn: emit a warning but include it as is anyway.
accept: silently include it as is.
+ Previously, the default (and only option) used to beforce. It’s nowwarn.
+ Thanks to Matthew W. Miller for telling me about this issue (which he did in 1999; the six-year delay is mine, all mine). -
Write errors while extracting PC speaker sounds are now actually detected and reported.
-
Hexen: musics are now identified and extracted properly.
The old music identification code assumed that any lump whose name does not begin with eitherD_orMUS_can’t be a music. It worked for Doom, Heretic and Strife but, for Hexen, it caused all musics to be seen as plain lumps and extracted accordingly into thelumps/directory. DeuTex even tried to interpreteSTALKRandWINNOWRas pictures and said silly things about them having a “width greater than 4096”.
The new code really checks whether the lump begins withMUS\x1ainstead of just looking at its name. A lump is now deemed to be a music if and only if it begins withMUS\x1a.
As a side-effect, certain operations (appending sprites and flats and merging) must have become slower. Furthermore, since these used to blindly assume that any lump whose name begins with eitherD_orMUS_is a music, their semantics might have changed. If you find they don’t do what you want, try again using the-musidoption and let me know whether it improves your condition. -
Hexen, Doom alpha 0.4/0.5: levels are now properly extracted and included.
There have been changes in the undocumented details of DeuTex’s behaviour with respect to levels. The one that is most likely to be noticed is that, when including a level, DeuTex now copies the entire contents of thelevels/pwad, starting from the level label. Previously, it included at most the 11 following lumps, and only if they had the expected names (THINGS,VERTEXESand so on).
But, basically, if thelevels/pwads contain, as they should, all the needed lumps and nothing else, there shouldn’t be any trouble. -
Heretic and Hexen: does not abort anymore with
Bug: *** idinx (12) ***when trying to include the graphic lumps (resp.CREDIT,E2END,FINAL1,FINAL2,HELP1,HELP2,TITLEandCREDIT,FINALE1,FINALE2,FINALE3,HELP1,HELP2,INTERPIC,TITLE). More generally, DeuTex now accepts to compose wads even when there are graphic files inlumps/. -
Hexen: does not abort anymore with
Height of FLAT ./flats/x_001.ppm is not 64 or 65when trying to include flatsX_001throughX_011. In addition, DeuTex now just emits a warning instead of aborting for other oddball heights (i.e. not 64, 65 or 128). Have fun. ;-) This is true for all iwads, not only Hexen.
Fixed ancient bug where DeuTex sometimes failed to include custom
patches if they were not explicitly listed in the [patches] section.
If the first patch used in texture1.txt was a custom patch, it had to
be listed in [patches] or DeuTex would forget to include it. This is
the same bug Olivier mentioned in the home page:
The support for wall patches in DeuTex has been modified. You must now explicitely declare all your patches in a [PATCHE] section.
If you don’t do this, DeuTex will attempt to work as usual, but there seems to ba a bug in this part of the code, so sometime some needed patches are not loaded.
After some summary testing, looks like it’s fixed.
-
More error handling improvements.
-
Bumped version number and cleaned things up for public release.
-
Decreased maximum number of warnings per picture from 10 to 5.
Fixed several bugs that showed in the DOS precompiled executables for
4.1.0 and 4.2.0 (most common symptom: DeuTex aborting with a Can't read
WAD error message).
Lengthy technical explanation: in 4.1.0, I removed the huge pointer
qualifiers that were scattered throughout the source not unlike nitrates
in groundwater. The reasoning was that, since DeuTex is always compiled
in the huge memory model anyway, those qualifiers were redundant. As
I found out at the end of a long and painful debugging session, they
weren’t.
Had I read the doc of the compiler, I would have known that, even when
in the huge memory model, pointers are far by default, not huge.
Far pointers wrap around at 64 kB; this is not what you want when you’re
trying to work with lumps larger than that. And, apparently, there is
no way to specify that pointers should be huge by default.
On top of that, there was a genuine bug in WADRreadBytes2() that would
have prevented the DOS port from working, even if all pointers had been
huge. But this one was fixed in 4.2.1.
I switched to DJGPP, with which you can get working executables without having to contaminate your code with carcinogenic keywords. The bad news: firstly, the executables are somewhat larger. Secondly, since DJGPP executables use protected mode, they tend to be more fussy.
Thanks to Kim Parrott for reporting the bug and alpha testing my fixes.
All the above applies only to the DOS precompiled executables. Other platforms did not have these problems.
New option -usedidx. When called with this option, DeuTex scans all
the graphics in the wad and prints statistics about which palette
indices they use. (By “graphics” is meant “any data that is converted
into an RGB triplet by looking up PLAYPAL or TITLEPAL ”. That
includes flats, graphics, patches, sneaps, sneats and sprites.) I’ve
added this command for my own use, to help my decide which index should
be used to store the transparent colour for Hexen.
-
Fixed a huge DOS bug that made DeuTex fail with
Can't read WADerror whenever it had to read more than 65535 bytes from a wad at once. -
Flushing
stdoutbefore writing tostderrso that messages come out in the right order when both outputs are redirected.
Fixed DeuTex aborting when extracting textures for versions of Strife
≥ 1.1. The problem was that Strife 1.1 and above use a different
format for the TEXTURE1 and TEXTURE2 lumps (Strife 1.0 uses the
same format as Doom). New options -tf strife11, -itf strife11 and
-otf strife11 to support that format. Option -strife has been
changed to imply -tf strife11. New option -strife10 that is
identical to -strife except that it does not imply -tf strife11.
Summary:
-
If you have the Strife 1.0 iwad, use
-strife10(or-tf normal). -
If you have Strife 1.1 or above, use
-strife(or-tf strife11).
Thanks to Kim Parrott for reporting the bug and Len Pitre for pointing me in the right direction.
Fixed two bugs in reading Sun audio (.au) files. Fixes error WAV:
can't read data of./sounds/foo.au [sic] when trying to build a wad.
One of these bugs prevented from reading Sun audio files on
little-endian machines. It had been there for a long time; v3.8 has it
and the v3.6 binary behaves like it had it too. I doubt that anyone had
ever been able to use .au files on little-endian machines before.
-
Replaced certain occurrences of
Int32byiolen_t. -
Replaced certain occurrences of
256byNCOLOURS.
AMENA0 and MSKUL* are now correctly recognized as graphics and not
as lumps anymore. The 21 graphic lumps that ended up in lumps/ are
now properly extracted (into sneaps/ and sneats/). (The first item
involved propagating to IDENTgraphic() the changes made to
PICtoRAW() in v. 4.0.2. The second item needed heavy hacking,
creating a new image type (christened “snea”) and managing an alternate
palette for TITLEPAL.) Still extracted as lumps: GNUM[0-9] and
HUFONT.
The 86 graphic lumps that ended up in lumps/ are now properly
extracted (into sneaps/ and sneats/). Still extracted as lump:
HUFONT.
Errors that used to cause DeuTex to give up on extracting a picture now just make it skip the rest of the column. It also prints detailed messages about what it didn’t like and in which picture it occurred instead of bailing out silently.
-
New option
-dito debug entry identification. Useful mainly to hackers. -
Cosmetic changes in the generated
wadinfo.txtand in the phase messages. -
No more messages
Creating PWADandWAD is complete...during level extraction. -
Set a limit of 10 warnings per picture, to prevent invalid pictures from uselessly flooding the output.
Now accepts to extract pictures as large as 4096×4096 (previously the
limit was 320×200). This fixes Failed to write sprite errors when
trying to extract PSYBA0 and PSYBB0 from strain.wad. Thanks to
Matthew miller for reporting the bug.
Now builds without errors on FAT filesystems (replaced .deutex and
.deusf by tmp/_deutex and tmp/_deusf).
New options
-
-doom02(implies-ipf alpha,-itf none, and-itl none) -
-doom04(implies-ipf alpha,-itf nameless, and-itl textures) -
-doom05(implies-ipf alphaand-itl textures) -
-doompr(impliesipf pr)
Doom alpha and Doom PR: it’s now possible to extract graphics, patches, sprites, and textures from those iwads. Three new options:
-ipf {normal|pr|alpha}-
Use
alphafor Doom alpha 0.2, 0.4, and 0.5.
Useprfor Doom PR (press release and beta).
Usenormalfor everything else. -itf {normal|nameless|none}-
Use
nonefor Doom alpha 0.2.
Usenamelessfor Doom alpha 0.4.
Usenormalfor everything else, including Doom alpha 0.5. -itl {normal|textures|none}-
Use
nonefor Doom alpha 0.2.
Usetexturesfor Doom alpha 0.4 and 0.5.
Usenormalfor everything else, including Doom alpha 0.5.
You shouldn’t ever have to use those options directly. It’s better to
just use -doom02, -doom04, -doom05, and -doompr, which take care
of setting ipf, itf, and itl properly for you.
Note that extracting levels and some other lumps from the Doom alpha iwads does not work yet.
Reworked the command line arguments parsing, with the following consequences.
-
Options can now be abbreviated freely, as long as the abbreviation is not ambiguous. For example, you can use
-heretic,-hereti,-heret,-hereor-herbut not-hebecause that could also be the abbreviation for-help(or-hexen, for that matter). On the other hand,-his allowed because it’s not an abbreviation (there’s really a-hoption). -
-hereticand-hexennow work (they were “hidden” by-h[elp]). -
-v@has been split in-v0,-v1…-v5because the new code does not allow excess characters after an option.-vstringwhere string is anything else than0through5now triggers an error (it used to be accepted silently). I hope no one relied on the old undocumented behaviour. -
Certain silly command line arguments that would have worked before would now trigger an error. For example, it used to be possible to type
-extramaritalor-exterminationfor-extractbut not anymore. The old code defined relatively short options (-ext) and accepted command line arguments as long as the defined option was an initial substring of the command line argument. The new code does the reverse; it defines relatively long options (-extract) and accepts command line argument as long as they’re an initial substring of the defined option.
-
Replaced direct testing of
__MSDOS__,__OS2__,__GNUC__,__BORLANDC__byDT_CCandDT_OS. This is hopefully going to make Udo’s job a bit easier. -
Now uses the same
fopen()modes for all platforms:{rw}bfor binary mode and{rw}for text mode, as per the ANSI/ISO C standard. This will fix the problem Udo Munk reported with the Cygwin build opening binary files in text mode and thus failing miserably. Note that certain DOS C compilers can be confused so that{rw}opens files in binary mode. Don’t do that! If you have problems with text files on DOS, make sure your C compiler is configured so that{rw}opens files in text mode. -
Added to the distribution archive
gifcodec.cthat I had forgotten to include (it’s not used anyway). -
Added to the distribution archive
src/{deusf,deusfos,deutex,deutexos}.defthat I had forgotten to include. I guess that’s Windows/OS/2-only stuff.
-
Updated
making.txtand renamed it asINSTALLfor homogeneity. Removed obsolete reference toalpha.shand the file itself. -
Made more legal updates.
-
Documented
DOOMWADDIRin the man page.
-
Changed the default graphics format for Unix from GIF to PPM, so that fewer user sites are broken if and when GIF support is removed. For the same reason, added a warning message when
-gifis used or the first time an image is read from a GIF file. -
Changed the lookup order for images to PPM, BMP, GIF (was BMP, GIF, PPM).
-
Fixed a couple of things that didn’t work on 16-bit platforms (real-mode DOS).
-
Now compiles on DOS with Borland C++ 4.0.
-
Now compiles on DOS with MSC 6.0. The MSC 6.0 build is functional but limited because it can’t allocate blocks larger than 64 kB, which is insufficient for certain images. I can’t use
halloc()instead ofmalloc()because it does not supporting resizing (i.e. there’s nohrealloc()function). -
In response to Udo’s remarks, DJGPP and Cygwin are now properly identified (
__DJGPP__and__CYGWIN__). -
Added sanity checks on specified-size types Int32 and friends.
-
Removed incongruous
#define-ing ofO_BINARYandSEEK_SET. -
After Udo Munk’s report, fixed warnings in
-
src/color.c(74) -
src/ident.c(583) -
src/ident.c(658) -
src/mkwad.c(78) -
src/mkwad.c(79) -
src/mkwad.c(80) -
src/mkwad.c(81) -
src/picture.c(903) -
src/picture.c(912)
-
As agreed to by Olivier Montanuy, DeuTex is now entirely GPL’d. Well,
almost entirely, since it includes code written by different authors
in lzw.c and elsewhere. Changed the notices in the source files and
added new file LICENSE to clarify things.
-
Should now work with all C compilers (removed
-WallfromCFLAGS). -
cleannow removes the DOS executables if they exist. -
Does not compile with debug information in by default anymore.
-
New targets
dall,ddt,dds,ddeutexandddeusffor compiling with debug information and all warnings. -
New target
help. -
New target
distdos.
-
Replaced
unlink()byremove()for portability. Thanks to Udo for reporting this. -
On 8.3 filesystems,
makeshould not choke ondocsrc/changes.htmlanymore. Thanks to Udo for reporting this.
-
Easier to use with Strife (now looks for
strife1.wad, new option-strife). -
Easier to use with Hexen (new option
-hexen).
-
New options
-hexenand-strife. -
New option
--version(prints version number and returns 0).
-
New options
-be,-le,-ibe,-ile,-obe, and-oleto control the endianness of the wads. Caution: don’t use them if you don’t know what you’re doing! As far as I know, wads are always little-endian regardless of the architecture of the host. Therefore, I see no reason for someone in his/her right mind to create a big-endian wad. Those options are here more for the sake of completeness than anything else. -
Made
%legal in names, to deal with Strife’sINVFONG%andINVFONY%. -
(Also graphics) End-of-flats marker is now
F_ENDby default instead ofFF_END. The reason for this change is that, withF_END, you don’t need DeuSF to get Doom to see your new flats. Should you need to, it’s still possible to getFF_ENDby using-fend.
-
The default transparent colour is now a dark blue-green (rgb:00/2f/2f). It used to be cyan (rgb:00/ff/ff) which was blindingly bright, especially compared to the usually dark colours used in Doom textures. It’s no fun to tweak shades of dark brown on a cyan background.
+ To reuse images done with/for a previous version of DeuTex, you need to either invoke DeuTex with-rgb 0 255 255or convert your images by replacing all occurrences of colour (0, 255, 255) by colour (0, 47, 47). To preserve compatibility with WinTex, I didn’t change the default transparent colour in WinTex mode; it’s still (0, 255, 255). -
Fixed segfaults due to bug in conversion of bitmap images to Doom pictures. Occured in certain 2-pixel high images such as
STBFN045in the Strife iwad. -
Now supports pictures and textures up to 509 high (was limited to 128).
-
Now supports pictures and textures up to 1024 wide (was limited to 512).
-
New option
-pfto deal with the different picture format in the Doom alpha iwad (the underlying functionality is not implemented yet!) -
Graphics: using
-ppmdoes not cause anymore DeuTex to abort withBug: *** psvit ***. -
Graphics: fixed
-ppmmessage.
-
Options can’t start with a slash (
/) anymore. I don’t think anyone used it and was a silly feature for a Unix program. -
Not case insensitive anymore.
-
Changed the wording of error messages to use “option” instead of “command”.
-
Added options
-?and--helpas synonyms for-help.
-
New option
-manto print help introff -mansource format for inclusion in the man page. -
The version number is now a free-form string.
-
Made on-line help more compact.
-
Updated
making.txt. -
Made a proper
READMEfile.
Reworked the handling of endianness. DeuTex used to deal with that
through a set of macros that swapped bytes whenever the required
endianness was not the same as the native endianness. To known the
native endianness, DeuTex relied on a macro defined via -D.
There were two problems with this scheme. Firstly, Olivier got the
meaning of “little endian” and “big endian” backwards and defining
LITTLE_ENDIAN in fact caused DeuTex to believe it was being compiled
for a big endian machine. As the glibc headers happen to define
LITTLE_ENDIAN if the machine is little endian, compiling DeuTex on a
glibc little endian Linux system was impossible unless you made changes
to the source.
The other, more fundamental, objection against the old approach is that, as it needed the user to tell it about the native endianness by modifying the makefile, it prevented unattended builds and made things difficult for naive users.
The new method eliminates this problem by using a different algorithm that does not need to know the native endianness. The end result is that you don’t have to worry about endianness anymore.