home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 851 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB

  1. Path: easy.in-chemnitz.de!mkmk!floh
  2. From: floh@mkmk.in-chemnitz.de (Andre Weissflog)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: WritePixelArray vs. ClipBlit vs. ...
  5. Message-ID: <sqoWx*NA0@mkmk.in-chemnitz.de>
  6. Date: Fri, 12 Jan 1996 02:21:16 CET
  7. Reply-To: floh@mkmk.in-chemnitz.de
  8. References: <oj6ka2yity1.fsf@hpsrk.fc.hp.com>
  9. Distribution: world
  10. Organization: private uucp site
  11. X-Newsreader: Arn V 1.04
  12.  
  13. In article <oj6ka2yity1.fsf@hpsrk.fc.hp.com>, Steve Koren writes:
  14.  
  15. > A little experimentation revealed that on my (Z-II 040/25) graphics
  16. > card, WritePixelArray8 is about twice as fast as ClipBlit when both are
  17. > talking to a 256 color screen.  No surprise there.  ClipBlit is much
  18. > faster for the Amiga native gfx modes (again no surprise).  And then we
  19. > have a CyberGfx call for dealing with truecolor modes that is better
  20. > than either of the above two if you have a truecolor screen, but doesn't
  21. > work on 8 bit screens at all.
  22. > So now, I am writing a program, and I have the following choices:
  23. [...]
  24. >   D) Do maximum work, optimize for each case:
  25. >         -> Use ClipBlit on native screenmodes
  26. >         -> Use WritePixelArray8 on CyberGfx 8 bit screenmodes
  27. >         -> Use the CyberGfx call on truecolor 16/24 bit screenmodes
  28. > This is annoying.  Is there any way to do case D) easier than what I am
  29. > thinking?
  30. I'm afraid not, except waiting for true RTG. As far as I understood
  31. it, RTG would provide automatic format conversion when blitting
  32. between any bitmap formats.
  33.  
  34. So you could have your working area in 8 bit chunky with a local
  35. color map, and blit it onto a 24 bit screen, or work in 24 bit,
  36. and blit it to an 8 bit screen without need to worry about
  37. color remapping.
  38.  
  39. > Also, if I have allocated a bitmap as a "friend bitmap" of a 8 bit
  40. > cybergfx mode, I would almost have expected ClipBlit to be as fast as
  41. > WritePixelArray8.  But it isn't even close.  Why not?  In fact, I
  42. > haven't seen the friend bitmap to make any difference at all.  I can use
  43. > it or not use it, and in both cases ClipBlit is slower than
  44. > WritePixelArray8.
  45. The mysteries of gfx emulators ;-)
  46.  
  47. I wouldn't necessarly expect that CyberGfx makes use of the
  48. friend bitmap arg at all. I guess, you get a ordinary planar bitmap,
  49. which is converted to CyberGfx private chunky format during
  50. bit blit. If CyberGfx would support friend bitmaps, one might
  51. expect to get a bitmap in an unknown format, somewhere in the
  52. hidden area of the gfx cards memory (so the card's blitter
  53. can directly access it).
  54.  
  55. BTW, it could be worse. On my Merlin (latest emulator version
  56. though), WriteChunkyPixels() (didn't try WritePixelArray8())
  57. to a 256 color screen (which is clearly in chunky8 format)
  58. is so slow it takes about a second(!) to redraw a 320x200
  59. screen. I guess they convert my chunky8 array into planar
  60. format first, before reconverting that planar bitmap to
  61. the screens chunky8 bitmap :-/
  62.  
  63. Bye,
  64. -Floh.
  65.  
  66. ====//=== Andre Weissflog <floh@mkmk.in-chemnitz.de> =======
  67. ...// Sep'95: Return Of The Living Death...................
  68. \\// 90% of everything is crap (Sturgeon's Law)...........
  69. =\\===============================================Amiga!=
  70.  
  71.