home *** CD-ROM | disk | FTP | other *** search
/ Amiga ACS 1998 #4 / amigaacscoverdisc1998-041998.iso / utilities / shareware / workbench / fblit / wbtunnel / wbtunnel.doc < prev    next >
Encoding:
Text File  |  1997-12-18  |  4.4 KB  |  145 lines
  1.  
  2. WBTunnel 0.4a
  3. -------------
  4. The entire contents of this archive remain © Stephen Brookes 1997, but may
  5. be freely distributed.
  6.  
  7.  
  8.  
  9. Hmmm
  10. ----
  11. You use this software at your own risk, I will accept no responsibility for 
  12. any undesirable effects resulting from the use of any software or
  13. information in this archive. If you don't accept this, don't use the
  14. software.
  15.  
  16.  
  17.  
  18. Requirements
  19. ------------
  20. To run this you will need at least an 020+ processor and probably V39.
  21. Developement machine is 040 and V39, no other has been tested!
  22.  
  23.  
  24.  
  25. Usage
  26. -----
  27. Double click the lovely blitzy icon. You can play with the window, change
  28. from RTG/Chip mode, get a palette allocation (slighty random and not good
  29. on shallow screens) and you can quit. Funky stuff.
  30.  
  31. New in 0.3a, you can also turn on/off the random shape changes with the
  32. menus morph option, and attract the tunnel to your mouse in the window
  33. (while selected).
  34.  
  35.  
  36.  
  37. OverView
  38. --------
  39. This is just some pointless code to test out the feasability of running
  40. stuff in a window, in a fashion that might work on RTG systems.
  41.  
  42. There is no double buffering. Even when running at high speed in RTG mode
  43. you will see some glitches/artifacts caused by the usual things (crossing
  44. the live raster, being interupted by... ummm... well, interrupts).
  45.  
  46. ICBA doing a backdrop for it, or making it allways render to the window
  47. edge (it's only 32bit aligned) so it's not even very pretty to look at.
  48.  
  49. RTG mode will NOT work on a standard amiga! It may even be dangerous,
  50. though I doubt it. If you want to try RTG mode on standard mig, you must
  51. install 'FBlit', or other hack that allows intuition images to be rendered
  52. from fast RAM. Without 'FBlit' you will also get unbearable colour flicker!
  53.  
  54. Note that there may be little difference between Chip and RTG mode on
  55. shallow screens, and with small windows.
  56.  
  57. This also uses 'PRend24'. Anyone else looking at using that code should
  58. see also the bug report in this archive!
  59.  
  60.  
  61.  
  62. Strewth! That's slow.
  63. ---------------------
  64. Excuses to be dog slow.
  65.  
  66. - the code that generates the scene is crummy, slow Basic.
  67. - the scene often contains over 200 surfaces.
  68. - the scene is allways rendered in 256 colours.
  69. - my CPU is faster than yours.
  70. - big window. 320*256 is equivalent to full screen low-res 256 colour
  71.   rendering before you even start the image->screen render.
  72. - PRend is a 32bit renderer, images are 16bit structures.
  73. - Chip mode will be real slow on anything but the most modest screen mode.
  74. - No partial updates are done.
  75.  
  76. Note that the scene->image render is not effected much by running in RTG
  77. mode (unless you have really fast CPU) due to the way PRend works. Only the
  78. image->screen render time is really effected in this code.
  79.  
  80. Speed is just about bearable on 704*564*6bit DblPal with 320*256 window and
  81. fblit installed (RTG mode) on here.
  82.  
  83. Speed is limited by only one 'vwait' call per loop (see end of doc for
  84. update on this), so it may steal most of your cycles, but task priority is
  85. at -10 so it shouldn't be too bad. More important, multi-tasking is
  86. suspended during the actual 'DrawImage' call and in extreme cases this can
  87. take seconds! (eg. 800*600 window on 8bit screen in Chip mode)
  88.  
  89.  
  90.  
  91. Bugs
  92. ----
  93. None known, but given the state of some of the scene generation code in
  94. here... ;)
  95.  
  96.  
  97.  
  98. Future
  99. ------
  100. No point, no future.
  101.  
  102.  
  103.  
  104. Past
  105. ----
  106.  
  107. v0.1a
  108. -----
  109. Initial release.
  110.  
  111. v0.2a
  112. -----
  113. Internal
  114.  
  115. v0.3a
  116. -----
  117. - scene generation code rebuilt with several preset tunnel shapes, instead
  118.   of badly generated on-the-fly circle.
  119. - occasional random shape change added. ('morph' option in the menu)
  120. - tunnel now chases the mouse arround in the window, if window is
  121.   currently selected.
  122. - speed is now limited (hopefully) to 50/3 frames per second (maybe 60/3 if
  123.   that's your mains frequency).
  124. - point projection routine converted to asm.
  125. - virtual screen is now square (meaning shapes will appear slightly
  126.   squashed in your average rectangular window)
  127. - grid resolution increased to 13*12 (264 surfaces)
  128. - the new, angular, shapes introduce a minor 'artifact' that I am NOT going
  129.   to deal with. You may notice, at sharp edges, some punch-through from
  130.   surfaces that should be hidden.
  131. - altered green palette to make it a little less horrible.
  132.  
  133. v0.4a
  134. -----
  135. This is identical to the 0.3a release, except 'FBlit' has been removed from
  136. the archive.
  137.  
  138.  
  139.  
  140. Send feedback to...
  141.  
  142. Stephen Brookes (2:258/4.15) (*** NOTE *** 2:259/2.15 is no longer valid,
  143.                               but may still appear elsewhere in this archive!)
  144. sbrookes@tpec.u-net.com
  145.