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

      implement --wide-view, that displays the textures not only as is, but in
    all mipmap-states and simple lighting too.

 partially done:

      support for quake2 (some things have been done for this)
    
      loading/saving of models
  
      ilbm/gif/pcx/bmp-support (but, I'm not the man to programm that crap
    , some has been done, but not everything)
  
      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.

 rejected:

      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.
     -> Quake does not load the whole PAK, and the offsets are only valid for
        the mipmap area, not even for the bsp-area
    
 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 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 compile
    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)
  
      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 and 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
     - ...
  
      make the subdivision configureable in libqdisplay, at 0 the results must
    be amazing

      implement hooks into light/rad that execute if new lightmap has been
    created (could be used for visualisation of lights/rads behaviour)

      maybe give light/rad the possibility to calculate only specific triangles
    or intervals of triangles (could be used for recalculating all triangles
    that are visible in a bsp-display, and render them again)
    
      make submodels to be displayed by DisplayBSP
      
      make anim-textures to be displayed by DisplayBSP
      
      try to replace all Error by eprintf and clean cleanup
      
      implement '$'-commands into qcc

      remove all map-specific stuff out of bspmemory and vice versa
    thats only texinfo, so go through mapmemory all the time, and save
    them to the bspmemory at FinishBSP, must be set before SubdivideFace!
    (->SolidBSP) and before vis/light/rad but they are no problem

      check for alloca in configure
      
      entities are the only map-resources in light/rad, maybe simplify them
      
      allow the "bsps", "_bsps" keyword in maps to load textures directly out of
    bsps in addition to wads and dirs
    
 ...  (too much)

 suggestions are welcome!
