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