home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 4511 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.6 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: doubling pixels horizontally
  5. Date: 29 Feb 1996 15:49:57 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4h4hv5$mnn@sunsystem5.informatik.tu-muenchen.de>
  9. 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> <4gbjg3$104@sunsystem5.informatik.tu-muenchen.de> <4518.6625T1142T92@ifi.uio.no>
  10. NNTP-Posting-Host: hphalle2i.informatik.tu-muenchen.de
  11. Originator: fischerj@hphalle2i.informatik.tu-muenchen.de
  12.  
  13.  
  14. In article <4518.6625T1142T92@ifi.uio.no>, ludvigp@ifi.uio.no (Ludvig Pedersen) writes:
  15.  
  16.  
  17. |> Please not, I have seen enough of rotzoomer!! :-)
  18.  
  19. except the sanity 1x1 one and the lemon 4x4 one in  Rink a Dink :) 
  20. I didn't see much good ones... maybe the one in full moon/VD.
  21.  
  22. |> >Well, both scrambled & linear, 2pass or 3pass.
  23. |> Yes that was the problem. It went 25 fps in linear mode.
  24.  
  25. no. 33fps, hehe! :)
  26.  
  27. |> Having many instructions on screen don't give us more overview but more MESS!
  28. |> (Try another screenmode instead)
  29. |> 
  30. |> Actually I think it is important to have a litte "air" in between! :-)
  31. |> 
  32. |> 
  33. |> Here is a small piece of *your* code:
  34.  
  35. wow my code! mama, I'm on TV :)  (quoting a demo :)
  36.  
  37. |> 
  38. |> * PLANES
  39. |>    movem.l d0-d7/a1-a6,-(sp) ;a0=(ptr)copl
  40. |>    move.l d4,mfpoffs : ext.l d5 : move.l d5,mfloffs
  41. |> * gen planeptr moves
  42. |>    movem.l d3/d0,-(sp)
  43. |>    move.w #$00e0,d3 : move.w #4-1,d7
  44. |> mf256genhi:
  45. |>    move.w d3,(a0)+ : addq.w #2,d3 : move.l d0,(a0)+  ;store hiwd ! -2(a0)
  46.  
  47. The idea: this 3 instructions belong together, writing 1 copper 
  48. instruction lonword. more structure (for my eyes).
  49.  
  50. and the "store hi word" trick isn't bad either imho :)
  51. nothing exceptionell though...
  52.  
  53. |>    move.w d3,-2(a0) : addq.w #2,d3 : move.w d0,(a0)+ ;store lowd
  54. |> ;every 2nd plane same data
  55. |>    move.w d3,(a0)+ : addq.w #2,d3 : move.l d0,(a0)+  ;store hiwd ! -2(a0)
  56. |>    move.w d3,-2(a0) : addq.w #2,d3 : move.w d0,(a0)+ ;store lowd
  57. |>    add.l mfpoffs,d0
  58. |>    dbra d7,mf256genhi
  59. |> * end gen ptrs
  60. |>    movem.l (sp)+,d3/d0
  61. |>    and.l #$ff,d2 : sub.b #1,d2 : ror.l #8,d2   ;sub #1: prev line
  62. |>    move.l #$00e1fffe,d4 : or.l d2,d4           ;WAS: 00df
  63. |> *
  64. |>    move.w d3,d5
  65. |>    subq.w #1,d5
  66. |> mf256yanz:
  67. |>    move.l #$1020010,d7
  68. |>    move.w #2-1,d6
  69. |> mf256do2:
  70. |>    move.l d4,(a0)+ : add.l #$01000000,d4  ;cwait
  71. |>    move.l d7,(a0)+ : eor.l #$00000031,d7  ;horiz shift
  72. |>                      ;             ^---- 3: 1 -> 2 -> 1 -> 2 ....
  73. |>    dbra d6,mf256do2
  74. |>    add.l mfloffs,d0
  75. |>    dbra d5,mf256yanz
  76. |>    movem.l (sp)+,d0-d7/a1-a6 ;a0=(ptr)copl
  77. |>    rts
  78. |> 
  79. |> Its quiet unreadable in my opinion.
  80.  
  81. AND THE READBLE VERSION WOULD HAVE TAKEN 3 PAGES INSTEAD OF ONE!
  82.  
  83. Maybe I'm the only one but I can read/build code much better that way.
  84. And I could read my code well :)
  85.  
  86. |> >I would be happy if we could get a 3pass almost at copy speed.
  87. |> >(well copy speed, that's 7mb/sec on 030 ? or are we refering to
  88. |> >the 4mb/sec on 020-14 ?)
  89. |> On my A1200 7mb/sec is not copy speed but chip write speed.
  90.  
  91. mhm, all people told me the blizzard will _copy_ 7mb/sec.
  92. a myth ?
  93.  
  94. |> 
  95. |> I did a simple test and I was able to copy 4.9mb/sec from fastram to chipram
  96. |> on a 256 colors screen.
  97.  
  98. what size ?  overscan, 320x256,320x200 ? pal ?
  99. :)
  100.  
  101. |> I don't get it??? ;) It is optimal. That was actually VERY easy. Remeber that
  102. |> we are taking about 2x2 without sprite-dithering!!
  103.  
  104. either you misuse a plane as mask, so 128 colors only, or the 2x2
  105. routine is slower than 3pass, i.e. not optimal :)
  106.  
  107. |> >I currently got problems with my way of calling qblit. You got a demo
  108. |> >executable ? Mine locks up with small OS-blits :\
  109. |> 
  110. |> I don't have that problem. You can look at the source. It will be released
  111.  
  112. didn't test it yet, but seems that peter found the bug:
  113. I busywait for qblit ready (normaly it is ready).
  114. So another lower pri task can't disown blitter.
  115.  
  116. |> this week.
  117. |> 
  118. |> BTW:
  119. |> 
  120. |> fASTERblIT(FBL) makes the CPU hang after a QBlit(). If you are using this
  121. |> patch thats the error.
  122.  
  123. mhm no, never heard of it, I use cpublit, but no interference yet.
  124.  
  125. |> 
  126. |> 
  127. |> 
  128. |> <sb>Ludde - Amiga Demo Coder
  129. |> <sb>Virtual Reality & Official Be developer
  130. |> <sb>ludvigp@ifi.uio.no
  131. |> 
  132. ------------------------------------------------------------------------
  133.    fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)   =:)
  134.  
  135.