home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / programm / 15732 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.9 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!cbmvax!chrisg
  2. From: chrisg@cbmvax.commodore.com (Chris Green)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: New hardware reference guide?
  5. Message-ID: <36998@cbmvax.commodore.com>
  6. Date: 12 Nov 92 13:50:18 GMT
  7. References: <1992Nov2.201536.9913@vax.oxford.ac.uk> <OD.6badnetOA92-901-302p0_52f54996@piraya.bad.se> <1992Nov11.115501.22945@ifi.uio.no>
  8. Reply-To: chrisg@cbmvax.commodore.com (Chris Green)
  9. Organization: Commodore, West Chester, PA
  10. Lines: 47
  11.  
  12. In article <1992Nov11.115501.22945@ifi.uio.no> olavka@ifi.uio.no (Olav Lur}s Kalgraf) writes:
  13. >
  14. >In article <OD.6badnetOA92-901-302p0_52f54996@piraya.bad.se>, Roger_Nordin@atb.bbs.bad.se (Roger Nordin) writes:
  15. >
  16. >> With Release4 in the not-so-distant future (yes, I'm an optimist if you are 
  17. >> wonderig :)) with Device Independant Graphics, we need to get rid of the 
  18. >> hardware hacking. Therefore, Release3 has been vastly improved in most areas 
  19. >> regarding speed and available functions with it comes to graphics and 
  20. >> animation. Use the Operation System, or die, with future machines.
  21. >> 
  22. >> Definatly a step in the Right Direction!
  23. >> 
  24. >
  25. >Although I agree that it is a step in the right direction, there is a
  26. >small problem with using the OS for games etc. Last weekend I tried
  27. >to make a small vector routine using the graphics.library. The results were
  28. >absolutly PATHETIC! And I use an A4000 for gods sake! After that big
  29. >dissapointment I rewrote the code to some giant pseudo OS/hardware hack.
  30. >This worked quite well, but anyway I came to a few conclusions:
  31. >
  32. >
  33. >    1. The graphics.library is incredibly slow and most likely
  34. >        not updated much in release3. This needs to be rewritten
  35. >        entirely to satisfy the needs for speed in todays games.
  36.  
  37.     What was too slow? How did your demo work? Information, please.
  38. How about posting the source? If the blits were too slow, then what
  39. function were you calling? You could call OwnBlitter/WaitBlit and
  40. poke the hardware yourself, and still run under the OS.
  41.  
  42.     If the screen stuff was too slow, then what were you using?
  43. Screens or ViewPorts? Scrolling or not? New double buffering calls?
  44.  
  45.     Were you using Draw? Using a profiler here, I note that a
  46. program continually drawing lines into a superbitmap (the most complex
  47. case) with lots of clipping spends less than 1% of its time on
  48. line draw setup, and the other >99% waiting for the line to actually
  49. be drawn. This is on an 040, the same as you were using.
  50.  
  51. -- 
  52. *-------------------------------------------*---------------------------*
  53. |Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
  54. |                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
  55. |My opinions are my own, and do not         - icantforgettheimpression  o
  56. |necessarily represent those of my employer.- youmadeyouleftaholeinthe  r
  57. |"A screaming comes across the sky..."      - backofmyhead              d
  58. *-------------------------------------------*---------------------------*
  59.