home *** CD-ROM | disk | FTP | other *** search
/ Fujiology Archive / fujiology_archive_v1_0.iso / !FALCON / LINEOUT / OUT.ZIP / SOURCE.ZIP / FLOW_DSP.TXT < prev    next >
Text File  |  2002-07-17  |  5KB  |  128 lines
  1.                  Human Fly 2.1 - DSP implementation schematics
  2. ============================================================================
  3.  
  4. Functional specifics:
  5.  
  6. This implementation is meant mostly for speed, not for flexibility. Hence
  7. when the implementation is not upto the task it will return errorcodes
  8. as specified in the interface. There are however some pending limitations
  9. described in the section further on.
  10.  
  11. The rendering pipeline has the following functions:
  12. - X/Y culling: removes all out of the viewcone
  13. - Z culling: removes all behind camera
  14. - Painters algorithm sorting
  15. - Parallel processing stages (see pipeline specs.)
  16. - Bitmap cacheing (see limitations)
  17.  
  18. Pipeline specifics:
  19.  
  20. This is built up by two parallel pipelines: the cpu and dsp ones. The main
  21. purpose of the cpu line is handling both I/O and housekeeping tasks. The dsp
  22. takes care of almost everything related to 3d arithmetic.
  23.  
  24. Both lines operate in parallel most of the time, but ofcourse need a sync
  25. each rendering cycle. This is done in two places:
  26. 1) when the commands are passed from cpu to dsp
  27. 2) when the dsp passes rendered data back to the cpu for it to output
  28.  
  29. Parallel execution is the main reason for the speed of this implementation. 
  30.  
  31.  CPU                                | DSP
  32. ------------------------------------+---------------------------------------
  33.  0a sending objects, tables (synced)| 0b receiving objects, tables (synced)
  34. ....................................|....................................... 
  35.  1a command sending (synced)        | 1b command storage (synced)
  36.  2a restoring screenarea            | 2b 3d object transformation
  37.                                     | 3b painters algorithm sorting
  38.  3a output of primitives (synced)   | 4b sending primitives to cpu (synced)
  39.  
  40. Pipeline stages explained:
  41.  
  42. 0a: Sends 3d objects and bitmaps to the cpu. Note that the dsp might return
  43.     an errorcode. This indicates the dsp has not got enough room. The
  44.     application should send less big objects or textures. Using the rest of
  45.     the pipeline after an error might result in unpredictable results.
  46.  
  47. 0b: Receives objects and textures from the cpu. There is no parsing of
  48.     objects. Passing invalid objects might result in unpredicatable
  49.     behaviour. Take note that the dsp has limited space.
  50.  
  51. 1a: Sending rendering commands to the dsp. This ranges from rotation and
  52.     translation to depthsorting.
  53.  
  54. 1b: Receives rendering commands and stores them. It is possible to overflow
  55.     the command-buffer. Beware!
  56.  
  57. 2a: This is ofcourse application-specific. This may use the bounding areas
  58.     calculated in a previous cycle (see 3a).
  59.  
  60. 2b: Executes stored commands in consecutive order. All vertex/vector
  61.     transformations are done and also various forms of culling. Take note
  62.     this stage might overflow dsp buffers!
  63.  
  64. 3a: Receives primitive data from dsp and outputs it to the viewport. Also
  65.     bounding rectangles are sent and are required to be read by the cpu(!).
  66.     The whole primitive reception is synchronized.
  67.  
  68. 3b: Sorts the primitive-index-table with a combsorting algorithm. This means
  69.     less than linear performance! This is in-place and hence does not
  70.     overflow anything.
  71.  
  72. 4b: This sends primitives and bounding rectangles to the cpu. Polygon-
  73.     clipping is done on dsp, line- and sprite-clipping on cpu. This stage
  74.     is synchronized.
  75.  
  76. Limitations:
  77.  
  78. There are numerous. The dsp has little memory, so object and scene
  79. complexity are limited. Let's start with the biggest drawbacks:
  80.  
  81. - Viewport width = [1..384] (*)
  82. - Viewport height = [1..256] (*)
  83. - amount of scene (transformed) objects =< 32
  84. - total size stored untransformed objects =< 8192 words
  85. - amount of transformed vertices =< 700 (*)
  86. - amount of transformed primitives =< 1000
  87. - total commandlist size (per cycle) =< 512 words
  88.  
  89. Quite some limitations. That is the tradeoff for parallel processing. Make
  90. sure neither the commandlist nor the vertex/primitive buffering limits of
  91. the dsp are exceeded or this may cause unpredictable results!
  92.  
  93. Since the dsp is responsible for texturing it can cache some small bitmaps
  94. for faster rendering. It can also be set to send offsets when it is
  95. initialized in stage 0. This way bitmaps are kept on the cpu side. The
  96. dsp bitmap storage space:
  97.  
  98. - 2 64*64 highcolor bitmaps
  99. - 2 64*64 7bpp bitmaps
  100.  
  101. All may be present in the dsp ram at the same moment.
  102.  
  103. * : You may alter these to finetune the viewportsize<->scene complexity
  104.     tradeoff.
  105.  
  106. Rendering specifics:
  107.  
  108. Perspectivation uses a multipass inverse-table algorithm. This is not as
  109. accurate as a normal division, but is over twice as fast. The error is below
  110. 1%. Renderings might appear upto 1% smaller than they should be.
  111.  
  112. Primitives are painted in two manners:
  113. a) cpu paints primitive with vertices given by the dsp
  114. b) cpu paints a polygon given entirely by the dsp
  115.  
  116. (a) is used for lines, sprites and flat polygons
  117. (b) is used for shaded polygons
  118.  
  119. The use of (b) is the speedgain using the dsp for interpolation algorithms.
  120. This mode draws n-polys without splitting them into triangles. Hence the
  121. texturing-slopes are recalculated with every scanline.
  122.  
  123. Special:
  124.  
  125. Enough (only barely) dsp ram is left to allow a small dsp-loader and
  126. interrupt-routine to be present along with audio-mixage functions. I used it
  127. with the exa-mixer and it worked fine.
  128.