home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1584 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Sat, 20 Jan 96 18:26:39 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Demo/game to OS friendly part II
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.47u5@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 19 Jan 96 Benjamin Hutchings wrote to All:
  14.  
  15.  >> How about a frontmost window layer that do not overlap... you can
  16.  >> pokeaway... If you dont want to force a window to be alway frontmost
  17.  >> you can check for any clipping and stop rendering when not frontmost.
  18.  >> Or lock the window tofront while you render or even if possible use
  19.  >> an offscreen buffer and render to it (Not possible on SGI system.)
  20.  
  21.  >> Having a mecanism for the user to extend the gfxlibrary at a 'lowlevel' 
  22.  >> is something AT should REALLY think about.
  23.  
  24.  BH> This is what Microsoft calls DirectDraw, and is how Windows 95 games
  25.  BH> run quite fast, uh, sorry, not as slowly as under Windows 3.x (if they
  26.  BH> ran that way at all). An interesting kluge which just might work as
  27.  BH> well for the Amiga as it is bound to do for Win95, but it is
  28.  BH> questionable whether any Microsoft scheme is actually a good idea after
  29.  BH> all.
  30.  
  31. Games on Amiga don't need to run in a window, after all, we've got screens.
  32.  
  33. However, I think that accessing the screen-buffer directly is a necessity for
  34. fast games, like a DOOM clone, as they want to do stuff on a pixel basis which
  35. the OS doesn't provide standard functions for (unlike line-drawing for
  36. example).
  37.  
  38. That's why I think that it should be possible to specify a number of supported
  39. (pixel-) layouts with the OpenScreen call, so you can tell OpenScreen that your
  40. application supports only 8-bit and 16-bit Chunky displays for example, and
  41. 'force' OpenScreen to either give you such a screen or to fail (instead of
  42. getting 'the best match').  A 'query' function to find out about what screen
  43. you got back from OpenScreen would also be quite handy.
  44.  
  45. Grtz John
  46.  
  47. -----------------------------------------------------------------------
  48.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  49. -----------------------------------------------------------------------
  50. -- Via Xenolink 1.985B3, XenolinkUUCP 1.1
  51.