home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3956 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.4 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: 18 Feb 1996 14:09:00 GMT
  6. Organization: Dept. of Informatics, University of Oslo, Norway
  7. Message-ID: <3764.6622T781T478@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><1225.6615T1229T800@login.eunet.no><1140.6616T51T1538@vip.cybercity.dk>
  9.     <1982.6617T1096T103@ifi.uio.no> <2175.6620T1429T2950@vip.cybercity.dk>
  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. >> He used a SCRAMBLED buffer and the source code was extremly hard to
  15. >> understand. (In my opinion this was the worst source I have ever seen!)
  16. >Yeah... that source was not to clever, but I used it to get information about
  17. >AGA 64bit sprites (and what a hard work that was).
  18. No the source was kind of weird, several asm-instructions on the same line
  19. etc! :)
  20.  
  21. >> Anyway, I was inspired by the sprite-dither (A great idea!). This enabled
  22. >> the c2p to have faster frame rate and less computations.
  23. >> So I wrote a new and faster routine using a LINEAR buffer.
  24. >Interesting ;) Do you by LINEAR mean non-scrabled? Or do you mean linear
  25. >blits so one don't have to do so many blits (I use 6)?
  26. I mean a non-scrambled chunky buffer ofcourse.
  27.  
  28. BTW: I use 4 blits.
  29.  
  30. >> This routine was released here at "comp.sys.amiga.programmer"
  31. >I was not around at the time. So please if somebody e-mail it to me or tell
  32. >me where to get it.
  33. Kind of hard, because I don't have that old source anymore. :(
  34.  
  35. But if you just wait a little I'll release the new version.
  36. Maybe I'll write a short doc today!
  37.  
  38. >> Anyway, some time ago some friends of mine and I rewrote the algorithm.
  39. >> And made the code 30-40% faster. Now it is just as fast as to copy
  40. >> 5120 (160*128/4) longwords to chipram. (Try to beat that!)
  41. >Then you can't do a hole blitter pass. Are you using the blitter???
  42. Maybe it was a little unclear? The CPU-2-passes code is now 40% faster than
  43. in the first version. So there is much *more* time for *rendering*.
  44. (I don't care much about how much time the blitter uses as long as it
  45. finishes it work in less than a frame!)
  46.  
  47. Mine current routine is using 48 cycles on 2 passes.
  48.  
  49.         move.l  #160*128/8-1,d7
  50.  
  51. Loop:
  52.         move.l  (a0)+,d0               ;Linear Chunky buffer
  53.         move.l  (a0)+,d1
  54.  
  55.         <2 passes = 48 cycles>
  56.  
  57.         move.l  d0,(a1)+               ;chipram
  58.         move.l  d2,(a1)+
  59.  
  60.         dbra    d7,Loop
  61.  
  62. As you probably have noticed the example is not optimised for memory-access,
  63. but the purpose was just to show what I meant by 48 cycles.
  64.  
  65. My old version which was released used 78 cycles.
  66.  
  67. How fast are your CPU-passes anyway?
  68.  
  69. >> It still uses a LINEAR buffer and can have a maximum framerate of 50 fps.
  70. >Is that for 20480 pixels? Because then it is almost the same as the old one.
  71. Yes it is 20480 chunky pixels. And Yes it not much different from the first
  72. version (well the algo is different!). But the CPU passes is much faster now
  73. so there is more time for rendering. Which is what we want! :-)
  74.  
  75. >> I have also made a version without sprite-dither with the same algorithm.
  76. >> However this one can only have a framerate of 25 fps. But it uses no more
  77. >> CPU time. So its good for more complex rendering.
  78. >> We plan to release this routine as soon as possible. The only thing we need
  79. >> is a doc file! :-/
  80. >> BTW:
  81. >> I have also tried to write this routine as system-friendly as possible by
  82. >> using QBlit for the blitterpasses.
  83. >Yeah... I'm also trying to make everything as systemfriendly as posible.
  84. >I have tryed out system copperlists and I will make intuition screen version
  85. >of the blitterscreen (this will ofcause only work on AGA screens).
  86.  
  87. How are you going to handle 64 pixels width sprites?
  88.  
  89. What about double pixel height?
  90.  
  91. What about multisync?
  92.  
  93. Intuition screens are often promoted to another screenmodes.
  94.  
  95. Have you thought about that the modulo registers work different in
  96. scandoubling modes like DBLPAL, DBLNTSC?
  97.  
  98. There is a lot of things to think about! :(
  99.  
  100. But it is possible more or less system-friendly. I'm finished a version
  101. without sprite dithering a copple of days ago.
  102.  
  103.  
  104.  
  105.  
  106. <sb>Ludde - Amiga Demo Coder
  107. <sb>Virtual Reality & Official Be developer
  108. <sb>ludvigp@ifi.uio.no
  109.  
  110.