home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3980 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 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: 14 Feb 1996 19:22:55 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4ftcqf$2bm@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.6614T57T <4fnq7t$rkv@brachio.zrz.TU-Berlin.DE> <656.6617T1074T2417@login.eunet.no>
  10. NNTP-Posting-Host: hphalle10i.informatik.tu-muenchen.de
  11. Originator: fischerj@hphalle10i.informatik.tu-muenchen.de
  12.  
  13.  
  14. In article <656.6617T1074T2417@login.eunet.no>, patrick.hanevold@login.eunet.no (Patrick Hanevold) writes:
  15. |> Organization: EUnet Norway
  16. |> Lines: 14
  17. |> Message-ID: <656.6617T1074T2417@login.eunet.no>
  18. |> 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>
  19. |>         <576.6613T1070T1730@login.eunet.no> <1257.6614T57T <4fnq7t$rkv@brachio.zrz.TU-Berlin.DE>
  20. |> NNTP-Posting-Host: pc9.asker-pm2-1.eunet.no
  21. |> X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
  22. |> 
  23. |> 
  24. |> >>>There are a few demos using this kind of blitterscreen with the spritemask.
  25. |> >>It was me and Ludvig Pedersen who wrote those c2p routines, so I know.
  26. |> >We don't forget that the sprite mask idea to save a pass is by Juergen
  27. |> >Fischer, do we? Changing the first two blitterpasses into CPU passes
  28.  
  29. Yep I hope they don't =:) I guess he referes to cpu pass
  30. routines he wrote on his own.
  31.  
  32. |> >isn't a great deed.
  33. |> He came first with it, so I guess he deserves the credits for that.
  34. |> No new idea though, and we designed our from scratch, and our is the fastest
  35. |> around. :) And the new one is even 40% faster. :) (Soon to be released.)
  36.  
  37. So what is faster than copying data to chipmem ? nothing ;)
  38.  
  39. On 030 blitter limits the framerate, so cpu passes increase
  40. timings (but the chunky dump to chipmem is still not faster 
  41. than 7mb/sec) that's what you refer to ;)
  42.  
  43. So the "40% faster" is quite a random number, I guess
  44. you refer to the time needed to c2p, which is in some
  45. cases (slow rendering, "doom") unimportant when done by
  46. blitter. In some other cases (very fast rendering, or
  47. fast cpu) your number gets important though.
  48.  
  49. The number of passes to be done by cpu depends on
  50. the cpu AND the kind of effect (execept 040+ where
  51. cpu only is best for any effect). 
  52.  
  53. I would make a file where user can config the
  54. number of passes, individually for each effect
  55. (or each new kind of effect). And I would make
  56. it possible to select writepixelarray8 for maximum
  57. c00l showoff on gfx-cards and maybe AGA+ BTW.
  58.  
  59. |> 
  60. |> <sb>Patrick Hanevold - Virtual Reality developer
  61. |> <sb>patrick.hanevold@login.eunet.no
  62. |> <sb>Amiga and official Be developer
  63. |> 
  64. ------------------------------------------------------------------------
  65.    fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)   =:)
  66.  
  67.