home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / programm / 5186 < prev    next >
Encoding:
Internet Message Format  |  1992-12-25  |  2.6 KB
  1. Path: sparky!uunet!munnari.oz.au!uniwa!shrydar
  2. From: shrydar@tartarus.uwa.edu.au (Christopher Phillips)
  3. Newsgroups: rec.games.programmer
  4. Subject: Re: Triple Buffering: Maybe..
  5. Date: 25 Dec 1992 15:18:01 GMT
  6. Organization: The University of Western Australia
  7. Lines: 49
  8. Message-ID: <1hf8n9INN8c3@uniwa.uwa.edu.au>
  9. References: <1992Dec21.171731.26731@midway.uchicago.edu> <1992Dec22.202057.18233@blkbox> <709@muller.loria.fr> <1992Dec24.185505.27786@mprgate.mpr.ca> <1992Dec24.152230@betsy.gsfc.nasa.gov> <1992Dec24.223839.29198@mprgate.mpr.ca>
  10. NNTP-Posting-Host: tartarus.uwa.edu.au
  11. Keywords: buffering
  12.  
  13. vanderby@mprgate.mpr.ca (David Vanderbyl) writes:
  14.  
  15. >I do see the point.  But what are you going to do with about 25 frames
  16. >when the frame rate is 30?  I don't think showing 25 frames with some
  17. >repeats will be much better animation than showing 15 frames with all
  18. >repeats.
  19.  
  20. It's precisly this situation where triple buffering is the most
  21. effective;  As long as your underlying model maintains a constant speed
  22. (see other articls in this thread), more frames always looks better,
  23. particularly when we are talking about a 5:3 improvement such as the one
  24. mentioned above.
  25.  
  26. >Of course, we are assuming that the redraw rate is just longer than the
  27. >frame rate.  Of course if the redraw rate was a lot longer then triple
  28. >buffering could improve things. An example would be if we could increase
  29. >from 4 to 5 redraws per second.
  30.  
  31. Triple buffering will never get your this sort of improvement from a
  32. crt; it will save you a maximum of one refresh period per frame.  When
  33. you are talking about 4 redraws per second, you go at most 1% faster by
  34. triple buffering.  In other words, you have a complete waste of memory.
  35.  
  36.  
  37. While on the topic of avoiding 'wasting cpu time on frame waits', it is
  38. worth remembering that, for many applications, the refresh code does not
  39. always start writing to the frame-buffer immediately.  For example, a 3d
  40. graphics game has to convert vertices to screen coordinates, initialise
  41. scan routines etc.  This can all be done while waiting for the refresh.
  42.  
  43. If your preparatory routines for each frame take more than a single
  44. refresh period, you will not benefit at all from triple buffering.
  45. The following is pseudo-code for my main loop:
  46.  
  47. {
  48.    scribble on off-screen page
  49.    tell interupt routine 'next page is ready'
  50.    prepare to draw next frame
  51.    if frame has not been flipped yet, then wait for flip
  52. }
  53.  
  54. where there is an interupt routine that is called at every fly-back, and
  55. swaps the on and off screen pages when the next page is ready, and
  56. indicates that the swap has occured.
  57.  
  58. Merry Christmas all!
  59.  
  60. Christoper Jam
  61.  
  62.