File: todo.html

package info (click to toggle)
deutex 4.4.902-10
links: PTS
area: main
in suites: etch, etch-m68k, lenny
size: 1,096 kB
ctags: 996
sloc: ansic: 10,805; sh: 424; makefile: 337; perl: 145; csh: 4
file content (471 lines) | stat: -rw-r--r-- 14,914 bytes
parent folder | download | duplicates (4)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
    <title>To-do list for DeuTex</title>
    <meta http-equiv="Content-Style-Type" content="text/css">
    <style type="text/css">
      p {
	margin-bottom:		0.5em;
	margin-top:		0.5em;
      }
      pre {
	margin-bottom:		0.5em;
	margin-top:		0.5em;
      }
      blockquote {
	margin-bottom:		0.5em;
	margin-top:		0.5em;
      }
      ul > li {
	margin-bottom:		0.5em;
	margin-top:		0.5em;
      }
    </style>
  </head>
<body>

	<h1>To-do list for DeuTex</h1>

		<h2>Directives file</h2>

<ul>
  <li>
    In the directives file and textures files, "<code>include</code>" directive
    to include the rest of another block/file.

  <li>
    In the directives file and textures files, allow references to environment
    variables (E.G. <code>$E(name)</code>).

  <li>
    In the directives file and textures files, allow user variables (E.G.
    <code>$(name)</code>)

  <li>
    Make it easier to let a texture have a description identical to another
    texture

  <li>
    In the directives file, add a mean to import all/only named/all except
    named flats as patches.

  <li>
    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&times;64 (by clipping) 2)
    converting transparent pixels to a certain colour (which one&nbsp;?).

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

  <li>
    Wherever an image is imported, give the option of applying graphical
    transforms: crop, tile, rotate, mirror, roll, colour.

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

  <li>
    Instead of allowing any and all characters in the script file, require them
    to be quoted.
    And, when doing <code>-xtract</code>, 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 "<code>/</code>", 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.

  <li>When composing, warn about invalid sections (E.G. "<code>[poo]</code>").
</ul>

		<h2>Game support</h2>

<ul>

  <li>Doom alpha <code>GNUM[0-9]</code>&nbsp;:
    <ul>
      <li>find name for 10x12, preferably ending in "p" (xxx),
      <li>implement <code>IDENTxxx()</code>,
      <li>add <code>[xxx]</code> section to <code>wadinfo.txt</code>,
      <li>
	make list of lumps that used to go in <code>lumps/</code> and now go in
	<code>xxx/</code> and put that in <code>changes.html</code>,
      <li>create corresponding <code>-sprites</code>-like option
    </ul>

  <li>
    When extracting the Doom alpha 0.2 iwad, "<code>Can't find PNAMES in
    wad</code>".

  <li>Doom alpha 0.4 and 0.5: <code>MENUMAP</code> is not supported.

  <li>
    DeuTex should not look for <code>doom.wad</code> in the directory set by
    <code>-heretic</code>&nbsp;!

  <li>Heretic: <code>E2END</code> is extracted with the wrong palette.

  <li>
    Hexen: does not extract graphics quite correctly (applies transparent
    colour translation to opaque images such as <code>FINALE1</code> and
    <code>FINALE2</code>).
    This is probably related to [1].

  <li>Strife: compile scripts.

  <li>Strife: what else is missing&nbsp;?

  <li>ROTT: add <code>-rott</code> and remove the <code>ROTT</code> macro.

  <li>
    ROTT: use <code>AP_PAL</code> instead of <code>PAL</code> for the Apogee
    thing.

  <li>
    ROTT: work on the identification (<code>ANIMSTRT</code>,
    <code>EXITSTRT</code>, <code>EXITSTOP</code>, <code>ABVWSTART</code>,
    <code>ABVMSTRT</code>, <code>HMSKSTRT</code>, <code>GUNSTART</code>,
    <code>ELEVSTRT</code>/<code>ELEVSTOP</code>,
    <code>DOORSTRT</code>/<code>DOORSTOP</code>,
    <code>SIDESTRT</code>/<code>SIDESTOP</code>,
    <code>MASKSTRT</code>/<code>MASKSTOP</code>,
    <code>UPDNSTRT</code>/<code>UPDNSTOP</code>,
    <code>SKYSTART</code>/<code>SKYSTOP</code>,
    <code>SKYSTART</code>/<code>SKYSTOP</code>,
    <code>ORDRSTRT</code>/<code>ORDRSTOP</code>,
    <code>ORDRSTRT</code>/<code>ORDRSTOP</code>,
    <code>SPECMAPS</code>,
    <code>PLAYMAPS</code>
    <code>SHAPSTRT</code>/<code>SHAPSTOP</code>,
    <code>DIGISTRT</code>/<code>DIGISTOP</code>,
    <code>SONGSTRT</code>,
    <code>PCSTRT</code>/<code>PCSTOP</code>,
    <code>ADSTRT</code>/<code>ADSTOP</code>).

  <li>
    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.
