home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2776 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 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: Demos on graphiccards
  5. Date: 2 Feb 1996 17:41:59 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4etid7$m36@sunsystem5.informatik.tu-muenchen.de>
  9. References: <xB53AMD0asz2@wizzcat.prima.ruhr.de>  <4eavqk$da8@sunsystem5.informatik.tu-muenchen.de> <PETERM.96Jan31231828@tui.maths.irl.cri.nz>
  10. NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
  11. Originator: fischerj@hphalle5.informatik.tu-muenchen.de
  12.  
  13.  
  14. In article <PETERM.96Jan31231828@tui.maths.irl.cri.nz>, peterm@maths.grace.cri.nz (Peter McGavin) writes:
  15. |> Organization: Industrial Research Ltd
  16. |> Lines: 23
  17. |> Distribution: world
  18. |> Message-ID: <PETERM.96Jan31231828@tui.maths.irl.cri.nz>
  19. |> References: <xB53AMD0asz2@wizzcat.prima.ruhr.de>
  20. |>     <4eavqk$da8@sunsystem5.informatik.tu-muenchen.de>
  21. |> NNTP-Posting-Host: tui.grace.cri.nz
  22. |> In-reply-to: fischerj@informatik.tu-muenchen.de's message of 26 Jan 1996
  23. |>     16:34:28 GMT
  24. |> 
  25. |> fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
  26. |> >well, supporting gfx-cards doesn't mean you need to fallback to
  27. |> >OS-routines for rendering. OS-rendering as option could speed up
  28. |> >on special hardware though.
  29. |> 
  30. |> IMHO, it's the other way around.  A demo must fall-back to high-level
  31. |> OS calls if it wants to support _all_ gfx-cards (including unknown and
  32. |> future cards).  If a demo detects a known, particular card or custom
  33. |> chipset, then it could possibly go faster with an option to go right
  34. |> to the hardware.
  35.  
  36. thats what I meant :)
  37. |> 
  38. |> >|>     See Gloom running systemfriendly !!
  39. |> >
  40. |> >Yes, that's nice. But it's too slow. Not because of sysfriendly, but
  41. |> >bacause of suboptimal c2p and suboptimal mapping.
  42. |> 
  43. |> Feel free to write faster c2p routines than the ones I uploaded to
  44. |> Aminet game/demo/GloomC2P10.lha.  Unfortunately the Gloom Deluxe Demo
  45. |> c2p interface doesn't seem to support async blitter, which would be
  46. |> faster on an '020.  For CPU-only c2p, I think my routines would be
  47. |> hard to improve significantly (but I've been proved wrong before).
  48.  
  49. that's it, not improvable, because gloom limits to cpu-only.
  50.  
  51. Black magic made the turn from "we-aim-at-A1200-users-only-copperscreen"
  52. to "wow-we-use-the-OS!-quite-unefficient-cpu-only-c2p".
  53.  
  54. But that's not the biggest prob, the problem is imho that
  55. the mapping is just too slow.
  56.  
  57. For example non shaded floor can run in 16ish cycles inner loop
  58. (on chipset copper does floorshading). And wall is even faster,
  59. I guess 20ish cycles including shadingtable (020/030).
  60.  
  61. I wish there was a clone coming much nearer to those theoretic max values.
  62.  
  63. |> -- 
  64. |> Peter McGavin.   (p.mcgavin@irl.cri.nz)
  65. ------------------------------------------------------------------------
  66.    fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)   =:)
  67.