home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2239 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.4 KB
  1. Path: Hermes.grace.irl.cri.nz!maths!peterm
  2. From: peterm@maths.grace.cri.nz (Peter McGavin)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 29 Jan 1996 03:40:36 GMT
  6. Organization: Industrial Research Ltd
  7. Distribution: world
  8. Message-ID: <PETERM.96Jan29164036@tui.maths.irl.cri.nz>
  9. References: <john.hendrikx.47u5@grafix.xs4all.nl>
  10. NNTP-Posting-Host: tui.grace.cri.nz
  11. In-reply-to: john.hendrikx@grafix.xs4all.nl's message of Sat, 20 Jan 96
  12.     18:26:39 GMT+1
  13.  
  14. john.hendrikx@grafix.xs4all.nl (John Hendrikx) writes:
  15. >However, I think that accessing the screen-buffer directly is a
  16. >necessity for fast games, like a DOOM clone, as they want to do stuff
  17. >on a pixel basis which the OS doesn't provide standard functions for
  18. >(unlike line-drawing for example).
  19.  
  20. Personally I would like to see what seems a completely opposite
  21. approach (for RTG).  That is, I think gfx should be implemented
  22. something like DOS.  Gfx primitives like Draw(), SetAPen(), Text(),
  23. etc, internally should use message-passing and packets.  The Amiga has
  24. a big advantage over other platforms that messages don't have to be
  25. copied.  Applications can choose either synchronous or asynchronous
  26. interfaces.  Gfx card drivers would have standard async BeginIO()
  27. functions.  The main advantages are:
  28.  
  29.  o  This allows much better high-level _async_ graphics than the
  30.     current implementation.  Applications don't have to wait for
  31.     each primitive to finish before they queue the next one.  Indeed,
  32.     an application could queue hundreds or thousands of operations
  33.     in advance, then carry on with something else while the gfx
  34.     system catches up.  Another scenario is that the application
  35.     queues only a few, large operations, such as a single, large,
  36.     WritePixelArray8() which operates with async DMA and uses no
  37.     CPU time.  Thus, gfx coprocessors and DMA can be better
  38.     utilised;
  39.  
  40.  o  Gfx redirection across networks would be relatively trivial
  41.     (much like X11).
  42.  
  43.  o  It makes less assumptions about the underlying hardware.  Gfx
  44.     hardware doesn't even have to be memory-mapped.
  45.  
  46.  o  It is more straightforward to share the same hardware between
  47.     multiple tasks this way.
  48.  
  49. But how could we reconcile such an interface with a system that allows
  50. direct hardware poking?  (and which won't work with "non-standard" gfx
  51. hardware or networks, BTW.)
  52. -- 
  53. Peter McGavin.   (p.mcgavin@irl.cri.nz)
  54.