home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / amiga / programm / 11504 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  1.5 KB
  1. Path: sparky!uunet!mcsun!uknet!axion!spuddy!spark
  2. From: spark@spuddy.uucp (Steve)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: MakeScreen(); RethinkDisplay() vs. MakeVPort(); MrgCop(); LoadView()
  5. Message-ID: <1992Jul22.192458.5966@spuddy.uucp>
  6. Date: 22 Jul 92 19:24:58 GMT
  7. References: <1b5c1b9e.ARN5a25@moria.UUCP> <paulk.0ucw@terapin.com>
  8. Organization: Spuddy's Public Usenet Domain
  9. Lines: 29
  10.  
  11.  
  12. It's about time the slowness of ReThinkDisplay() was discussed. If
  13. it wasn't so slow, we'd e able to hvae copper scrolling, among other things.
  14.  
  15. For those not au fait, with copper scrolling, it invloves setting up a 
  16. copper list with two accesses to the bitplane data in it.
  17.  
  18. One access is at the top of the viewport, and the other access is x pixels
  19. down.
  20.  
  21. To scroll the viewport, you simply change the first access, to make the
  22. bitplane pointers point (say) 8 pixels further down the screen. Then
  23. you make x -= 8. Position x is where you reload the bitplane pointers
  24. with the start of the display data.
  25.  
  26. Well - anyway - the point is that you'd be able to scroll a whole screen
  27. really smoothly, using virtually no processor time, no blitter,
  28. many times faster than the blitter, with no flicker, if it wasn't for the
  29. slowness of ReThinkDisplay()
  30.  
  31. If CBM can't speed up RTD(), how about adding some kind of special support
  32. for the above kind of scrolling. Sure would make text editors look nice.
  33.  
  34. Steve
  35.  
  36. -- 
  37.  
  38.         ---- Steve Parkinson (spark%spuddy.uucp@uknet.ac.uk) ----
  39.         ----- Call Spuddy for Free UK USENET on 0203 638780 -----
  40.