home *** CD-ROM | disk | FTP | other *** search
/ APDL Public Domain 1 / APDL_PD1A.iso / customise / texturgdn / !TexturGdn / Docs / Problems < prev    next >
Encoding:
Text File  |  1996-10-12  |  3.1 KB  |  60 lines
  1.  
  2.                                 Problems
  3.                                 ========
  4.  
  5. A list of the not-so-good "features" of this program.
  6.  
  7. The textures are not generated as functions of X and Y, but in a serial
  8. manner.  In other words, they are generated in an all-or-nothing manner.  It
  9. would sometimes be useful to produce the texture at a limited number of
  10. points, for example to see a low-resolution version of the texture which
  11. gradually increases in resolution until it is complete.  This is not
  12. possible; a problem which is connected to the use of inverse fast-fourier
  13. transforms, which are so advantageous in other ways, that a low resolution
  14. preview feature cannot be implemented without a performance hit.
  15.  
  16. No parallel processing support exists yet, though hopefully this will produce
  17. excellent speed benefits when implemented.
  18.  
  19. The program makes extensive use of self-modifying code to improve execution
  20. speed.  All the correct SWIs to ensure StrongARM compatibility have been
  21. employed, but there has not yet been any testing.
  22.  
  23. Dozens of useful texture routines have yet to be implemented.  See the
  24. "plans" file for details.
  25.  
  26. The front-end could be extended to provide control over features which are
  27. currently only accessible by the editing of texture generation files.  A
  28. proper palette editor of some kind is top of the list.  A texture properties
  29. dialogue box may be added to the main menu to offer control over various
  30. texture features, including proper layering.
  31.  
  32. Animation cannot change between two completely different textures using
  33. "key-frames" or, indeed at all.
  34.  
  35. The dithering patterns used by the program involve a number of types of
  36. simple random dithering.  The dithering used means that the same degree of
  37. dithering is used in all screen modes.  A command such as: "If
  38. IsLessThanOrEqualTo(LogBitsPerPixel,&2) Then Dithering(&4000) Else If
  39. IsEqualTo(LogBitsPerPixel,&3) Then Dithering(&2000) Else Dithering(&0)" may
  40. be used where this is inappropriate.  The dithering technique used also
  41. means things can appear with slightly different tints in 16 and 256 colour
  42. modes.  Setting the dithering to "FloydSteinberg" should make the program
  43. use Floyd-Steinberg dithering if virtual sprites are being used, but this is
  44. a feature that does not currently work.
  45.  
  46. Resizing textures partially obscured by windows means they temporarily jump
  47. to the top of the window stack.  RISC OS seems to offer little support for
  48. plotting scaled sprites clipped to windows.  Short of writing custom display
  49. routines, there seems little that can be done about this.  Still, this is
  50. not as bad as certain OSs that could be mentioned.  Also the program expects
  51. the window to remain still while texture resizing takes place.  Use of
  52. programs such as !Madness or !MoveWindo may produce some harmless confusion.
  53.  
  54. Changing the template set in use should operate in a more friendly manner.
  55.  
  56. Those using more "chunky" window furniture than the author's may find that
  57. the control window's minimum size allows the tops of the texture icons to be
  58. seen.  Those finding the efect sufficiently ugly, will find that it may be
  59. very easily remedied with the assistance of a template editor.
  60.