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 ?