The old music identification code assumed that any lump whose name
does not begin with either "D_" or "MUS_"
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 the lumps/ directory. DeuTex even tried
to interprete STALKR and WINNOWR as pictures
and said silly things about them having a "width greater than 4096".
The new code really checks whether the lump begins with
"MUS\x1a" instead of just looking at its name. A lump is
now deemed to be a music if and only if it begins with
"MUS\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 either
"D_" or "MUS_" is a music, their semantics
might have changed. If you find they don't do what you want, try again
using the -musid option and let me know whether it
improves your condition.
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 the levels/ pwad, starting from the level
label. Previously, it included at most the 11 following lumps, and only
if they had the expected names (THINGS,
VERTEXES and so on).
But, basically, if the levels/ pwads contain, as they
should, all the needed lumps and nothing else, there shouldn't be any
trouble.
Bug: *** idinx (12) ***" when trying to include the
graphic lumps (resp. CREDIT, E2END,
FINAL1, FINAL2, HELP1,
HELP2, TITLE and CREDIT,
FINALE1, FINALE2, FINALE3,
HELP1, HELP2, INTERPIC,
TITLE). More generally, DeuTex now accepts to compose wads
even when there are graphic files in lumps/.
Height of FLAT
./flats/x_001.ppm is not 64 or 65" when trying to include flats
X_001 through X_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.
quantisation is slow"
warnings now appear at most once.
<count> warnings
omitted" message, added optional scope prefix and changed the
picture extraction function to use it.
[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.After some summary testing, looks like it's fixed.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.
ftruncate() being undeclared when
compiling with DJGPP and updated the building-on-DOS section of the
doc.
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.
deutex --vers".
-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 me decide which index should be used to store
the transparent colour for Hexen.
Can't read WAD" error whenever it had to read more
than 65535 bytes from a wad at once.
stdout before writing to
stderr so that messages come out in the right order when
both outputs are redirected.
-pkgfx,
-pknormal and -usedtex.
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 :
-strife10"
(or "-tf normal"),
-strife"
(or "-tf strife11").
Thanks to Kim Parrott for reporting the bug and Len Pitre for pointing me in the right direction.
.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.
-sneas, -sneaps and
-sneats.
huge" on the
theory that, on platforms where it's meaningful, we always use the
huge memory model anyway.
Int32" by
"iolen_t".
256" by
"NCOLOURS".
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.
lumps/ are now properly extracted (into
sneaps/ and sneats/). Still extracted as
lump : HUFONT.
-di to debug entry
identification. Useful mainly to hackers.
wadinfo.txt and in the phase messages.
Creating PWAD" and
"WAD is complete..." during level extraction.
-doom2 as suggested by Matthew
Miller.
Failed to write sprite" errors when trying to extract
PSYBA0 and PSYBB0 from
strain.wad. Thanks to Matthew miller for reporting the
bug.
.deutex and .deusf by
tmp/_deutex and tmp/_deusf).
DSVILACT
and DSVILSIT from ncc1701.wad, with a sample
rate of 44.1 kHz). Thanks to Matthew Miller for reporting the
bug.
-doom02 (implies -ipf alpha,
-itf none and -itl none)
-doom04 (implies -ipf alpha,
-itf nameless and -itl textures)
-doom05 (implies -ipf alpha and
-itl textures)
-doompr (implies -ipf pr)
Use those options where you would have used -doom and
friends. For example, to extract the contents of the Doom 0.4 iwad
that is in c:\doom0_4, type "deutex -doom04
c:\doom0_4 -xtract".
Int32
by long.
old/readme.txt. It's so out of date
that it's more confusing than useful.
-ipf {normal|pr|alpha}
alpha for Doom alpha 0.2, 0.4 and 0.5.pr for Doom PR (press release pre-beta).normal for everything else.
-itf {normal|nameless|none}
none for Doom alpha 0.2.nameless for Doom alpha 0.4.normal
for everything else, including Doom alpha 0.5.
-itl {normal|textures|none}
none for Doom alpha 0.2.textures for Doom alpha 0.4 and 0.5.normal for everything else, including Doom alpha 0.5.
You shouldn't ever have to use those options directly. It's better
to use just -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.
-heretic, -hereti, -heret,
-here or -her but not -he
because that could also be the abbreviation for -help
(or -hexen, for that matter). On the other hand,
-h is allowed because it's not an abbreviation
(there's really a -h option).
-heretic and -hexen now work (they
were "hidden" by -h[elp]).
-v@ has been split in -v0,
-v1 ... -v5 because the new code does not
allow excess characters after an option.
-vstring where string is anything
else than "0" through "5" now triggers an
error (it used to be accepted silently). I hope no one relied on the
old undocumented behaviour.
-extramarital or
-extermination for -extract but 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.
__MSDOS__,
__OS2__, __GNUC__,
__BORLANDC__ by DT_CC and
DT_OS. This is hopefully going to make Udo's job a
bit easier.
fopen() modes for
all platforms: "{rw}b" for 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 configured
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.
gifcodec.c that I had forgotten to include (it's
not used anyway).
src/{deusf,deusfos,deutex,deutexos}.def that I had
forgotten to include. I guess that's Windows/OS/2-only stuff.
making.txt and renamed it as
INSTALL for homogeneity. Removed obsolete reference
to alpha.sh and the file itself.
DOOMWADDIR in the man page.
-gif is used or the first time an image is
read from a GIF file.
halloc() instead of malloc()
because it does not supporting resizing (i.e. there's no
hrealloc() function).
__DJGPP__ and
__CYGWIN__).
Int32 and friends.
#define-ing of
O_BINARY and SEEK_SET.
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)
making.txt.
lzw.c
and elsewhere. Changed the notices in the source files and added
new file LICENSE to clarify things.
-Wall from CFLAGS).
clean now removes the DOS
executables if they exist.
dall,
ddt, dds, ddeutex
and ddeusf for compiling with debug
information and all warnings.
help.
distdos.
unlink() by
remove() for portability. Thanks to Udo for
reporting this.
docsrc/changes.html anymore. Thanks to Udo for
reporting this.
sound.c.
strife1.wad", new option "-strife").
-hexen").
-hexen" and
"-strife".
--version" (prints
version number and returns 0).
-help" and "-man" and elsewhere.
fclose (NULL).
-be, -le,
-ibe, -ile, -obe and
-ole to 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.
%" legal in names, to deal with
Strife's "INVFONG%" and
"INVFONY%".
F_END by default instead of FF_END.
The reason for this change is that, with F_END, you
don't need DeuSF to get Doom to see your new flats. Should you
need to, it's still possible to get FF_END by using
-fend.
To reuse images done with/for a previous version of DeuTex,
you need to either invoke DeuTex with "-rgb 0 255
255" or 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).
STBFN045 in the Strife iwad.
-pf" to deal with the
different picture format in the Doom alpha iwad (the underlying
functionality is not implemented yet !)
-ppm does not cause anymore
DeuTex to abort with "Bug: *** psvit ***".
-ppm" message.
.wav files on big endian machines has been
squashed.
/") anymore. I don't think anyone used it and was
a silly feature for a Unix program.
-?" and
"--help" as synonyms for "-help".
-man" to print help in
troff -man source format for inclusion in the man
page.
making.txt".
README file.
unix" target as
"strip".
install".
dist".
-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.
TXTinit(), removed useless
"% 0xFF" in index of TXTval.