deutex-4.4.902/ 0000755 0003245 0003245 00000000000 10305373426 012573 5 ustar aym aym 0000000 0000000 deutex-4.4.902/docsrc/ 0000755 0003245 0003245 00000000000 10305373425 014047 5 ustar aym aym 0000000 0000000 deutex-4.4.902/docsrc/README 0000644 0003245 0003245 00000003524 10301444222 014721 0 ustar aym aym 0000000 0000000 DeuTex $VERSION DESCRIPTION DeuTex and DeuSF are programs than can do many things with Doom, Heretic, Hexen and Strife wad files such as extracting and inserting graphics, sounds, levels and other resources. See the manual for details (dtexman6.txt). BUILDING AND INSTALLING ON UNIX You need a reasonably standard Unix environment with a C compiler. The first step is to type ./configure If you need to install somewhere else than /usr/local, give ./configure the --prefix option. For example, to install in ~/deutex, ./configure --prefix ~/deutex The C compiler is auto-detected. If the auto-detection does not find your compiler, use the --cc option : ./configure --cc ~/mycc-1.2.3/mycc The default CFLAGS is "-O2 -Wall" for GCC, "-O" for other compilers. The default LDFLAGS is empty. To override these, you can use the --cflags and/or the --ldflags options. For example, ./configure --cflags '-O2 -m64' --ldflags '-m64' After ./configure completes successfully, type make Finally, type make install Note that you will need to type this last command as root if you're installing in /usr/local or some other "system" directory. BUILDING AND INSTALLING ON DOS See INSTALL. LEGAL DeuTex is Copyright Olivier Montanuy 1994-1995 and Copyright André Majorel 1999-2005 and available under the terms of version 2 of the GPL, except lzw.c which is Copyright David Koblas and others and available under the terms of the PBMPLUS license. See the LICENSE file. All trademarks are the property of their owners. CONTACT Home page : http://www.teaser.fr/~amajorel/deutex/ Doom questions : news:rec.games.computer.doom.editing DeuTex questions : The Yadex mailing list (http://www.teaser.fr/~amajorel/yadex/lists.html) -- AYM $SELF_DATE deutex-4.4.902/docsrc/changes.html 0000644 0003245 0003245 00000103641 10305347506 016353 0 ustar aym aym 0000000 0000000
make
compatibility: removed all occurrences
of "$<
" not in inference rules in the makefile.
make
compatibility: removed all
"\
" followed by empty lines.
On NCR MP-RAS, make
quotes all empty lines that
follow !
./configure
" script (GNU autoconf
work-alike).
Installing somewhere else than /usr/local
is now done by
giving ./configure
the --prefix
option.
CC
, CFLAGS
and LDFLAGS
are now
auto-detected.
The defaults can be overridden by passing ./configure
the --cc
, --cflags
and
--ldflags
options.
The fixed-size types (Int16
etc.) are now correctly set
on all LP64 platforms, not just Alpha.
char[8]
were used as char[9]
(caught by NCR/MetaWare cc
on NCR MP-RAS).
//
" comments that
had slipped into the source.
static
but defined
as extern
(caught by NCR/MetaWare cc
on NCR
MP-RAS).
static
- and const
-correctness fixes.
Legal()
function.
--help
and the man page, divided the options into
groups and sorted them alphabetically within each group.
It seems to be clearer that way.
tr .@ +=
).
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.
PLAYPAL
.
Previously, DeuTex always used the PLAYPAL
from the iwad
when building.
It now uses the one in lumps/
if it exists.
Thanks to Ras2 for reporting the problem.
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 in COLdiff()
.
The time to rebuild the Strife iwad is down from 8.6s to 7.2s (16%
faster).
#ifdef
QUANTSLOW
).
Line n: Illegal char
'*'
".
Z_Malloc
.
1024×128 textures make Doom freeze in R_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.
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.).
Misc: at the request of Kim "Sparky" Parrott, all messages are now
copied to a file named "deutex.log
"
("deusf.log
" for DeuSF).
The default log file name can be overridden through the
"-log
" option.
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
, --version
etc. do not create a log.
-rate
to specify what DeuTex should do
when including sound files whose sample rate is not exactly
11025 Hz.
The choices are :
reject
force
warn
accept
force
". It's now "warn
".
Thanks to Matthew W. Miller for telling me about this issue (which he did in 1999 ; the six-year delay is mine, all mine).
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 :
After some summary testing, looks like it's fixed.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.
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
.
CREDIT
, E2END
, FINAL1
,
FINAL2
, HELP1
, HELP2
and
TITLE
extracted into lumps/
and not into
graphics/
?
They're extracted into lumps/
because that's what they are.
The graphics/
directory is for images that are in the in the
so-called "picture" format, described in section [5-1] of the UDS (HTTP link).
Those lumps are not in picture format, they're just straight bitmaps (320
× 200 pixels, 64,000 bytes).
The distinction may seem academic, but it isn't.
If those lumps were extracted into graphics/
, it would be
impossible to compose your wad correctly afterwards.
In the wad created by DeuTex, CREDIT
and friends would be in
the picture format while the engine expects them to be in the 64000-byte
matrix format.
CREDIT
, FINALE1
, FINALE2
,
FINALE3
, HELP1
, HELP2
,
INTERPIC
and TITLE
extracted into
lumps/
and not into graphics/
?
See question 1.
This is what happens when you try to use DeuTex 4 on files extracted by DeuTex 3 or WinTex.
It happens because DeuTex 3 and WinTex use (0, 255, 255) (cyan) for transparent areas while DeuTex 4 uses (0, 47, 47) (dark blue-green). Therefore, what looks like a transparent pixel to DeuTex 3 and WinTex just looks like an opaque, cyan pixel to DeuTex 4. The closest match to cyan in the Doom palette is (115, 115, 255) (blue-mauve) so that's what you get.
Try one of the following :
-rgb 0 47 47
"
option,
-rgb 0 255 255
" option.
lumps/
.
This has been fixed in version 4.4.
No. Though it would certainly be nice to have.
AYM 2005-08-29
deutex-4.4.902/docsrc/hackers_guide.html 0000644 0003245 0003245 00000005062 10304554306 017533 0 ustar aym aym 0000000 0000000Some files contain numbers that have a fixed endianness, independent from the endianness of the CPU DeuTex happens to run on. These call for some special treatment, as the C language has no provision for reading and writing integers otherwise than in the native endianness.
To read an integer from a file with a particular endianness, use
fread_i16_le()
, fread_i16_be()
,
fread_i32_le()
and fread_i32_be()
.
The first argument is the file descriptor, the second argument is a
pointer on a variable that will receive the value read from the file.
To write an integer to a file with a particular endianness, use
fwrite_i16_le()
, fwrite_i16_be()
,
fwrite_i32_le()
and fwrite_i32_be()
.
The first argument is the file descriptor, the second argument is the
value to write.
To read an integer with a particular endianness from a memory area,
use read_i16_le()
, read_i16_be()
,
read_i32_le()
and read_i32_be()
.
The first argument is a pointer on the memory area, the second
argument is a pointer on a variable that will receive the value read
from the memory area.
Alternatively, you can use the peek_i*()
functions that
take no second argument but instead return the read value.
To write an integer with a particular endianness to a memory area,
use write_i16_le()
, write_i16_be
,
write_i32_le()
and write_i32_be()
.
The first argument is a pointer on the memory area, the second
argument is the value to write.
Mnemonic to remember the arguments order : the object that has a defined endianness is considered central and therefore always comes first.
Here is some sample code and the result of running it.
fwrite_i32_be (stdout, 0x12345678); fwrite_i32_le (stdout, 0x12345678); fwrite_i16_be (stdout, 0xabcd); fwrite_i16_le (stdout, 0xabcd);
12 34 56 78 78 56 34 12 AB CD CD ABdeutex-4.4.902/docsrc/readme.dos 0000644 0003245 0003245 00000002225 10301444206 016004 0 ustar aym aym 0000000 0000000 DeuTex $VERSION - DOS binary distribution WHAT ARE DEUTEX AND DEUSF DeuTex and DeuSF are programs than can do many things with Doom, Heretic, Hexen and Strife wad files such as extracting and inserting graphics, sounds, levels and other resources. See the manual for details (dtexman6.txt). This is a binary distribution. It only contains a DOS pre-compiled executable and the user documentation. The source and the rest of the documentation are in deutex-$VERSION.tar.gz. INSTALLING Copy deutex.exe and deusf.exe in a directory of your PATH. LEGAL DeuTex is Copyright Olivier Montanuy 1994-1995 and Copyright André Majorel 1999-2005 and available under the terms of the GPL, except lzw.c which is Copyright David Koblas and others and available under the terms of the PBMPLUS license. See the LICENSE file. All trademarks are the property of their owners. CONTACT Home page : http://www.teaser.fr/~amajorel/deutex/ Doom questions : news:rec.games.computer.doom.editing DeuTex questions : The Yadex mailing list (http://www.teaser.fr/~amajorel/yadex/lists.html) -- AYM $SELF_DATE deutex-4.4.902/docsrc/todo.html 0000644 0003245 0003245 00000035102 10305107536 015701 0 ustar aym aym 0000000 0000000
include
" directive
to include the rest of another block/file.
$E(name)
).
$(name)
)
-xtract
, produce the script file with the
appropriate quotes...
Since, under Unix, the only characters that are not allowed in a file name
are NUL and "/
", I don't see why DeuTex should prevent users
from extracting lumps with weird characters in their names.
However, that might cause compatilibity problems with the DOS version.
[poo]
").
GNUM[0-9]
:
IDENTxxx()
,
[xxx]
section to wadinfo.txt
,
lumps/
and now go in
xxx/
and put that in changes.html
,
-sprites
-like option
Can't find PNAMES in
wad
".
MENUMAP
is not supported.
doom.wad
in the directory set by
-heretic
!
E2END
is extracted with the wrong palette.
FINALE1
and
FINALE2
).
This is probably related to [1].
-rott
and remove the ROTT
macro.
AP_PAL
instead of PAL
for the Apogee
thing.
ANIMSTRT
,
EXITSTRT
, EXITSTOP
, ABVWSTART
,
ABVMSTRT
, HMSKSTRT
, GUNSTART
,
ELEVSTRT
/ELEVSTOP
,
DOORSTRT
/DOORSTOP
,
SIDESTRT
/SIDESTOP
,
MASKSTRT
/MASKSTOP
,
UPDNSTRT
/UPDNSTOP
,
SKYSTART
/SKYSTOP
,
SKYSTART
/SKYSTOP
,
ORDRSTRT
/ORDRSTOP
,
ORDRSTRT
/ORDRSTOP
,
SPECMAPS
,
PLAYMAPS
SHAPSTRT
/SHAPSTOP
,
DIGISTRT
/DIGISTOP
,
SONGSTRT
,
PCSTRT
/PCSTOP
,
ADSTRT
/ADSTOP
).
#ifdef
them out ?
Determine why converting Doom graphics to PPM and back does not yield the same thing. This also happens with BMP but much less so.
Update 2000-01-04 : for example, with Heretic, patch
WALL17
has its (4Eh, 50h, 4Dh) pixels turned into (4Eh, 4Eh,
4Eh).
It seems DeuTex sometimes uses a close match even when an exact match
exists.
PPM and GIF do not agree with each other.
An extract/build round trip on the Ultimate Doom iwad does not produce
the same wad on DOS as it does on Unix because the default format on DOS
is GIF.
If you extract with -ppm
on DOS, you do get the same wad you
do on Unix.
CEIL4_1
).
DeuTex 3.6 for DOS exhibits the same problem [1].
RAWtoPIC()
could use some optimization.
Warning:
xxxxxxxx.xxx: assuming the transparent colour is cyan.
") and the
transparent colour for this image is set to cyan.
This would make for a smooth transition from DeuTex 3 to DeuTex 4.
There should be a command-line switch to disable that feature.
-xtract
but not when doing
-build
(they're ignored).
Fix that, or at least mention it somewhere.
Though I don't see many people wanting to make wads for Doom alpha
anyway...
mattm=infinet+com
> offered the following comment on
1999-07-04 :
Audio handling in deutex (I'm referring to the irix 5.3 version's included source code) is, I believe, based on dmgraph, but is pretty dire in any case.
[...]
Also, one would hope that eventually one or more of the source ports will start to support bitrates other than 8 bit, and (maybe?) stereo samples. You may want to start leaning on various source ports' programmers to get their acts together and start coming to some sort of agreement. ;)
Importation of .wav files is pretty crufty. Like dmgraph before it, the deutex 5.3 source expects there to be just one big 'data' chunk, and doesn't notice the 'info' chunks that certain stupid Windows programs (*cough*cough*CoolEdit*GoldWave*cough*) insist on putting in (usually with copyright messages for the program itself, which in a just world would be illegal). Greater explanation of all this whacky chunk business can be found at:
http://www.compsoc.man.ac.uk/~maniac/resource_web/wav_file_format/
(wav1.htm, wav2.htm, wav3.htm, 4.htm, 5.htm)Essentially, you want to clip out the first 'data' chunk and ignore crap like 'info', 'inam', 'list', or whatever.
atc4:/doom/dev/test/wav/16$ deutex -doom /doom/doom -xtract ../16bit44k.wad DeuTex 4.0.3 Main directory: /doom/doom. Extracting entries from WAD ../16bit44k.wad Reading WAD /doom/doom/doom.wad: (2306 entries) Reading WAD ../16bit44k.wad: (1 entries) PWAD entry identification...done Color palette is Doom Warning: ** Appending to file ./wadinfo.txt ** Extracting Levels... Extracting Lumps... Extracting Sounds... Bug: *** not a WAVE *** Please report that bug.
-iwad
seems to be ineffective if placed last.
-xtract
and friends must be placed last if they don't have all
their arguments.
-check
shouldn't require an argument.
It should use the iwad by default.
-main
should be implemented for DeuTex as well.
stat()
the argument to -doom
,
-heretic
, etc.
If it's a file and not a directory, use that.
-doom2
, look for doom2.wad
first.
And if doom2.wad
was not found, emit a warning.
-doom
and -heretic
should look for all
basenames because that's what previous versions of DeuTex did.
-main
) but
it's for DeuSF only.
Why ?
-V
(equivalent to --version
).
Include the URL of the original distribution archive ?
which expands to :$(msg AB34 w "Sneeze %{name}s: %{num}f dB > 100 dB, bad for straw huts" $("fname (pathname)" "strerror (errno)") $<Sneeze $p name is louder than 100 dB. Versions of House lesser than Wood will collapse.$> )
and :Warning("Sneeze %s: %f dB > 100 dB, bad for straw huts", fname (pathname), strerror (errno));
.TP \fBAB34 Sneeze \fIname\fB: \fInum\fB dB > 100 dB, bad for straw huts\fR Sneeze \fIname\fP is louder than 100 dB. Versions of House lesser than Wood will collapse.
-fstart
and -fend
to control the
start-of-flats and end-of-flats markers used in pwads.
Default to FF_START
and F_END
respectively.
Warning: here again, don't use those options just because
they're here.
The default markers are perfectly fine, and they conform to the de-facto
standard.
If you deviate from them, you're asking for trouble.
-f_end
deutex -ipf alpha -doom .. -sprites -graphics -patches
-xtract
" trigger "Error: *** Can't open file
./lumps/titlepic.lmp ***
" ?
todo.html
grows faster than changes.html
.
Fix that. ;-)
-usedidx
: don't count sneats (-nosneats
?).
deutex.h
are missing in the makefile.
-xtract
doom.wad twice then build, you get either a
PA90 bug or a wad that's twice as big as the original.
PrintInit()
is called way too late.
All error messages relative to parsing the command line will be written to
standard error, not the specified file (asFile
).
Options that set asFile
should be honour in the first pass.
The fact that Info()
, Detail()
and
Phase()
write to standard output is wrong if you take the
stance that the real distinction between stdout and stderr is not
information vs. error but "data to be processed by the next filter in the
pipe" vs. "messages to be read by a human".
If so, need to check that all uses of Output()
are indeed
"pipeable".
Also, is it right to copy Output()
to the log ?