THIS IS A GENERATED FILE -- DO NOT EDIT !
Edit docsrc/todo.html instead.

                          To-do list for DeuTex

Directives file

  * In the directives file and textures files, "include" directive to
    include the rest of another block/file.
  * In the directives file and textures files, allow references to
    environment variables (E.G. $E(name)).
  * In the directives file and textures files, allow user variables (E.G.
    $(name))
  * Make it easier to let a texture have a description identical to
    another texture
  * In the directives file, add a mean to import all/only named/all except
    named flats as patches.
  * In the directives file, add a mean to import all/only named/all except
    named patches as flats. This implies 1) accepting flats larger than 64
    *64 (by clipping) 2) converting transparent pixels to a certain colour
    (which one ?).
  * In the directives file, add a mean to automatically generate a texture
    for all/only named/all except named patches. The height of the
    automatic texture is 128, its width is the least power of two wide
    enough to contain the patch. The automatic texture is filled with the
    patch by tiling, starting from the top left corner. The name of the
    automatic texture is the name of the patch.
  * Wherever an image is imported, give the option of applying graphical
    transforms: crop, tile, rotate, mirror, roll, colour.
  * Wherever an image is imported, give the option of composing the image
    from several files. This would be particularly useful for flats, which
    cannot be composed from several patches like textures do. This might
    complicate the wadinfo.txt syntax, though.
  * Instead of allowing any and all characters in the script file, require
    them to be quoted. And, when doing -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.
  * When composing, warn about invalid sections (E.G. "[poo]").

Game support

  * Doom alpha GNUM[0-9] :

       * find name for 10x12, preferably ending in "p" (xxx),
       * implement IDENTxxx(),
       * add [xxx] section to wadinfo.txt,
       * make list of lumps that used to go in lumps/ and now go in xxx/
         and put that in changes.html,
       * create corresponding -sprites-like option

  * When extracting the Doom alpha 0.2 iwad, "Can't find PNAMES in wad".
  * Doom alpha 0.4 and 0.5: MENUMAP is not supported.
  * DeuTex should not look for doom.wad in the directory set by -heretic !
  * Heretic: E2END is extracted with the wrong palette.
  * Hexen: does not extract graphics quite correctly (applies transparent
    colour translation to opaque images such as FINALE1 and FINALE2). This
    is probably related to [1].
  * Strife: compile scripts.
  * Strife: what else is missing ?
  * ROTT: add -rott and remove the ROTT macro.
  * ROTT: use AP_PAL instead of PAL for the Apogee thing.
  * ROTT: work on the identification (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).
  * ROTT: seems to implement lump aliases by pointing to the same offset
    as an other lump. All lumps but the last have a zero size.

Graphics

  * The presence of the GIF routines might push DeuTex into the non-free
    section of Debian. Would it be sufficient to #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.

  * Bug: some flats seem to be extracted with certain pixels set to the
    transparent colour (Doom's CEIL4_1). DeuTex 3.6 for DOS exhibits the
    same problem [1].
  * Building seems to be slower than extracting. Perhaps RAWtoPIC() could
    use some optimization.
  * Include the Gimp and PSP palettes in the distribution.
  * For people who have old graphics files generated by DeuTex 3 with cyan
    (0, 255, 255) as the transparent colour : it would be nice if DeuTex 4
    could import those files automatically. The way I see it, if no
    transparent pixel has been found in an image so far and if a cyan
    pixel is found, a warning is emitted ("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.
  * Sneas are supported when doing -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...

Sound

  * Regarding audio support, Matthew W. Miller <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:
      [1]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.

  * Fix this :

 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.

  * Look into importing sounds as .wav's. What are the highest supported
    sample rates and resolution ? Seems to depend on the engine.

Command line

  * The command line interface is not always intuitive and it's fussy
    about the position of certain options. -iwad seems to be ineffective
    if placed last. -xtract and friends must be placed last if they don't
    have all their arguments.
  * Options shouldn't care whether there is space between them and their
    argument. Hmm... or should they ?
  * -check shouldn't require an argument. It should use the iwad by
    default.
  * -main should be implemented for DeuTex as well.
  * Matthew Miller wants to be able to specify the name of the iwad
    instead of just its path (this is how it should have been done from
    the start, IMHO). Possible ways to do that :

       * stat() the argument to -doom, -heretic, etc. If it's a file and
         not a directory, use that.
       * Look for a different basename in the iwad directory, depending on
         the option through which the directory was specified. E.G. if it
         was set with -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.
       * Add an option to specify the name of the iwad file, without
         specifying which iwad it is and let DeuTex guess what needs to be
         guessed. Apparently, there's already such an option (-main) but
         it's for DeuSF only. Why ?

  * Add -V (equivalent to --version). Include the URL of the original
    distribution archive ?

Documentation

  * It's in shambles.
  * Mention that negative patch Y-offsets are forced to 0 by the engine.
  * Mention that sneaps are extracted but not built.
  * Man page: mention that some options are DeuTex-only, not DeuSF.
  * Document the messages. What I have in mind :

 $(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.$>
 )

    which expands to :

 Warning("Sneeze %s: %f dB > 100 dB, bad for straw huts",
fname (pathname), strerror (errno));

    and :

 .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.

Platform

  * Borland C: to revive the port, must find a way to make all pointers
    implicitly huge.

Misc.

  * TBD: New options -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
  * Why does "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 ?).
  * The dependencies on deutex.h are missing in the makefile.
  * Integrate AJA's patch compression patch.
  * Change text file line numbers from shorts to longs.
  * If you -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 ?

References

Visible links
1. http://www.compsoc.man.ac.uk/~maniac/resource_web/wav_file_format/