home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / graphics / 7392 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  3.3 KB
  1. Xref: sparky comp.sys.amiga.graphics:7392 comp.sys.amiga.programmer:15794
  2. Path: sparky!uunet!cbmvax!chrisg
  3. From: chrisg@cbmvax.commodore.com (Chris Green)
  4. Newsgroups: comp.sys.amiga.graphics,comp.sys.amiga.programmer
  5. Subject: Re: OS3.0: does this have to use Chip ram?
  6. Message-ID: <37024@cbmvax.commodore.com>
  7. Date: 13 Nov 92 12:58:40 GMT
  8. References: <BxK58F.24J@fc.hp.com> <lg3bmfINNn0u@peaches.cs.utexas.edu> <1992Nov12.121428.1@brandonu.ca>
  9. Reply-To: chrisg@cbmvax.commodore.com (Chris Green)
  10. Organization: Commodore, West Chester, PA
  11. Lines: 52
  12.  
  13. In article <1992Nov12.121428.1@brandonu.ca> brycerw@brandonu.ca writes:
  14. >In article <lg3bmfINNn0u@peaches.cs.utexas.edu>, bryan@cs.utexas.edu (Bryan Bayerdorffer) writes:
  15. >> In article <BxK58F.24J@fc.hp.com> koren@fc.hp.com (Steve Koren) writes:
  16. >> =-
  17. >> =-So it occurred to me that this scheme might be workable:
  18. >> =-
  19. >> =-   Bitmaps for the workbench screen itself:    CHIP
  20. >> =-   Bitmaps for the IFF backdrop images    :    FAST
  21. >> =-
  22. >> =-The idea is that only the screen's bitmaps _really_ have to be in chip
  23. >> =-RAM, because they are the only ones displayed.  The IFF backdrop bitmaps
  24. >> =-are never displayed directly; they are just used to copy parts of back
  25. >> =-into the screen's bitmap.  If one is willing to use the CPU to do this
  26. >> =-copy instead of the blitter, then why couldn't the IFF backdrop image
  27. >> =-planes be stored in fast RAM?  I have boatloads of fast RAM to allocate
  28. >> 
  29. >> 
  30. >> You could ask that question about any concealed portion of a bitmap.  It's a
  31. >> fine idea, and would be a good way to implement SMART_REFRESH windows,
  32. >> especially with a fast processor, and maybe dual-ported chip RAM.  I'd say that
  33. >> Intuition doesn't do this for SMART_REFRESH windows, and Workbench doesn't do
  34. >> this for its SIMPLE_REFRESH window, because they're aimed at the
  35. >> lowest-common-denominator system with a 7MHz 68000 and 16-bit-wide chip RAM,
  36. >> which would be killed by this scheme.  Hell, even Nickprefs keeps its WB picture
  37. >> in chip RAM.
  38. >> 
  39. >> Still, there otter be a config option that tells the system which way to do it.
  40. >> Anyone want to reimplement layers.library?
  41. >> 
  42. >> 
  43. >> Now get back to work on SKsh, Steve.  I want my $FG_PRI.   :-)
  44. >
  45. >Then there are those of us who need *large* bitmaps for only internal
  46. >rendering, then copy only a portion out to be displayed.  It'd be great if I
  47. >could store a completely compatible bitmap in fast ram, then copy a portion of
  48. >it to a displayable bitmap in chip ram.  Right now, I've made up my own 
  49. >FastBitMap structure and use Read/WritePixelArray8() to move data to/from 
  50. >fast ram and chip ram.  This is in an attempt to allow bitmapped images
  51. >too large for chip ram, but will fit in fast ram, to exist.  Could someone 
  52. >from Commodore let us know if a standard (but not displayable) bitmap is now 
  53. >possible in fast ram, under 3.0?
  54.  
  55.     Nope. :-(.
  56.  
  57. -- 
  58. *-------------------------------------------*---------------------------*
  59. |Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
  60. |                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
  61. |My opinions are my own, and do not         - icantforgettheimpression  o
  62. |necessarily represent those of my employer.- youmadeyouleftaholeinthe  r
  63. |"A screaming comes across the sky..."      - backofmyhead              d
  64. *-------------------------------------------*---------------------------*
  65.