home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3610 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.7 KB
  1. Path: Norway.EU.net!usenet
  2. From: patrick.hanevold@login.eunet.no (Patrick Hanevold)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: doubling pixels horizontally
  5. Date: 22 Feb 1996 07:02:37 GMT
  6. Organization: EUnet Norway
  7. Message-ID: <5073.6626T469T1290@login.eunet.no>
  8. References: <4f4ibc$gl9@news.cs.tu-berlin.de> <591.6610T1165T2102@login.eunet.no><1045.6611T753T2256@vip.cybercity.dk><4faoe1$47@sunsystem5.informatik.tu-muenchen.de><2991.6612T1034T625@vip.cybercity.dk><576.6613T1070T1730@login.eunet.no><1257.6614T57T922@vip.cybercity.dk><1982.6617T1096T103@ifi.uio.no>
  9.     <4gbjg3$104@sunsystem5.informatik.tu-muenchen.de> <4518.6625T1142T92@ifi.uio.no>
  10. NNTP-Posting-Host: pc9.asker-pm2-1.eunet.no
  11. X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
  12.  
  13.  
  14. >>: He was the first to use sprite-dither!
  15. >>yes. In "Excess/RIOT", I used this method for quick 256 col rotzoom.
  16. >>It was no c2p, it was a special 1-blitterpass solution with cpu
  17. >>storing mega-scrambled ;) Any more rotzoomers ?
  18. >Please not, I have seen enough of rotzoomer!! :-)
  19.  
  20. >>Having already claimed "blitteronly c2p on A1200 rulz" bevore,
  21. >>I combined both ideas of ghost-mode & c2p. voila :)
  22. >>: He used a SCRAMBLED buffer and the source code was extremly hard to
  23. >>Well, both scrambled & linear, 2pass or 3pass.
  24. >Yes that was the problem. It went 25 fps in linear mode.
  25.  
  26. >>: understand. (In my opinion this was the worst source I have ever seen!)
  27. >>were you the one I was wrestling with about this some months ago ? ;)
  28. >>nobody could really tell me what is bad about my code. maybe it is...
  29. >>Yes, blitterscreen is "extremly hard to understand" for some people ;->
  30. >>Sorry for not writing a comment after each instruction. I know it
  31. >>would have been hard work to understand it for myself if I had to
  32. >>try to check what's going on just by this code :)
  33. >In my opinion good code don't need comments on *every* lines.
  34. >It should be written in a way that it is easy to understand and
  35. >there is easy to get an overview.
  36. Like using structures. :)
  37.  
  38. >Having many instructions on screen don't give us more overview but more MESS!
  39. >(Try another screenmode instead)
  40. And removing unnessecary moveq's. :)
  41.  
  42. >Actually I think it is important to have a litte "air" in between! :-)
  43. Not too much. :)
  44.  
  45. >Here is a small piece of *your* code:
  46.  
  47. >* PLANES
  48. >   movem.l d0-d7/a1-a6,-(sp) ;a0=(ptr)copl
  49. >   move.l d4,mfpoffs : ext.l d5 : move.l d5,mfloffs
  50. >* gen planeptr moves
  51. >   movem.l d3/d0,-(sp)
  52. >   move.w #$00e0,d3 : move.w #4-1,d7
  53. >mf256genhi:
  54. >   move.w d3,(a0)+ : addq.w #2,d3 : move.l d0,(a0)+  ;store hiwd ! -2(a0)
  55. >   move.w d3,-2(a0) : addq.w #2,d3 : move.w d0,(a0)+ ;store lowd
  56. >;every 2nd plane same data
  57. >   move.w d3,(a0)+ : addq.w #2,d3 : move.l d0,(a0)+  ;store hiwd ! -2(a0)
  58. >   move.w d3,-2(a0) : addq.w #2,d3 : move.w d0,(a0)+ ;store lowd
  59. >   add.l mfpoffs,d0
  60. >   dbra d7,mf256genhi
  61. >* end gen ptrs
  62. >   movem.l (sp)+,d3/d0
  63. >   and.l #$ff,d2 : sub.b #1,d2 : ror.l #8,d2   ;sub #1: prev line
  64. >   move.l #$00e1fffe,d4 : or.l d2,d4           ;WAS: 00df
  65. >*
  66. >   move.w d3,d5
  67. >   subq.w #1,d5
  68. >mf256yanz:
  69. >   move.l #$1020010,d7
  70. >   move.w #2-1,d6
  71. >mf256do2:
  72. >   move.l d4,(a0)+ : add.l #$01000000,d4  ;cwait
  73. >   move.l d7,(a0)+ : eor.l #$00000031,d7  ;horiz shift
  74. >                     ;             ^---- 3: 1 -> 2 -> 1 -> 2 ....
  75. >   dbra d6,mf256do2
  76. >   add.l mfloffs,d0
  77. >   dbra d5,mf256yanz
  78. >   movem.l (sp)+,d0-d7/a1-a6 ;a0=(ptr)copl
  79. >   rts
  80. Whow! What a mess. :)
  81.  
  82. >Its quiet unreadable in my opinion.
  83.  
  84. >>: Anyway, I was inspired by the sprite-dither (A great idea!). This enabled
  85. >>: the c2p to have faster frame rate and less computations.
  86. >>one pass done by planar hardware, so one less for blitter or cpu.
  87. >Yes that was clever. :)
  88.  
  89. >>: And made the code 30-40% faster. Now it is just as fast as to copy
  90. >>: 5120 (160*128/4) longwords to chipram. (Try to beat that!)
  91. >>Your refer to 2-pass on 030-50 ? please be more exact.
  92. >Yes. I think I have posted some timings here some days ago.
  93.  
  94. >>Well, I guess my 1pass routine will also be as fast as copy on 030-25,
  95. >>it needs 2 times on 020-14 and as 030-25 is roughly about 2 times
  96. >>faster...
  97. >>I would be happy if we could get a 3pass almost at copy speed.
  98. >>(well copy speed, that's 7mb/sec on 030 ? or are we refering to
  99. >>the 4mb/sec on 020-14 ?)
  100. >On my A1200 7mb/sec is not copy speed but chip write speed.
  101.  
  102. >I did a simple test and I was able to copy 4.9mb/sec from fastram to chipram
  103. >on a 256 colors screen.
  104.  
  105. >>: I have also made a version without sprite-dither with the same algorithm.
  106. >>=:o oooh! But it's non-ideal, right ? how you get normal planar words
  107. >>out of THAT mess :) 01010101 how you get together the 0's to 0000 ?
  108.                                                                ^^^^
  109.                                                                00000000!
  110.  
  111. >I don't get it??? ;) It is optimal. That was actually VERY easy. Remeber that
  112. >we are taking about 2x2 without sprite-dithering!!
  113. He forgot that it was 2xn
  114.  
  115. >(This code will also be released.)
  116.  
  117. >>: We plan to release this routine as soon as possible. The only thing we
  118. >>: need is a doc file! :-/ BTW: I have also tried to write this routine as
  119. >>: system-friendly as possible by using QBlit for the blitterpasses.
  120. >>I currently got problems with my way of calling qblit. You got a demo
  121. >>executable ? Mine locks up with small OS-blits :\
  122.  
  123. >I don't have that problem. You can look at the source. It will be released
  124. >this week.
  125. Hmm.. Yes you do. Its tha same locker we have. Exept we MAY have found a
  126. solution. Guess it will lock when I implement it in our world engine. :)
  127.  
  128. >BTW:
  129.  
  130. >fASTERblIT(FBL) makes the CPU hang after a QBlit(). If you are using this
  131. >patch thats the error.
  132. It doesnt hang forever does it?
  133.  
  134. <sb>Patrick Hanevold - Virtual Reality developer
  135. <sb>patrick.hanevold@login.eunet.no
  136. <sb>Amiga and official Be developer
  137.  
  138.