
 allready done:
 
  possibly use cpp as preprocessor for quakec (do not open the source-file
directly, instead open a pipe, into that cpp pipes (alternativly use
tempfile instead))

 future ideas:

  use zlib instead of own compression algorithm?  (already in, but only
used for png)

  make-like timestamp-updating?

  lot of dokumentation (the whole source)

  support for quake2 (some things have been done for this)

  support for the extensions of bsp/worldcraft/... like prefabs etc.

  if there are '/' in the mipmaps-name, we try to load wals instead of wads
(minor change, based upon the dir-keyword) [so it is possible to ompile
quakeII-maps for quakeI

  redefine some of the unused fields in structs for fast viewers (eg.  a
fullcolor-field in miptexs, or a group-id in wads)

  gif/pcx/bmp-support (but, I'm not the man to programm that crap)

  specify "lightcolors" in map-files for colored lights (quakeI and
quakeII), the lightmaps for colored light are saved after the normal
lightmaps, so we get get red-lightmap at "lightdatasize/4", green at
"lightdatasize/4 * 2", blue at "lightdatasize/4 * 3", that way it is
completely comatible to quake (dont forget to add lightofs)

  a basic idea to enhance the bsp-format:  after the bspheader we have room
for everything we want.  the standard-header has offsets into the file, so
quake nor any other program that READ the file, expects that eg.  the
entity-lump lies after the header.  now we build a crc-sum, or something
other union like a magic number.  we put that directly after the header.
 now if we look for an enhanced bsp-file we check that number and voila
we put everything what we want into the bsp-file.
 some ideas for extensions:
 - write the texture-strings into a lump a save them, but don't load the
textures, so we have the same capability as quakeII for quakeI, but it
doesn't work for quakeI.exe, 'cause quakeI misses the texture-lump
 - we can save the precalculated values from qview into a special lump
 - we can save the colored light-tables into a special lump instead after
the original lightmaps
 - ...

  an idea to patch a pre-processed pak-file that the bsp-files shares
textures:  first we create a wad, that contains all the textures that are
in the bsps (not in one, in all).  than we create the bsps without adding
the textures and build the pak-file.  now we post-process the bsps directly
in the pak-file (the bsps offsets to the textures exists but are -1) that
the offsets point into the location of the texture in the wad-file in the
pak-file.

  alias-lists for texture-names: we expand an array of texturenames and its
aliases "alias\0texturename\0texturepath", so life is easy if you change your
texturenames on your harddrive or want to replace the standard-textures with
your own. and it is faster than searching through all your directories all
the time.

  ...  (too much)

 suggestions are welcome!
