home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6188 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Scrolling only selected bitplanes
  5. Date: 25 Mar 1996 16:36:42 +0100
  6. Organization: dis-
  7. Message-ID: <4j6eia$16r@serpens.rhein.de>
  8. References: <3155e4a7@beachyhd.demon.co.uk>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. Adam@beachyhd.demon.co.uk writes:
  12.  
  13. >However, I *am* having to scroll the screen using ScrollRaster(), where in the
  14. >ol' hardware bashing days I would have directly manipulated the bpl pointers.
  15.  
  16. Well, even in the old hardware bashing days you couldn't do the same
  17. without blitting. Both are different operations and you can even do
  18. both through the OS.
  19.  
  20. >Why can't we have OS control over blitplane addressing?
  21.  
  22. We do, to some degree. Scrolling a whole bitmap by changing the
  23. bitplane pointers is no problem. Scrolling on a line-by-line
  24. basis is not supported.
  25.  
  26. >allowed to access the h/w registers to set them to point to these addresses. A
  27. >system hardware.library (or whatever) would allow me to do this in a fully
  28. >system friendly way.
  29.  
  30. No. This would definitely not be system friendly. The system has to
  31. present the hardware to all programs. This can only work in an
  32. acceptable manner if it provides some abstraction. So it doesn't let
  33. you change bitplane addresses but let you specify a scroll position.
  34. The scroll position is abstract enough to be interpreted by different
  35. hardware and you can even have some virtual display. Bitplane addresses
  36. are not abstract.
  37.  
  38. >Similarly, we could use a 3d.library (for vector graphics), chunky.library (for
  39. >chunky operations), etc.etc. If these were written using the most optimal
  40. >techniques possible, and supported and updated, they could solve a lot of the
  41. >Amigas problems..
  42.  
  43. Well, even a 3d.library or chunky.library had to be based on graphics
  44. operations. Nothing prevents you from writing your own 3d routines and
  45. use graphics for the display.
  46.  
  47. Regards,
  48. -- 
  49.                                 Michael van Elst
  50.  
  51. Internet: mlelstv@serpens.rhein.de
  52.                                 "A potential Snark may lurk in every tree."
  53.