home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / programm / 15899 < prev    next >
Encoding:
Text File  |  1992-11-16  |  3.5 KB  |  83 lines
  1. Nntp-Posting-Host: kjerringa.ifi.uio.no
  2. Newsgroups: comp.sys.amiga.programmer
  3. Path: sparky!uunet!mcsun!sunic!aun.uninett.no!nuug!ifi.uio.no!olavka
  4. From: olavka@ifi.uio.no (Olav Lur}s Kalgraf)
  5. Subject: Re: New hardware reference guide?
  6. Message-ID: <1992Nov16.134153.6356@ifi.uio.no>
  7. Sender: olavka@ifi.uio.no (Olav Lur}s Kalgraf)
  8. Organization: Dept. of Informatics, University of Oslo, Norway
  9. References:  <1992Nov12.215020.20036@ultb.isc.rit.edu>
  10. Date: Mon, 16 Nov 1992 13:41:53 GMT
  11. Lines: 69
  12. Originator: olavka@kjerringa.ifi.uio.no
  13.  
  14.  
  15. In article <1992Nov12.215020.20036@ultb.isc.rit.edu>, eas3714@ultb.isc.rit.edu (E.A. Story) writes:
  16. > In olavka@ifi.uio.no (Olav Lur}s Kalgraf) writes:
  17. > >
  18. > > Although I agree that it is a step in the right direction, there is a
  19. > > small problem with using the OS for games etc. Last weekend I tried
  20. > > to make a small vector routine using the graphics.library. The results were
  21. > > absolutly PATHETIC! And I use an A4000 for gods sake! After that big
  22. > > dissapointment I rewrote the code to some giant pseudo OS/hardware hack.
  23. > 
  24. > Code please?  It doesn't mean anything if you don't know HOW to program
  25. > fast graphics under 3.0... (and you don't, most likely, since MOST people
  26. > don't have any documentation on 3.0 as of yet).
  27. >
  28. Actually I used the 2.0 includes, and used calls to old graphics lib
  29. fillpoly functions. BUT if 3.0 was coded in a sencible way, these functions would
  30. be optimized, and recoded to use the AGA chipset, NO? Anyway all I
  31. did was making a 1 BITPLANE rotating polygon and timing it with the raster
  32.  
  33.  
  34. > > This worked quite well, but anyway I came to a few conclusions:
  35. > >
  36. > >       1. The graphics.library is incredibly slow and most likely
  37. > >           not updated much in release3. This needs to be rewritten
  38. > >           entirely to satisfy the needs for speed in todays games.
  39. > 
  40. > Again, graphics.library isn't gonna help you much if you insist on using
  41. > old routines in slow ways.
  42.  
  43. And again, my result didn't have anything to do with the way I am using
  44. gfxlib. ONE filled polygon, five points rotated about 3 axis......
  45. OK, I used the fillpoly or something, function. And I am sure I could
  46. have done it faster by using the blitter functions, BUT won't these
  47. functions be kind of obsolete when DIG is introduced. They are assuming 
  48. things about the hardware you know.......
  49.  
  50.  
  51. > 
  52. > >       2. The dream of DIG can not include the blitter unless 1.
  53. > >           comes true. We really need the blazing speed of optimized
  54. > >           assembly to take advantage of the amigas chips with todays
  55. > >           incredibly slow OS graphics support.
  56. > 
  57. > We need blazing speed, not necessarily optimized assembly.  Two different
  58. > things.
  59. > 
  60. Different, true. But also very closely connected, optimized assembly
  61. means blazing speed. 
  62.  
  63.  
  64. > >       3. Anyone claiming that the speed difference between using
  65. > >           OS and optimized assembly+hardware hacking is minimal
  66. > >           does not know what he is talking about.
  67. > 
  68. > Depends on what you're doing... I'd suggest that you optimize the way you
  69. > USE graphics.library, not the way graphics.library is written.
  70. > 
  71. Have you ever tried hitting the hardware with pure optimized assebly????
  72. I can tell you that it can't be compared to OS snailcode. I mean, there is
  73. a reason why most games are written in 'trash the metal' code......
  74.  
  75.  
  76.     Yours, Olav Kalgraf..
  77.  
  78.  
  79. PS: I really hope you are right about 3.0 gfxlib, it would be nice if
  80.     there were some functions for fast gfxoperations there, in 
  81.     pre 3.0  stuff like that was NONEXISTANT!!!
  82.     pre 
  83.