home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / programm / 5184 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.7 KB  |  68 lines
  1. Newsgroups: rec.games.programmer
  2. Path: sparky!uunet!spool.mu.edu!agate!ames!nsisrv!betsy.gsfc.nasa.gov!giglio
  3. From: giglio@betsy.gsfc.nasa.gov (Louis Giglio)
  4. Subject: Re: Triple Buffering: NOT!
  5. Message-ID: <1992Dec24.152230@betsy.gsfc.nasa.gov>
  6. Keywords: buffering
  7. Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet)
  8. Nntp-Posting-Host: betsy.gsfc.nasa.gov
  9. Reply-To: giglio@betsy.gsfc.nasa.gov (Louis Giglio)
  10. Organization: NASA/GSFC
  11. References: <1992Dec21.171731.26731@midway.uchicago.edu> <1992Dec22.202057.18233@blkbox> <709@muller.loria.fr> <1992Dec24.185505.27786@mprgate.mpr.ca>
  12. Date: Thu, 24 Dec 1992 20:22:30 GMT
  13. Lines: 53
  14.  
  15. In article <1992Dec24.185505.27786@mprgate.mpr.ca>,
  16. vanderby@mprgate.mpr.ca (David Vanderbyl) writes:
  17. |> eker@loria.fr (Steven Eker) writes:
  18. |> >If your frame redraw code takes longer than one video frame, one way
  19. of speeding
  20. |> >things up is to use triple buffering rather than double buffering.
  21. |> [explanation deleted]
  22. |> 
  23. |> Triple buffering is completely useless. (Almost) Here's why.
  24. |> 
  25. |> Let's say your screen redraw takes 0.9 of the frame rate time.
  26. |> No problem, right?  You simply draw each frame and wait for
  27. |> the vertical retrace.
  28. |> 
  29. |> Now let's say your screen redraw takes 1.1 of the frame rate time.
  30. |> If the frame rate is 1/30 second per frame then your redraw takes
  31. |> 1.1/30 of a second.  So in 1 second you need to draw 30 frames for
  32. |> a total of 1.1/30 * 30 = 1.1 seconds.  It doesn't matter how many
  33. |> buffers you use, you can't do 1.1 seconds worth of drawing in 1
  34. |> second.
  35. |> 
  36. |> To the person who posted their triple buffering idea:
  37. |> Please state that you idea is just that, an idea. (and in this
  38. |> case not a very good one.)  It will save a lot of people from
  39. |> being misled.
  40.  
  41.  
  42. If you sit down with a piece of paper and pencil I think you will see
  43. that you are actually wrong.  Look at it this way:  with your double
  44. buffering scheme the CPU sits around and does *nothing* while it waits
  45. for the next frame.  With triple buffering the CPU starts drawing the
  46. next
  47. frame, so it effectively has a head start.
  48.  
  49. Get some paper and start a sequence like this:
  50.  
  51. display         (double buffer)               (triple buffer)
  52. .03333 sec       draw frame 0.03666 sec       draw 0.03666 sec
  53. .03333 sec       DO NOTHING 0.03 sec          start next frame 0.03 sec
  54. FLIP
  55. .03333 sec       draw frame 0.03666 sec       finish frame 0.00666 sec
  56.                  {still drawing/waiting}      {can flip next page here}
  57. .03333 sec       DO NOTHING 0.03 sec          start next frame 0.06 sec
  58.                  {now flip}
  59.  
  60. I know this "chart" is a confusing mess, but if you work it out
  61. yourself,
  62. you'll see the point.
  63.  
  64. The triple buffered display gets slightly ahead of the double buffered
  65. display, yielding a higher frame rate.
  66.  
  67.  
  68.