home *** CD-ROM | disk | FTP | other *** search
/ Gold Fish 3 / goldfish_volume_3.bin / files / fish / disks / d1104.lha / Programs / Image2C / i2c.doc < prev    next >
Text File  |  1995-03-19  |  6KB  |  161 lines
  1. Image2C 1.2
  2. Copyright © 1994,1995 Udo Schuermann
  3. All rights reserved
  4.  
  5. This program converts an image in an IFF FORM ILBM to a 'C' struct Image
  6. structure which you can use as part of your C programming projects.  The
  7. program is not intended (in its present form) for creation of sprites or
  8. raw bitplane data, although you are welcome to improve it.  If you do, I
  9. would much appreciate if you sent me the revised code!
  10.  
  11. Image2C accomplishes a number of things which I have time and again found
  12. to be important to me, but have somehow not found in quite the right form
  13. elsewhere:
  14.  
  15. 1. You get to specify your own "key" string on the command line by which
  16.    the source code's identifiers are prefixed.  The program does not make
  17.    any "guesses."  Whatever you specify is added as a prefix, and nothing
  18.    else.  You can specify a null string, such as "" whereby no prefix is
  19.    added.
  20.  
  21. 2. You get to specify exactly what you want included in the file.  You can
  22.    also include everything and have the program add #ifdef/#endif around
  23.    the sections so you can define LATER what you want to actually use
  24.    without having to reconvert the image.
  25.  
  26. 3. The program uses the iffparse.library as part of a demonstration of
  27.    how to extract image information.  It was my goal to learn how to do
  28.    this properly, especially since CITAS 2.0 failed to properly handle
  29.    6-bitplane images (this was the ultimate reason why I wrote Image2'C')
  30.  
  31. 4. Image2C adds the __chip identifier automatically, unless you specify
  32.    the NOCHIP flag.  This permits you to store image data in Fast RAM,
  33.    and use some pen-remapping functions to recolor the image; the new
  34.    image would then end up in Chip RAM without having the original waste
  35.    space there.
  36.  
  37. 5. The information is nicely and intelligently formatted.  No mess!  :-)
  38.    It should, therefore, be easy to understand (i.e. makes a good learning
  39.    tool) and, depending on your own skill, easy to modify, too!
  40.  
  41. In its simplest form, Image2C could be used as part of a Makefile in the
  42. following manner:
  43.  
  44. ---------------------------------------------------------------------------
  45. MyImages.o:    Image1.c Image2.c Image3.c Image4.c\
  46.         Image5.c Image6.c Image7.c\
  47.         MyImages.c
  48.     sc MyImages.c
  49.  
  50. Image1.c:    Image1.IFF
  51.     i2c Image1.IFF Image1_ >Image1.c
  52.  
  53. Image2.c:    Image2.IFF
  54.     i2c Image2.IFF Image2_ >Image2.c
  55.  
  56. Image3.c:    Image3.IFF
  57.     i2c Image3.IFF Image3_ >Image3.c
  58. ...etc.
  59. ---------------------------------------------------------------------------
  60.  
  61.  
  62. Your file MyImages.c could be something as simple as this:
  63.  
  64. ---------------------------------------------------------------------------
  65. #include "MyImage1.c"
  66. #include "MyImage2.c"
  67. #include "MyImage3.c"
  68. ...etc.
  69. ---------------------------------------------------------------------------
  70.  
  71.  
  72. Now you can modify your .IFF files to your heart's content and each time
  73. you run 'smake' (or make) all altered .IFF files will be reconverted to .c
  74. files with unique "ImageX_" prefixes in their headers.
  75.  
  76.  
  77. The program uses the following CLI template.  I am parsing this on my own,
  78. without help from the system's own libraries (so shoot me!)
  79.  
  80. ILBMFILE/A,SYMPREFIX/A,NOINFO/S,NOPENS/S,NODATA/S,NOIMAGESTRUCT/S,
  81.     NORGB4/S,USEIFDEFS/S,NOCHIP/S
  82.  
  83. ILBMFILE/A        Must always be given.  This is the IFF ILBM input
  84.             file to be converted.  I2C supports images up to
  85.             8 bitplanes deep (actually, any bitplane oriented
  86.             ILBM)
  87.  
  88. SYMPREFIX/A        Must always be given.  The symbol prefix for this
  89.             image file.  This forms the prefix to all symbols
  90.             in the file.
  91.             Example:  A prefix of "myImage_" will generate
  92.             symbols such as "UWORD myImage_ImageData[]"
  93.  
  94. NOINFO/S        This switch will cause image information, such
  95.             such as height, width, depth, number of colors
  96.             to be omitted.  See also NOIMAGESTRUCT below!
  97.  
  98. NOPENS/S        This switch will cause pens (used by LoadRGB32()
  99.             for example) to be omitted.
  100.  
  101. NODATA/S        This switch will cause the actual image data to
  102.             be omitted.  See also NOIMAGESTRUCT below!
  103.  
  104. NOIMAGESTRUCT/S        This switch will cause a "struct Image ..." item
  105.             to be omitted.  This item requires the presence
  106.             of INFO and DATA items; if you specify that either
  107.             or both of those should not be included (NOINFO
  108.             and/or NODATA) but you do not also specify the
  109.             NOIMAGESTRUCT, then I2C will reverse your decision
  110.             on NOINFO and/or NODATA so that the Image struct
  111.             can be built.
  112.  
  113. ADDRGB4/S        This switch will cause register color values to
  114.             be added.  Such values are 12-bit only and are
  115.             probably of use only for older software.  It is
  116.             for this reason that this is the only switch that
  117.                 needs to be specified to add something to the
  118.             code; i.e. if not specified you will NOT get the
  119.             information for this item.
  120.  
  121. USEIFDEFS/S        This switch encloses the INFO, PENS, DATA, IMG,
  122.             and RGB4 sections with #ifdef/#endif constructs
  123.             to allow you to build a source file with ALL
  124.             information, but decide at a later time which
  125.             portions the compiler should include or ignore.
  126.             Use of this switch enables an additional level
  127.             of flexibility, which you may or may not find
  128.             of use.
  129.  
  130.             The following #define statements used BEFORE you
  131.             #include the source code generated by I2C will
  132.             tell the compiler which portions of the file to
  133.             use and which to ignore:
  134.  
  135.             #define I2C_IMAGE_INFO        Accept image info
  136.             #define I2C_IMAGE_PENS        Accept RGB32 pens
  137.             #define I2C_IMAGE_RGB4        Accept 4-bit pens
  138.             #define I2C_IMAGE_DATA        Accept image data
  139.             #define I2C_IMAGE_IMG        Accept struct Image
  140.  
  141. NOCHIP/S        Omit the __chip attribute on structures.  This may
  142.             be desirable if you are going to remap image colors
  143.             anyway and won't be needing the original in chip
  144.             RAM.
  145.  
  146. If you are not clear on some of the points described above, you are hereby
  147. STRONGLY advised to run the program on a test image and see what the
  148. resulting output file contains.  Try this:
  149.  
  150.     I2C  TestImage.IFF  MyTest_  USEIFDEFS
  151.  
  152. Some limitations:
  153.  
  154.    · Image2C does not support optimization to eliminate bit planes of all
  155.      1's or all 0's.
  156.  
  157. Cheers!
  158.  
  159.  ._.  Udo Schuermann
  160.  ( )  walrus@wam.umd.edu
  161.