home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / atari / st / tech / 4136 < prev    next >
Encoding:
Text File  |  1992-07-24  |  3.5 KB  |  77 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!dmb
  3. From: dmb@wam.umd.edu (David M. Baggett)
  4. Subject: Re: Is page flipping safe, and I need to know about syncing
  5.         <1992Jul23.184657.5699@wam.umd.edu>
  6.         <1992Jul23.222019.27222@infoserver.th-darmstadt.de>
  7. Message-ID: <1992Jul24.144340.24606@wam.umd.edu>
  8. Sender: usenet@wam.umd.edu (USENET News system)
  9. Nntp-Posting-Host: rac2.wam.umd.edu
  10. Organization: University of Maryland, College Park
  11. Date: Fri, 24 Jul 1992 14:43:40 GMT
  12. Lines: 63
  13.  
  14. wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
  15. >dmb@wam.umd.edu (David M. Baggett) writes:
  16. >>The Setscreen and Vsync (X)Bios calls work fine for double buffering
  17. >>(aka "page flipping").  There are some subtleties but for most
  18. >>practical purposes you'll get good results using these calls and your
  19. >>code will work with all versions of TOS (including, in theory, those
  20. >For most practical purposes you do get good results with this.
  21. >
  22. >BUT: the disadvantage is that you don't have precision page flipping. It 
  23. >just may happen that on screen1 you are done drawing in 2 screens and flip 
  24. >then, while on screen2 you need 3 screens. The net effect of that would
  25. >be that if your flip rate is 4 that screen 1 will be displayed 5 VBIs, where 
  26. >screen2 will be displayed only for 3 VBIs.
  27.  
  28. Nat! is right and has pointed out the "subtlety" I alluded to.  In
  29. practice it doesn't make a whole lot of difference since you don't
  30. often find a game that goes 3, 2, 3, 2, 3, 2 consistently enough to
  31. look jerky; the priciple of locality tends to hold in game timing as
  32. well as it does in the rest of the computer world, and so you usually
  33. find that your game will run something more along the lines of 4, 4, 4,
  34. 4, 4, 4, 4, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, ...
  35.  
  36. It isn't so much a problem with the vsync counting code as with
  37. Setscreen.  Remember that you don't wait _exactly_ n vertical retraces
  38. each game turn; you wait long enough to ensure that _at least_ n
  39. vertical retraces have happened since the last game turn.  Assuming n
  40. is 4, your example would work out as follows:
  41.  
  42. frclock    screen    frames req.    condition to wait on    #frames to wait
  43.  
  44. 1000    1    2        frclock >= 1004        1004-1002 = 2
  45. 1004    2    3        frclock >= 1008        1008-1007 = 1
  46. 1008    1    2        frclock >= 1012        1012-1010 = 2
  47.  
  48. screen one is visible through the period from 1004 to 1008, during the
  49. time screen two is being computed and drawn to, which includes the
  50. 1-frame wait starting at 1007.
  51.  
  52. screen two is visible through the period from 1008 to 1012, during the
  53. time screen 1 is being being computed and drawn to, which includes the
  54. 2-frame wait starting at 1010.
  55.  
  56. The vsyncing algorithm I described simply adapts itself dynamically to
  57. the CPU requirements of the game.
  58.  
  59. The problem is that Setscreen sets the screen as soon as the *next*
  60. vblank comes around.  Nat!'s right in thinking that you need to wait
  61. until the end of your ~n vertical retrace waits to set the actual
  62. screen pointer.  One way around this is to call the adaptive vsync
  63. routine with n-1, then call Setscreen, and then call Vsync().  Then
  64. you're still OK with respect to the cross-machine compatibilty but your
  65. timing is exact.
  66.  
  67. >If your game nears completion and you are not 100% satisfied with the
  68. >animation I'd suggest that you use the VBL directly to flip pages (you
  69. >can use Setscreen()) there too.  Until then Setscreen() + Vsync() +
  70. >frclock will suffice.
  71.  
  72. Calling Setscreen from an interupt seems very dodgy to me.  It may
  73. work now, but I wouldn't count on it working forever.
  74.  
  75. Dave Baggett
  76. dmb@wam.umd.edu
  77.