</ul>

		<h2>Graphics</h2>

<ul>
  <li>
    The presence of the GIF routines might push DeuTex into the non-free
    section of Debian.
    Would it be sufficient to <code>#ifdef</code> them out&nbsp;?

  <li>
    <p>
      Determine why converting Doom graphics to PPM and back does not yield the
      same thing.
      This also happens with BMP but much less so.
    </p>

    <p>
      Update 2000-01-04&nbsp;: for example, with Heretic, patch
      <code>WALL17</code> 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.
    </p>

    <p>
      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 <code>-ppm</code> on DOS, you do get the same wad you
      do on Unix.
    </p>

  <li>
    Bug: some flats seem to be extracted with certain pixels set to the
    transparent colour (Doom's <code>CEIL4_1</code>).
    DeuTex 3.6 for DOS exhibits the same problem [1].

  <li>
    Building seems to be slower than extracting.
    Perhaps <code>RAWtoPIC()</code> could use some optimization.

  <li>Include the Gimp and PSP palettes in the distribution.

  <li>
    For people who have old graphics files generated by DeuTex 3 with cyan (0,
    255, 255) as the transparent colour&nbsp;: 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 ("<code>Warning:
    xxxxxxxx.xxx: assuming the transparent colour is cyan.</code>") 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.

  <li>
    Sneas are supported when doing <code>-xtract</code> but not when doing
    <code>-build</code> (they're ignored).
    Fix that, or at least mention it somewhere.
    Though I don't see many people wanting to <em>make</em> wads for Doom alpha
    anyway...
</ul>

		<h2>Sound</h2>

<ul>
  <li>
    Regarding audio support, Matthew W. Miller
    &lt;<code>mattm=infinet+com</code>&gt; offered the following comment on
    1999-07-04&nbsp;:

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

      <p>
        [...]

      <p>
	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. ;)

      <p>
	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:
	<a href="http://www.compsoc.man.ac.uk/~maniac/resource_web/wav_file_format/"
	><code
	>http://www.compsoc.man.ac.uk/~maniac/resource_web/wav_file_format/</code
	></a> (wav1.htm, wav2.htm, wav3.htm, 4.htm, 5.htm)

      <p>
	Essentially, you want to clip out the first 'data' chunk and ignore
	crap like 'info', 'inam', 'list', or whatever.
    </blockquote>

  <li>
    Fix this&nbsp;:
    <pre>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.</pre>

  <li>
    Look into importing sounds as .wav's.
    What are the highest supported sample rates and resolution&nbsp;?
    Seems to depend on the engine.
</ul>

		<h2>Command line</h2>

<ul>
  <li>
    The command line interface is not always intuitive and it's fussy about the
    position of certain options.
    <code>-iwad</code> seems to be ineffective if placed last.
    <code>-xtract</code> and friends must be placed last if they don't have all
    their arguments.

  <li>
    Options shouldn't care whether there is space between them and their
    argument.
    Hmm... or should they&nbsp;?

  <li>
    <code>-check</code> shouldn't require an argument.
    It should use the iwad by default.

  <li><code>-main</code> should be implemented for DeuTex as well.

  <li>
    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&nbsp;:

    <ul>
      <li>
	<code>stat()</code> the argument to <code>-doom</code>,
	<code>-heretic</code>, etc.
	If it's a file and not a directory, use that.

      <li>
	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 <code>-doom2</code>, look for <code>doom2.wad</code> first.
	And if <code>doom2.wad</code> was not found, emit a warning.
	<code>-doom</code> and <code>-heretic</code> should look for all
	basenames because that's what previous versions of DeuTex did.

      <li>
	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 (<code>-main</code>) but
	it's for DeuSF only.
	Why&nbsp;?
    </ul>

  <li>
    Add <code>-V</code> (equivalent to <code>--version</code>).
    Include the URL of the original distribution archive&nbsp;?
</ul>

		<h2>Documentation</h2>

<ul>
  <li>It's in shambles.

  <li>Mention that negative patch Y-offsets are forced to 0 by the engine.

  <li>Mention that sneaps are extracted but not built.

  <li>Man page: mention that some options are DeuTex-only, not DeuSF.

  <li>
    Document the messages.
    What I have in mind&nbsp;:

    <blockquote>
      <pre>$(msg AB34 w
  "Sneeze %{name}s: %{num}f dB &gt; 100 dB, bad for straw huts"
  $("fname (pathname)" "strerror (errno)")
  $&lt;Sneeze $p name is louder than 100 dB.
  Versions of House lesser than Wood will collapse.$&gt;
)</pre>
    </blockquote>

    which expands to&nbsp;:

    <blockquote>
      <pre>Warning("Sneeze %s: %f dB &gt; 100 dB, bad for straw huts",
  fname (pathname), strerror (errno));</pre>
    </blockquote>

    and&nbsp;:

    <blockquote>
      <pre>.TP
\fBAB34 Sneeze \fIname\fB: \fInum\fB dB &gt; 100 dB, bad for straw huts\fR
Sneeze \fIname\fP is louder than 100 dB.
Versions of House lesser than Wood will collapse.</pre>
    </blockquote>

</ul>

		<h2>Platform</h2>

<ul>
  <li>
    Borland C: to revive the port, must find a way to make all pointers
    implicitly huge.
</ul>

		<h2>Misc.</h2>

<ul>
  <li>
    TBD: New options <code>-fstart</code> and <code>-fend</code> to control the
    start-of-flats and end-of-flats markers used in pwads.
    Default to <code>FF_START</code> and <code>F_END</code> respectively.
    <strong>Warning:</strong> 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.
  </li>

  <li>
    <code>-f_end</code>
  </li>

  <li>
    Why does "<code>deutex -ipf alpha -doom .. -sprites -graphics -patches
    -xtract</code>" trigger <code>"Error: *** Can't open file
    ./lumps/titlepic.lmp ***</code>"&nbsp;?
  </li>

  <li>
    <code>todo.html</code> grows faster than <code>changes.html</code>.
    Fix that. <code>;-)</code>
  </li>

  <li>
    <code>-usedidx</code>: don't count sneats (<code>-nosneats</code> ?). 
  </li>

  <li>
    The dependencies on <code>deutex.h</code> are missing in the makefile.
  </li>

  <li>
    Integrate AJA's patch compression patch.
  </li>

  <li>
    Change text file line numbers from shorts to longs.
  </li>

  <li>
    If you <code>-xtract</code> doom.wad twice then build, you get either a
    PA90 bug or a wad that's twice as big as the original.
  </li>

  <li>
    <code>PrintInit()</code> is called way too late.
    All error messages relative to parsing the command line will be written to
    standard error, not the specified file (<code>asFile</code>).
    Options that set <code>asFile</code> should be honour in the first pass.
  </li>

  <li>
    <p>
      The fact that <code>Info()</code>, <code>Detail()</code> and
      <code>Phase()</code> 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".
    </p>

    <p>
      If so, need to check that all uses of <code>Output()</code> are indeed
      "pipeable".
      Also, is it right to copy <code>Output()</code> to the log&nbsp;?
    </p>
  </li>

</ul>


</body>
</html>