home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / programm / 15797 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  4.3 KB
  1. Path: sparky!uunet!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: <37027@cbmvax.commodore.com>
  6. Date: 13 Nov 92 13:35:17 GMT
  7. References: <Bx7782.CKD@kingston.ac.uk> <1992Nov5.184916.17436@sth.frontec.se> <1927@lysator.liu.se> <BxAMtH.Aos@cck.coventry.ac.uk> <36816@cbmvax.commodore.com> <1992Nov13.085247.58456@qut.edu.au>
  8. Reply-To: chrisg@cbmvax.commodore.com (Chris Green)
  9. Organization: Commodore, West Chester, PA
  10. Lines: 75
  11.  
  12. In article <1992Nov13.085247.58456@qut.edu.au> podesta@qut.edu.au writes:
  13. >Underestimate the performance of the system routines?????????
  14. >Come on, is that possible. True, that 2.x is much better than 1.x and
  15. >3.x sounds great, but there's still NO way your gonna write a game
  16. >like Shadow of the Beast III that will run on a 1meg A500 using system routines!
  17.  
  18.     An A1200 isn't a 1meg A500. AGA chip specs will in no way aid
  19. in writing demos and games that work on 1meg A500's.
  20.  
  21. >And to compete with the Console games, and to get people to buy your games,
  22. >and just to feel proud of your games, you need to target that kind of level
  23. >of speed, graphics and gameplay.
  24.  
  25.     Once speed is at an acceptable level, and graphics are good
  26. (which is to a large degree determined by the skill of the artist
  27. drawing them, rather than which bits are set in which registers),
  28. work spent on speed at the expense of work spent on gameplay is
  29. wasted and can easily translate into lost sales. In fact, a good
  30. marketing tie-in is worth more to a product's sales than any
  31. AGA register bit.
  32.  
  33.     Also, isn't it kind of hard to compete with the people using
  34. the OS? Developers using screens & viewports for their games already
  35. have all their stuff working in 256 colors simply by changing
  36. a depth of 5 to one of 8, and can already be started on re-doing
  37. the art. Hardware hackers have to go back and re-write all of
  38. their routines. And don't think that it's simply a matter of setting
  39. the right bit in the right place. None of your ECS scrolling and copper
  40. routines will come close to working without being re-written. It
  41. took more than a man-year to get all of the view creation stuff
  42. (arbitrary overscan, all resolutions, scrolling, color table loading,
  43. and support for 1x,2x, and 4x fetch modes) working perfectly. And we
  44. had full access to the people who designed the chips, schematics of
  45. the chips, and logic analyzers monitoring pins which let us see the
  46. internal operation of the fetch engine. We also had an entire PA
  47. department, more AGA machines than any game company would have, 
  48. and the whole commercial developer community to make sure we got it
  49. right. To throw all of this away and start from scratch is hardly
  50. a competitive action.
  51.  
  52. > There's no market for games and demos that
  53. >only run on 68020 machines and above. 
  54.  
  55.     Than there's no market for AGA games and demos. So why do you
  56. want the register list?
  57.  
  58. >In demos??? They must be pretty lame if some hardcoded effects are slower than
  59. >the system software.
  60.     I've seen plenty of demos, particularly 3d ones, that I
  61. could have coded faster using OS routines. Some of these 3d
  62. demo coders seem to have spent more time figuring out how to draw lines
  63. using the blitter than they did learning the 3d math, and use
  64. ridiculously inefficient methods.
  65.  
  66. ..Remember that demos and games can use the fact that
  67. >they are not generic - we don't have to worry about window clipping or
  68. >multiple tasks or I/O because these are all controlled.
  69.  
  70.     The OS doesn't worry about clipping either. One tst.l of rp_Layer
  71. and it branches to non-clipping versions of the drawing routines. And if this
  72. is too slow, than its perfectly alright to write directly to the bitplanes
  73. with the CPU or blitter, if you're careful.
  74.     Multiple tasks don't matter either. A task running at a priority
  75. above input.device will get all the CPU it wants.
  76.  
  77.  
  78.  
  79. -- 
  80. *-------------------------------------------*---------------------------*
  81. |Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
  82. |                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
  83. |My opinions are my own, and do not         - icantforgettheimpression  o
  84. |necessarily represent those of my employer.- youmadeyouleftaholeinthe  r
  85. |"A screaming comes across the sky..."      - backofmyhead              d
  86. *-------------------------------------------*---------------------------*
  87.