home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2153 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: fc.hp.com!news
  2. From: koren@hpsrk.fc.hp.com (Steve Koren)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: WritePixelArray vs. ClipBlit vs. ...
  5. Date: 27 Jan 1996 13:28:28 -0700
  6. Organization: HP Fort Collins Site
  7. Sender: koren@hpsrk.fc.hp.com
  8. Message-ID: <oj6n379tmab.fsf@hpsrk.fc.hp.com>
  9. References: <oj6ka2yity1.fsf@hpsrk.fc.hp.com> <sqoWx*NA0@mkmk.in-chemnitz.de>
  10.     <4e9dju$ron@sunsystem5.informatik.tu-muenchen.de>
  11. NNTP-Posting-Host: hpsrk.fc.hp.com
  12. In-reply-to: fischerj@Informatik.TU-Muenchen.DE's message of 26 Jan 1996 02:17:34 GMT
  13. X-Newsreader: Gnus v5.0.9
  14.  
  15.  
  16. fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) wrote:
  17.  
  18. > : > This is annoying.  Is there any way to do case D) easier than what I am
  19. > : > thinking?
  20. > 
  21. > I do not quite get what you want to do. Looks like your engine renders
  22. > planar on AGA and chunky on gfx-card. This should give 10 times more work
  23. > than adapting the copy routines. I'm really wondering...
  24.  
  25. Right now my engine never renders planar (it will run without a graphics
  26. card, but I don't consider systems without graphics cards useful, so I
  27. don't care about optimizing for that case).  It renders 24 bit truecolor
  28. for 16 and 24 bit gfx card modes, and it renders 8 bit LUT for 8 bit
  29. register modes.  WritePixelArray(cybergraphics.library) and
  30. WritePixelArray8(graphics.library) are used, accordingly.  I would
  31. prefer to *always* render 24 bit, but there doesn't seem to be an easy
  32. way to blit a 24 bit bitmap to an 8 bit screen and have the remappinng
  33. work.  So, failing that, I do more work in my code to render either 8
  34. bit LUT or 24 bit truecolor graphics depending on the screen I'm going
  35. to be talking to.
  36.  
  37. > Also why 24bit mode. you want to play the 8bit chunky game also when
  38. > 24bit is present I guess. Or do you even have a 24bit version of your
  39. > rendering engine.
  40.  
  41. Well, it is not a game, it is an application.  It would prefer to always
  42. deal with 24 bit color space.  I did briefly consider always rendering
  43. to 24 bit internally, and using ObtainBestPen() on each pixel before
  44. displaying to achieve the truecolor->LUT conversion.  However, this is
  45. *terribly* slow on a 68040/25.  ObtainBestPen() is no practical for use
  46. on every pixel in a large image.  So instead I obtain some pens up front
  47. and render using them, if I'm on a LUT screen.
  48.  
  49. > anyway it's no wonder that updating a 256 color window on a 24bitscreen
  50. > needs some time (colortable lookup...)
  51.  
  52. Yes, but it is far slower than I can explain by doing lookups.  If it
  53. was just doing one color table lookup per pixel, it should be much
  54. faster (compared to WritePixelArray)) than it is.  So I don't understand
  55. why it is so slow now.
  56.  
  57. > : I'm afraid not, except waiting for true RTG. As far as I understood
  58. > : it, RTG would provide automatic format conversion when blitting
  59. > : between any bitmap formats.
  60. > 
  61. > huh ? Current functions do this, too. writeparr8, blitbitmap...
  62. > if they don't, imho the gfxcard driver is not ok.
  63.  
  64. They do in some cases, but not all.  I can blit an 8 bit array of pen
  65. values to a 16 or 24 bit screen (although quite slowly).  But I cannot
  66. blit a 24 or 16 bit truecolor array of data to a LUT screen mode.  I
  67. believe that's what the poster above means.  Some systems do this -
  68. applications can always speak 24 bit, and any necessary remapping is
  69. done at display time.
  70.  
  71.    - steve
  72.