              GMUTILS - Possible future improvements & extensions


During my GMUTILS project, which almost lasted a year, several new features and
ideas were suggested. Some of them have already been implemented and are a part
of the utilities you now have at your disposal.

However, the features listed in this file are NOT currently available and none
of them are even implemented yet. If GMUTILS gains any greater popularity I
will, perhaps, be willing to implement some of them as Freeware. On the other
hand, it is more likely that if there is a demand for features like these I
implement most (if not all) of them and release the whole package as Shareware.

As I stated before, the only way I get to know if GMUTILS is of any use to you
is your feedback that I'm expecting (you have read README.1ST, haven't you ;)

Besides these new features that are still missing, there is always the
possibility that the existing code has bugs in it. If you encounter any bugs
within any of these utilities or if you run into strange operation that does
not comply with the documentation, I will try to fix the anomaly. With your bug
reports, please supply me with the file(s) that caused the bug(s) to surface.


AND THE POSSIBLE NEW FEATURES ARE...

First of all, I must emphasize that not one of these utilities has any "known
bogs". All of the soon described improvements are simply unimplemented features
rather than bug fixes.

The following lists all the utilities and also the improvements that have been
thought of as being realistic and useful to implement. The descriptions of
improvements appear in no specific order.


PPFIX    -Picture & Palette Fixer
         1.       An even (much) better color reduction (without dithering, of
                  course). 

                  I have figured out a method with which it should be possible
                  to reduce colors with much better results. The new method
                  would need no color component selections but would be
                  somewhat slower in execution time than the current one.

                  Currently, you need to specify a color component according to
                  which the reduction is biased.

         2.       Color reduction on unoptimized pictures.

                  Currently, it is necessary to optimize a picture prior to
                  reducing any colors.

         3.       Color concatenation with two full palettes.

                  You could thus concatenate e.g. a picture with 200 triplets
                  with another picture with 200 triplets provided that they
                  have enough identical entries which results in a final
                  palette of 256 colors at most.

                  Currently, it is not possible to concatenate pictures whose
                  palette triplets together would total more than 256. This is
                  a regrettable drawback that can sometimes be a real nuisance.
                  For example, even if you have a picture with a palette that
                  contains 129 triplets and another picture with identical
                  palette, you cannot concatenate them (129+129=258>256).

         4.       Capability to load pictures larger than one segment.

                  This feature would allow the processed pictures to be larger
                  and therefore also better graphics formats (e.g. 640x480x256,
                  800x600x256 etc.) would be supported. Improved capability to
                  handle more graphics would be accomplished by using e.g. a
                  protected mode in the utility.

                  Currently, only a graphics mode 320x200x256 is supported.
                  This is a result of DOS's typical segment boundaries that are
                  relatively difficult to deal with in the code.

         5.       Support for different picture formats (e.g. PCX, BMP etc.).

                  Currently, only LBM and RAW picture formats are supported.

         6.       Support for pictures with variable number of colors.

                  Color support would, at least, include pictures with less
                  colors than 256. The support for true color pictures is also
                  a consideration.

                  Currently, only 256-color pictures are supported.

         7.       New interactive editing mode.

                  It would be useful to construct a new mode to the existing
                  palette usage view (/U) feature. In this mode the miniature
                  picture and all the palette triplets would be visible (like
                  in /U) but the user could edit the palette with the help of
                  e.g. a mouse. Functionality could include cutting, copying
                  and pasting of selected triplets etc.

                  Currently, all editing of palette or picture data is done
                  indirectly through the use of command-line parameters. The
                  user cannot thus edit the palette specifically to suit
                  his/her needs. Also, the mentioned /U functionality is
                  currently for information purposes only.

         8.       Redundancy viewing feature.

                  Sometimes, it can be quite handy to actually see where the
                  redundant triplets and/or redundant entries are located. This
                  feature could be conveniently a part of /U feature.

                  Currently, much information can be obtained with the /U
                  feature. However, specific information on the locations of
                  redundancies is not given.

         9.       Palette matching capability.

                  Especially in game projects, it could be useful to match a
                  given bitmap with another palette. In other words, all
                  pictures have initially a palette of their own. If, however,
                  only one full general palette is used throughout a game, it
                  is inevitable to process each individual picture to match the
                  general palette as well as possible. 

                  Matching as it is described here, would require an extra
                  parameter, that would tell the maximum tolerance that is
                  allowed when the matching is performed. Otherwise, when no
                  good "close" entries are found, the matching could yield
                  exceptionally poor results. 

                  Currently, palette matching is not supported.

         10.      New optimization features.

                  I have been suggested some additional features that could be
                  added to the picture optimization.

                  Currently, the optimization features are quite extensive
                  already.

         11.      GUI (Graphical User Interface) for PPFIX.

                  After implementing all of these improvements it would be nice
                  to have a GUI to help the user to cope with all the features.
                  Of course, the regular command-line version would be
                  available as well.

                  Currently, only the command-line version of PPFIX is
                  available.


ANIME    -Animator Element
         1.       Sprite movement capability.

                  This feature would allow the user to see the sprite much the
                  same way as the sprite is seen in a "live" game. The only
                  problem is with the way the movement information is presented
                  to ANIME. With a background picture and new coordinates for
                  the sprite specified, the command-line parameters become
                  quite cryptic already.

                  Currently, sprite frames can be animated but the sprite's
                  location on the screen remains unchanged.

         2.       More sequence playing options.

                  New sequence playing options could be:
                  -playing backwards
                  -playing only selected frames

                  Current options can be found in ANIME.DOC or in on-line help.

         3.       Sprite data animation capability.

                  This feature would allow you to animate your sprite data. In
                  other words, the files you create with BOXCRS and CRSPR.BAT
                  could be animated and at the same time the sprites you have
                  in those files could be verified.

                  Currently, there is no way you can animate your sprite data
                  unless you create a sprite routine which is capable of doing
                  that. On the other hand, sprite data can be viewed with
                  BOXCRS.


BOXCRS   -Box Creators (both normal and tweaked)
         1.       Ability to convert the box (sprite) data back into legible
                  picture.

                  Currently, it is possible to view the box data back in its
                  original picture data format, but in case the original
                  picture data from which the box data was generated is
                  missing, a new "original" picture file cannot be regenerated.


FILECROP -File Cropper
         1.       A detailed parsing of command-line arguments.

                  Parsing of arguments would enable the possibility to pass
                  expressions (e.g. 23*34+55) to FILECROP. Expressions would
                  then be evaluated to form the final results out of them.
                  Parsing would e.g. make the FILECROP much nicer to use in
                  batch files (see the chapter "CRSPR - What is it?" in the end
                  of BOXCRS.DOC).

                  Currently, all parameters must be entered as plain numbers.


FILEFLIP -File Flipper
         Can't think of any improvements (unless someone needs more speed :).


BINTOC   -Binary To C
         Can't think of any improvements.


PAPA     -Parent Passer
         1.       More buffered keystrokes.

                  Currently, only one keystroke can be buffered (see help).
                  However, multiple keystroke buffering is seldom needed.

EOF