home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 6 / AACD06.ISO / AACD / System / FBlit / ReadMe.doc < prev    next >
Text File  |  1999-10-02  |  6KB  |  180 lines
  1.  
  2. FBlit 3.51a
  3. -----------
  4. 'FBlit' and it's associated files are © Stephen Brookes 1997-99
  5.  
  6.  
  7.  
  8. Blah
  9. ----
  10. This software is experimental, incomplete and fundamentaly dangerous, so
  11. don't use it! I will take no responsibility for any undesirable effects
  12. resulting from the use of any software or information in this archive.
  13.  
  14.  
  15.  
  16. Distribution
  17. ------------
  18. This archive is freely distributable. The latest version is available from
  19. <http://www.tpec.u-net.com>. Please ensure that you have the latest release
  20. from that address before reporting bugs.
  21.  
  22.  
  23.  
  24. Requirements
  25. ------------
  26. 020+ CPU
  27. v39+ (OS3.0)
  28. Fast RAM
  29.  
  30. The GUI also requires MUI.
  31.  
  32.  
  33.  
  34. Installation
  35. ------------
  36. Copy 'FBlit' and 'FBlitGUI' to 'C:'.
  37. Copy 'fblit.library' to 'Libs:'.
  38.  
  39. Or, copy the whole drawer anywhere you like...
  40.  
  41. Add the following line to 'S:startup-sequence' before anything else that
  42. may patch gfx functions, and after anything that may patch memory
  43. functions. Just before 'BindDrivers' is usually ok.
  44.  
  45. C:FBlit
  46.  
  47. (or <path to FBlit drawer>FBlit)
  48.  
  49. If updating a previous FBlit installation, you should also 'delete
  50. ENVARC:fblit.cfg' to restore the default configuration before rebooting.
  51.  
  52. Notes:
  53.  
  54. FBlit should *not* be launched with 'run' (or 'asyncrun', 'runback' or
  55. anything like that)! Doing so may cause patch order problems with CGX,
  56. NewIcons etc.
  57.  
  58. If FBlit's OSTLPatch is installed (it is by default), you may have to
  59. launch FBlit before any bootpic software, or use PatchControl (or equiv'),
  60. but FBlit should not be installed before ENV: & ENVARC: have been assigned.
  61.  
  62. Do not try to rename the FBlit files ;) If you change the name of
  63. 'fblit.library', 'FBlit' or 'FBlitGUI', things may not function as
  64. expected!
  65.  
  66. A related point. FBlit currently generates *no* error output. If it fails,
  67. it will do so silently (or with a guru).
  68.  
  69.  
  70.  
  71. Usage
  72. -----
  73. The GUI is invoked by launching FBlit a second time.
  74.  
  75.  
  76.  
  77. What's this?
  78. ------------
  79. This is a public test version of FBlit. There is no new documentation yet
  80. so if you don't know what this is about, please download FBlit v2.45a and
  81. have a look at the doc's in that archive, but be aware that much of the
  82. detailed information in that is not applicable to current versions.
  83.  
  84. These versions are intended to run with FAllocBitMap set to 'exclude' mode
  85. (in the GUI), so you may want to try that ('include' mode is still the
  86. default), but it is a little risky so be prepared for trouble! Exclude mode
  87. is not really recommended unless you have a fair grasp of what FBlit
  88. actually does and the possible side-effects (also, a recent backup of any
  89. valuable data is a good idea) ...re-read the 'Blah' section above.
  90.  
  91. For those I haven't put off yet... There are a couple of known issues with
  92. exclude mode. Line related corruption problems, caused by the incomplete
  93. FDraw() patch are more common, but these are harmless and, for the most
  94. part, bearable. Voyager's task 'V' (up to, at this time, V³pre2) will go
  95. down in flames if promoted, when displaying scaled images, so it is
  96. advisable to add 'V' to the 'exclude task' list if you use Voyager. I have
  97. also had reports of corruption (safe) with DOpus' internal animation
  98. viewer.
  99.  
  100.  
  101.  
  102. More blah
  103. ---------
  104. The current temporary FDraw() patch is rather limited in that it won't do
  105. patterned, or complement mode lines. It is also inaccurate and slow. None
  106. of these things cause much trouble in day to day use, but they can create
  107. (safe) graphics corruption under certain circumstances! (especially if it
  108. is set to process all chip data)
  109.  
  110.  
  111.  
  112. 3.36...
  113.  
  114. FText() has gone, hopefully without any fallout. You can still accelerate
  115. text functions to some extent by setting FBltTemplate() to process chip
  116. data.
  117.  
  118.  
  119. 3.40...
  120.  
  121. Hmmm. The rules for FAreaEnd()'s discard operation have changed
  122. (VisualPrefs etc. should now work).
  123.  
  124. FDraw() and FBltPattern() are still incomplete :/
  125.  
  126. OSTLPatch is a new patch. It checks any custom bitmap supplied to
  127. OpenScreenTagList(), and if this bitmap is not in chip RAM, it attempts to
  128. reallocate it with #BMF_DISPLAYABLE. This should solve the problem of
  129. multiview opening custom screens in fast RAM with certain datatypes.
  130.  
  131.  
  132. 3.47...
  133.  
  134. ditto FDraw() and FBltPattern().
  135.  
  136. This version contains a new system to deal with RTG NewIcons. Any BOB image
  137. which is found to be in fast mem will be copied back to chip mem. The rest
  138. is left up to the OS to deal with (ie. BOBs are again rendered on the
  139. blitter). This also means that BOBs will use chip mem while they are
  140. dragged, and they may dissapear (or become corrupt under extremes) when
  141. there is very little chip mem left. The only likely downside of this, is
  142. that it takes time (when the 'drag' is started) to copy the BOB images back
  143. to chip, and that may be significant when large numbers of BOBs are dragged
  144. on slower processors.
  145.  
  146.  
  147. 3.51...
  148.  
  149. FBltBitMap() has a new option to check the stack size of the calling task.
  150. This is really just a debug feature for my own use. If enabled, output will
  151. be generated when the calling tasks free stack falls below a threshold,
  152. this is set at $200 (512 bytes) and is NOT user definable (unless you hack
  153. the library). No other action will be taken. Output is in the form of
  154. 'enforcer' hits, so you will need to run 'enforcer', 'cyberguard',
  155. 'muforce' or whatever to see it. The hits are identified by several
  156. features. They are caused by a long read from $0, and originate in
  157. 'fblit.library'. Also, d0 will contain $c0ded00d. d1 will contain the tasks
  158. current free stack space, negative values may indicate stack overflow. The
  159. fact that no output is generated does not prove that you will not have
  160. stack problems, it simply shows (probably!) that there is sufficient stack
  161. at a certain point (ie. when calling BltBitMap()). Equally, if you do get
  162. hits (and you almost certainly will), it does not necessarily mean you have
  163. a problem, though 512bytes is sailing pretty close to the wind
  164. (FBltBitMap() itself requires arround 256bytes ($100)). Also, some things
  165. (eg. NewIcons, and many other 'E' programmes) have messed up stack
  166. parameters which may generate hits.
  167.  
  168. FDraw() is still incomplete but everything else is basically finished
  169. (other than documentation).
  170.  
  171. There are no known problems with this version, other than line related
  172. issues on promoted gfx.
  173.  
  174.  
  175.  
  176. Contact
  177. -------
  178.  
  179.  Stephen Brookes        <sbrookes@tpec.u-net.com>
  180.