home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / amiga / programm / 11437 < prev    next >
Encoding:
Text File  |  1992-07-21  |  2.2 KB  |  63 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!caen!uri.csmil.umich.edu!chymes
  3. From: chymes@uri.csmil.umich.edu (Charles Hymes)
  4. Subject: Impulse FORM TDDD is crummy. was: IFF 3D standard? (DR3D?)
  5. Message-ID: <tKR-ft_@engin.umich.edu>
  6. Date: Tue, 21 Jul 92 12:45:04 EDT
  7. Organization: Cognitive Science and Machine Intelligence Lab, U. of MIichigan
  8. References: <1992Jul21.135437.1@economics.adelaide.edu.au> <1992Jul21.055017.2772@wam.umd.edu>
  9. Keywords: n
  10. Nntp-Posting-Host: uri.csmil.umich.edu
  11. Lines: 50
  12.  
  13.  
  14. Impulse's FORM TDDD is a crummy IFF is I heartily incourage is
  15. upgrading. My promlem with it is that while it is a LEAGL IFF it is a
  16. NON-STANDARD IFF. It is non-standard to the point that
  17. parseiff.library is won't read any of its chunks. The problem is that
  18. it has sub-chunks and sub-sub chunks, without any of the encapulating
  19. FORMs LISTs or PROPs. TDDD's look like this:
  20. FORM TDDD
  21.     OBJ
  22.         DESC
  23.             PNTS
  24.             EDGE
  25.             FACE
  26.             ...
  27.         TERM
  28.     ...
  29.  
  30. When it should look like this:
  31.  
  32. LIST TDDD
  33.     FORM OBJ
  34.         FORM DESC
  35.             PNTS
  36.             EDGE
  37.             FACE
  38.             ...
  39.         TERM            
  40.     ....
  41.  
  42. The problem is that IFFParse.library never enters the contents of a
  43. chunk. So to it, (and any other IFF reader that is not TDDD specific)
  44. a TDDD is only made of one large OBJ chunk, which it will never parse
  45. again. If the TDDD form was standard, iffparse could decend into each
  46. sub chunk, and retreve the ones wanted ones, perserving context and
  47. all that jazz. To parse TDDDs, one has to treat OBJ chunks and DESC chunks as
  48. seperate, *NON STANDARD* IFF files, and parse each seperately. This is
  49. what I have done. I wrote a TDDD reader that reads uses Iffparse to
  50. get each OBJ chunk, copys the chunk to a buffer and prefixes "FORM
  51. TDDD" and the size to each OBJ, calls iffparse on each (now-legal) OBJ
  52. chunk, gets each DESC sub-chunk, prefixes "FORM TDDD" and the size to
  53. each DESC chunk, and finally one can then get at the data for the 3d
  54. objects. Yuck. 
  55.  
  56. One could argue that the problem is with Iffparse, but this is not the
  57. case. A standard IFF should expicitly state which chunks are
  58. sub-chunks, and not expect the parser to look inside each chunk and
  59. guess that it is a sub-chunk becuse the first four bytes happen to be
  60. upper case ASCII. That is what FORM LIST, and PROP chunks are for.
  61.  
  62. Charweed Hymerfan
  63.