home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2029 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.3 KB
  1. Path: informatik.tu-muenchen.de!fischerj
  2. From: fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: WritePixelArray vs. ClipBlit vs. ...
  5. Date: 26 Jan 1996 02:17:34 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4e9dju$ron@sunsystem5.informatik.tu-muenchen.de>
  9. References: <oj6ka2yity1.fsf@hpsrk.fc.hp.com> <sqoWx*NA0@mkmk.in-chemnitz.de>
  10. NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Andre Weissflog (floh@mkmk.in-chemnitz.de) wrote:
  14. : In article <oj6ka2yity1.fsf@hpsrk.fc.hp.com>, Steve Koren writes:
  15.  
  16. : > 
  17. : > A little experimentation revealed that on my (Z-II 040/25) graphics
  18. : > card, WritePixelArray8 is about twice as fast as ClipBlit when both are
  19. : > talking to a 256 color screen.  No surprise there.  ClipBlit is much
  20.  
  21. why. clipblit should copy from window to window. If this is slower, then
  22. either overhead or copy vram->vram is slower than fast->vram.
  23.  
  24. the function according to writepixelarray8 should rather be 
  25. blitbitmaprastport (maybe not much difference if your sourcerastport is
  26. not layered (not a window or screen)).
  27.  
  28. well, rastports of screens/windows on gfx-cards should be chunky anyway ?
  29.  
  30. So I'm not sure why writepixelarray8 is faster, it is a surprise imho.
  31.  
  32. : > faster for the Amiga native gfx modes (again no surprise).  And then we
  33. this indeed no surprise ;)
  34.  
  35. : > have a CyberGfx call for dealing with truecolor modes that is better
  36. : > than either of the above two if you have a truecolor screen, but doesn't
  37. : > work on 8 bit screens at all.
  38. : > 
  39. : > So now, I am writing a program, and I have the following choices:
  40. : > 
  41. : [...]
  42. : > 
  43. : >   D) Do maximum work, optimize for each case:
  44. : >         -> Use ClipBlit on native screenmodes
  45. : >         -> Use WritePixelArray8 on CyberGfx 8 bit screenmodes
  46. : >         -> Use the CyberGfx call on truecolor 16/24 bit screenmodes
  47. : > 
  48. : > This is annoying.  Is there any way to do case D) easier than what I am
  49. : > thinking?
  50.  
  51. I do not quite get what you want to do. Looks like your engine renders
  52. planar on AGA and chunky on gfx-card. This should give 10 times more work
  53. than adapting the copy routines. I'm really wondering...
  54.  
  55. Also why 24bit mode. you want to play the 8bit chunky game also when
  56. 24bit is present I guess. Or do you even have a 24bit version of your
  57. rendering engine.
  58.  
  59. anyway it's no wonder that updating a 256 color window on a 24bitscreen
  60. needs some time (colortable lookup...)
  61.  
  62. maybe I'm off topic now, I got no idea what you are doing :)
  63.  
  64. : > 
  65. : I'm afraid not, except waiting for true RTG. As far as I understood
  66. : it, RTG would provide automatic format conversion when blitting
  67. : between any bitmap formats.
  68.  
  69. huh ? Current functions do this, too. writeparr8, blitbitmap...
  70. if they don't, imho the gfxcard driver is not ok.
  71.  
  72. : So you could have your working area in 8 bit chunky with a local
  73. : color map, and blit it onto a 24 bit screen, or work in 24 bit,
  74. : and blit it to an 8 bit screen without need to worry about
  75. : color remapping.
  76. blit 24bit scene to 8bit without any worry ? naaah ;)
  77.  
  78. : > Also, if I have allocated a bitmap as a "friend bitmap" of a 8 bit
  79. : > cybergfx mode, I would almost have expected ClipBlit to be as fast as
  80. : > WritePixelArray8.  But it isn't even close.  Why not?  In fact, I
  81. good question.
  82. : > haven't seen the friend bitmap to make any difference at all.  I can use
  83. : > it or not use it, and in both cases ClipBlit is slower than
  84. : > WritePixelArray8.
  85.  
  86. writeparr8 is maybe most optimized. good, because it's the main
  87. routine for chunky games on gfx-cards. longword-alignment comes into
  88. my mind, but I don't know if it's a reason.
  89. if the card has a blitter which is used, cliblit should be lots faster...
  90. hmmm....
  91.  
  92. : > 
  93. : The mysteries of gfx emulators ;-)
  94.  
  95. indeed!
  96.  
  97. : I wouldn't necessarly expect that CyberGfx makes use of the
  98. : friend bitmap arg at all. I guess, you get a ordinary planar bitmap,
  99.  
  100. well, native bitmaps are in chipmem. then I wonder why it's only 2 times
  101. slower than writeparr8....
  102.  
  103. : which is converted to CyberGfx private chunky format during
  104. : bit blit. If CyberGfx would support friend bitmaps, one might
  105. well, only if the bitmap is one of the chunky window/screen....
  106.  
  107. : expect to get a bitmap in an unknown format, somewhere in the
  108. : hidden area of the gfx cards memory (so the card's blitter
  109. : can directly access it).
  110.  
  111. : BTW, it could be worse. On my Merlin (latest emulator version
  112. : though), WriteChunkyPixels() (didn't try WritePixelArray8())
  113. : to a 256 color screen (which is clearly in chunky8 format)
  114. : is so slow it takes about a second(!) to redraw a 320x200
  115. : screen. I guess they convert my chunky8 array into planar
  116. : format first, before reconverting that planar bitmap to
  117. : the screens chunky8 bitmap :-/
  118. yes, I guess so ! the first one is as slow as on AGA (I gues it
  119. needs also 1 sec there ?), the latter conversion should be
  120. very qick (compared to 1sec) if a p2c hardware is present.
  121.  
  122. : Bye,
  123. : -Floh.
  124.  
  125. : ====//=== Andre Weissflog <floh@mkmk.in-chemnitz.de> =======
  126. : ...// Sep'95: Return Of The Living Death...................
  127. : \\// 90% of everything is crap (Sturgeon's Law)...........
  128. : =\\===============================================Amiga!=
  129.  
  130. ------------------------------------------------------------------------
  131.    fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)   =:)
  132.