home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / programm / 5183 < prev    next >
Encoding:
Text File  |  1992-12-24  |  1.5 KB  |  35 lines
  1. Newsgroups: rec.games.programmer
  2. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!gatech!destroyer!cs.ubc.ca!mprgate.mpr.ca!mprgate.mpr.ca!vanderby
  3. From: vanderby@mprgate.mpr.ca (David Vanderbyl)
  4. Subject: Triple Buffering: NOT!
  5. Message-ID: <1992Dec24.185505.27786@mprgate.mpr.ca>
  6. Sender: news@mprgate.mpr.ca
  7. Reply-To: vanderby@mprgate.mpr.ca (David Vanderbyl)
  8. Organization: MPR Teltech Ltd.
  9. References: <1992Dec21.171731.26731@midway.uchicago.edu> <1992Dec22.202057.18233@blkbox> <709@muller.loria.fr>
  10. Date: Thu, 24 Dec 92 18:55:05 GMT
  11. Lines: 22
  12.  
  13. eker@loria.fr (Steven Eker) writes:
  14. >If your frame redraw code takes longer than one video frame, one way of speeding
  15. >things up is to use triple buffering rather than double buffering.
  16. [explanation deleted]
  17.  
  18. Triple buffering is completely useless. (Almost) Here's why.
  19.  
  20. Let's say your screen redraw takes 0.9 of the frame rate time.
  21. No problem, right?  You simply draw each frame and wait for
  22. the vertical retrace.
  23.  
  24. Now let's say your screen redraw takes 1.1 of the frame rate time.
  25. If the frame rate is 1/30 second per frame then your redraw takes
  26. 1.1/30 of a second.  So in 1 second you need to draw 30 frames for
  27. a total of 1.1/30 * 30 = 1.1 seconds.  It doesn't matter how many
  28. buffers you use, you can't do 1.1 seconds worth of drawing in 1
  29. second.
  30.  
  31. To the person who posted their triple buffering idea:
  32. Please state that you idea is just that, an idea. (and in this
  33. case not a very good one.)  It will save a lot of people from
  34. being misled.
  35.