home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 12 / CD_ASCQ_12_0294.iso / news / 2391 / form03 / docs / form.doc < prev    next >
Text File  |  1994-02-02  |  9KB  |  214 lines
  1. Sections
  2.     LEGAL STUFF AND COPYRIGHT
  3.     OUTPUT formats, and historical digression
  4.         POV
  5.         PLG
  6.         VIVID
  7.     Tools Used
  8.     BORROWED, BEGGED AND STOLEN SOURCE CODE :-).
  9.     TECHNICAL INFORMATION
  10.     REGISTRATION (Part 2)
  11.     CREDITS
  12.  
  13.  
  14. For command line switches see OPTIONS.DOC
  15. For an introduction see       TUTOR.DOC
  16. For new features see          WHATSNEW.DOC
  17.  
  18. LEGAL STUFF AND COPYRIGHT
  19.  
  20. The FORM program is not public domain software. It is copyrighted
  21. software, Copyright (C) 1993,1994 Andrew Rowbottom. It is however
  22. free software, or what some people term 'Freeware'. You may use it
  23. for whatever you wish, even using it to produce commercial pictures,
  24. animations, sculptures, deep sea diving equipment, etc. You may NOT
  25. however re-distribute modified versions of the executable nor
  26. distribute any of the files in this distribution for a profit. 
  27.  
  28. Any files in this distribution that contain a Copyright message are
  29. copyright, and may not be used as the basis for any further work,
  30. except for personal use. The images generated from input files
  31. containg a copyright message are copyrighted to the author named in
  32. the file.
  33.  
  34. None of the files in this distribution may be distributed with a
  35. magazine, or a book without the the permission of Andrew Rowbottom.
  36.  
  37. Since this software is free, it is supplied WITHOUT ANY WARRANTY;
  38. without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
  39. PARTICULAR PURPOSE. It is supplied as is, in the hope the people will
  40. find it useful.
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47. OUTPUT formats, and historical digression
  48.  
  49.     When form was originally written it was designed to output text
  50. files for input to POVRAY and to REND386, this used to be the only
  51. way to actually see what had been created, but I got fed up with the
  52. low quality of display from REND386 (although there is a lot to be
  53. said for truly real time display), and didn't have the patience to
  54. wait for a raytrace from POV every time, so I built in the screen
  55. display that you have seen and now I use it all the time.  
  56.  
  57. POV output
  58.  
  59.     Pov output from FORM goes to a file temp.pov. The output file is
  60. (usually :-) suitable for raytracing using the formvue2.pov sample
  61. file. The form is always scaled so that it fits inside a unit box for
  62. ease of placement. You can input textures inside FORM but you will 
  63. probably want to edit the output file to fine tune the textures.
  64.  
  65. FORM can now output declares for the primitives allowing you to
  66. substitute your own shapes for the inbuilt primitives. This was a 
  67. suggestion from DAN FARMER and xxxx.
  68.  
  69.  
  70. PLG output
  71.  
  72.     PLG output from FORM goes to a file temp.plg. The output file is
  73. suitable for input to rend386 (sometimes known as DEMO3 or DEMO4).
  74. This output is crude and not optimal at all. REND386 does give a fast
  75. real time display, but a problem I have had is that if the form
  76. starts getting complicated (which they do very rapidly) bits start to
  77. disappear from the screen.  
  78.  
  79. VIVID output (implemented for John Beale)
  80.     John requested VIVID output, and since I used to think VIVID was
  81. the bees knees I've implemented it. It's a bit clunky but it is
  82. functional. Testing the output from this sidetracked me for a week
  83. looking for a "bug" in VIVID that wasn't there, or anywhere for that
  84. matter (a virtual bug!). That'll teach me to accuse other peoples
  85. programs of mistakes! 
  86.  
  87. Motive
  88.  
  89.     The FORM program was started in April '93 as an excercise in
  90. using C++ and LEX and YACC it has grown from it's original modest
  91. intentions.
  92.  
  93. TOOLS USED
  94.  
  95.     The code was originally developed under DJDelories Gnu C++, but I
  96. changed to Borland's C 3.1 compiler, debugger and profiler. The
  97. source code has been kept under control by MKS RCS, which has saved
  98. the code from being completly lost twice so far. I use GNU's FLEX and
  99. BYACC, although I have had to modify the code to FLEX to provide
  100. include file capability and fix other minor incompatibilities.
  101.  
  102.  
  103. BORROWED, BEGGED AND STOLEN SOURCE CODE :-).
  104.  
  105.     Since I hate re-inventing the wheel I have in the course of this
  106. project used code from Graphics Gems (the source code not the book)
  107. and xxx's SVGAKIT.  The Graphics Gems code proved a great source of
  108. inspiration, and a good stepping stone to developing customised
  109. algorithms since I could see if the idea worked first and then
  110. rewrite for integer arithmetic.  
  111.  
  112.     SVGAKIT on the other hand is used practically as is. A very
  113. useful package for IBM PC programmers.   
  114.  
  115. TECHNICAL INFORMATION
  116.  
  117.     I have rigged the code so that integers are used for most of the
  118. drawing, giving somewhere around a five times increase in speed
  119. compared against using floating point operations on a non 486. There
  120. was a slight loss in quality, (try a single sphere at 320x200 res)
  121. but it was worth it. I may improve the quality since I now know what
  122. causes it, much rewritten code later!  Some improvement in quality
  123. has now been made in V3 , and I don't intend to change it any more except
  124. for bug fixing.
  125.  
  126.     The drawing method used is a simple polygonal ZBUFFER algorithm,
  127. with gouraud shading. The polygons are rendered using integer
  128. algoritms, including the depth, and intensity fields.  
  129.  
  130.     All other calculations in the system are performed using single
  131. precision floating point. 
  132.  
  133.     Dos memory is used for the Zbuffer unless there isn't enough at
  134. which point EMS memory is used. Failing that XMS memory is used, 
  135. this is copied to and from a single 64K cache in standard DOS memory. 
  136. This use of XMS is not the fastest possible, but what the heck - 
  137. it works!
  138.  
  139. A disk Zbuffer has now been implemented and appears to work. (Oh for
  140. FLAT virtual memory!)
  141.  
  142.     If you want to see how long form takes to parse a file run with
  143. the command line flags "-display- -plg- -pov-", no output is
  144. generated, and so the time taken is simply the load and process time.
  145.  
  146.     For those of you who are really interested the TGA file is
  147. uncompressed with a 256 colour palette. It's only TGA because that
  148. was the easiest. GIF is now my standard (ta fractint).
  149.  
  150.  
  151. REGISTRATION (Part 2)
  152.  
  153.     Personally I hate readme's that either don't tell you how to
  154. register (or even if you should), or give you half a book on the
  155. subject right at the beginning. This program is free, give it to your
  156. friends if you think they may like it. I don't charge anything for
  157. this program, it costs nothing, and is warranted to no purpose except
  158. that it will occupy some space on your hard disk/floppy until
  159. deleted. You get what you paid for.
  160.  
  161. PS. If no-one sends me e-mail, I'll conclude that this program is
  162. rubbish and probably stop development. 
  163.  
  164. PPS. Thanks to all those who sent email. Don't stop sending it or I
  165. won't develop mutations! 
  166.  
  167.  
  168. CREDITS
  169.  
  170.     The code for this program came from many sources, 
  171.  
  172.     UNIVESA and SVGAKIT came from Kendall Bennett.
  173.     FLEX the lexical analyser came from the GNU project
  174.     BYACC came from heaven knows where.
  175.     The GIF encoder is a very mutilated version of the one in
  176.     Fractint. Thanks to the stone soup team, for making their source
  177.     freely available.  ( and for sstools.ini , you should see the
  178.     junk in mine!)
  179.  
  180.     Thanks to the people who published code from Graphics Gemsxxx.
  181.     While very little of their code finally ended up in FORM many of
  182.     the display routines were originally tested using their code. The
  183.     Graphics Gems collection was a real godsend and should be in your
  184.     source code collection. It can be retreived from wuarchive.wustl.edu 
  185.     somewhere in \graphics\graphics.
  186.  
  187.  
  188.     PANTEK Ltd for allowing me to release this code.
  189.  
  190.     Stephen Todd and William Latham for the inspiration and a good book.
  191.  
  192.     Andrew Pearmund for providing a much needed get_pixel function
  193.     without which FORM couldn't save any pictures, and for breaking 
  194.     the program it every time I showed it to him.
  195.  
  196.     Sue Cunningham for being with me, and constantly praising my
  197.     feeblest efforts at creativity, and finally showing me the sort 
  198.     of form that could be created! I still feel shocked looking at
  199.     them. Most of her forms are included with release 3.00.
  200.  
  201.     Robert Fargher for being the ONLY person who sent me a FORM,
  202.     and for praising FORM. 
  203.                 Thanks.
  204.  
  205.     Dan Farmer for many suggestions and encouragement.
  206.                 Thanks also.
  207.  
  208.     All the rest of you who wrote, it's given me great encouragement.
  209.  
  210.  
  211.         rummy@snaffle.demon.co.uk
  212.  
  213.         Andrew Rowbottom
  214.