home *** CD-ROM | disk | FTP | other *** search
-
- 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))
-
- 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.
-
- 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 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.
-
- ... (too much)
-
- suggestions are welcome!
-